Unraveling the Complexities of Scaling

Scaling Agile to fit your world! Peter & Dave explore the nuances of customizing agile frameworks for diverse organizational needs. They delve into practical applications of the 80-20 rule and discuss the pivotal role of agile coaching in facilitating effective change. Tune in for a clear and engaging discussion on how to adapt agile methods to suit your specific organizational needs, making your work processes smoother and more efficient.

This week's takeaways:

• Context-specific scaling: the need to tailor agile scaling efforts to the unique context and culture of each organization, acknowledging that a one-size-fits-all approach doesn't work.
• Framework agnosticism:  the importance of not being overly reliant on a single agile framework. Instead, understanding and choosing from various frameworks and patterns to best fit your organization's specific needs is crucial.
• The 80-20 rule in scaling: identify the critical 20% of agile practices that are most relevant and impactful for your organization, while recognizing that 80% might be generally applicable.
• Organizational change as problem-solving:  scaling agile as an organizational change challenge, requiring a problem-solving mindset to identify specific issues and apply targeted agile practices effectively.

If you're interested in editing or providing feedback for their upcoming ebook, please contact us at feedback@definitelymaybeagile.com. And don't forget to subscribe to the podcast for more insightful episodes.

Chapters

• 0:05 Scaling Agile
• 6:20 Patterns, Practices, and Scaling Agile Delivery

Transcript

Peter: 0:05

Welcome to Definitely, Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you today?

Dave: 0:15

Peter, good to see you again. Good to have a bit of a chat about some topics.

Peter: 0:19

It is indeed. And what's on the cards today?

Dave: 0:23

I wanted to float the idea of talking a little bit about scaling, and there's a couple of reasons for that. One is, while everything we've talked about in one way or another relates to the idea of getting agility across more than a few teams right, we've talked about this in many different contexts over the years. But the other side is that the Scrum Alliance has just announced a new scaling course, a scaling product. I've been fortunate enough to be involved in kind of helping pull together what that course might look like, and so there's just some interesting topics that came up in those conversations that, now that it's beginning to kind of gather some momentum, I think would be a great place for us to talk and sort of share our views on what that scaling product, what scaling and agility really means.

Peter: 1:10

Yeah, it's an interesting topic, isn't it? And we were chatting a little bit before this, and my perspective is similar around that. The first question you ask when somebody say they want to scale agile is well, what is it that you're scaling? What exactly is it you're looking to do? What's the outcome you're targeting here? Because very often this is coming from a place of well, we set up a team over here and they seem to have done quite well. Okay, how do I do that for the rest of my organization?

Dave: 1:38

More of that everywhere, right, and I mean I would say we're lucky if we get that conversation. What we normally get is we need to be agile, or 2020X this is the year that we're going to be agile or something like that. Or we want this framework, we want this Spotify model, or we want the X, y and Z model framework, and of course, that's not the way these things work, because we've got to understand that we need to. Leading with a solution or leading with a tool is never going to get you where you want to go in these sort of organizational transformations.

Peter: 2:09

Yeah, it's not. Something that worked somewhere else is not necessarily going to work here. And the interesting word in that sentence, of course, is necessarily you may have some success with some of these frameworks and at least a part of your organization. It might actually work quite well, and but then it's unlikely, given your organizational context and the people that you have in the situation you're in with the systems that you have. That if you can just copy something from somewhere else and slap it down on your organization and expect it to work Well.

Dave: 2:39

I mean, we've talked man y times about Kinevin and complexity and the fact is this sort of volatile, unique, contextual environments become very difficult to rubber stamp or to copy and paste what works in one organization into another, and I think that's that's part of I mean, it's part of why we work with organizations is that 80%, which is the same, is great, but the art is in identifying the 20% which is contextually relevant in your organization and your situation.

Peter: 3:07

Yeah, the conversation, even recently, I've had with an organization you said well, just tell us how to do it, just tell us how to set this up like that, exactly, let me email you.

Dave: 3:18

It was kind of a hit list of what to do Well and one of the other things. So what I really enjoyed over the last few months of just pulling some you know, discussing what goes into scaling is recognizing first of all and I think this was a really smart move of what the course ended up doing, is saying hold on, let's not try and do agility everywhere.

Dave: 3:37

Let's take a look at the most common problem, which is I need more capacity. How do I scale across many teams? Or maybe you know the product is growing in complexity. How do I scale that complexity technically across many teams, or even just simple things? Like you know, we're now we're an international company and we've got teams distributed in lots of different locales, time zones, and how do you overcome the complexity? You know the difficulty of working in those environments and I think this is a really it isn't well enough understood to say, oh well, you just go and do these things, even those what many might consider pretty straightforward, of you know, moving to a dozen teams from two teams or whatever other instance of that problem is. There's still plenty of room, for what works here doesn't necessarily work there.

Peter: 4:23

Yeah, and especially I mean the classic example of that is okay. So you added more people and essentially into a system which is greater, more communication channels. If you aren't able to have those teams deliver individually because the underlying system architecture doesn't enable them to, I don't have the surrounding frameworks and capabilities to make any of that work. So it's great that I've got more people. It's actually going to just slow you down. Yes.

Dave: 4:48

Well and leave you with a lot of risk because you've got those two layers right the technical layer that you have to kind of make sure is aligned and congruent and so on and behaving in its way that we need it to, and then the sort of communication layer, the people side of it, which is digital transformations and, a nutshell, that's what makes them hard is it's not just technology or just people, it's a combination of both.

Dave: 5:10

Now, one of the other things that the learning objectives really focused on is not is being framework agnostic, and what I find interesting in the market right now is there's a lot of conversation about framework X, framework Y, framework Z, but very little about scaling and how to make a decision around framework. So how to make a decision around the patterns that you use or don't you and I think that was a really good I mean, we all agreed on the subject matter experts of just the validity of patterns and of just recognizing that frameworks definitely have value. But there's another that is kind of like you got to know how to use them and what bits of them to you.

Peter: 5:49

Yeah, and patterns work a little better in that sense, in that you can say well, here are things that we've seen, combinations of things that we've seen work well in other organizations or in other places. That doesn't necessarily mean those patterns are going to work well with you, but they may well. So this is something to try. This is how things might relate together, so something to look at. If you have this problem, try this pattern. Like, if you see this in your organization, then try this pattern and see if it helps resolve that or helps you forward.

Dave: 6:19

Well, I think there's so many. Intuitively, we understand where these sort of patterns and practices come from and we can talk about them. But what I find is more granular, so you're not trying to kind of shift the entire thing. They're really kind of targeting a particular problem that's been identified, and what I like about it is it's a problem, it's really true problem solving. We can now look at this and go.

Dave: 6:42

You know there are different patterns. How do we select which pattern we're going to use? When we use a pattern, how do we validate it? And again, we've talked about this so many times, whether it's experiments, whether it's just understanding context, to be able to make small changes and evolve our approach as we get feedback and so on. And what I find interesting is it doesn't mean we have to be slow. Those small changes can be happening repeatedly and rapidly, but it is definitely not a fire and forget approach. We kind of got to be continuously engaged and aware of those changes as they're happening and make sure we're not going and driving off a cliff by accident, as it were.

Peter: 7:18

Yeah, we've got to be able to measure, we've got to be intentional, as you often could word to describe it. I find to say we're intentional about the actions that we take and we're looking at to measure what are those outcomes. So we want to make sure that we understand that, hey, we're going to try this pattern and this is what we're hoping to see as an outcome. And if we don't see that, we need to look at why and decide whether that's something that we want to continue doing or if we want to go and find something else that may work better for us.

Dave: 7:43

And I really I find the conversation like that 80-20 rule that I hinted at earlier on. There is so many times there's. From a scaling perspective, there seems to be a choice of either choose a framework or clean slate, build from the ground up, and I think what it? Understanding patterns and principles and how to use those to scale agile delivery in an organization, agility in an organization. That really stops us looking at it as a blank sheet, a blank slate, and allows us to actually build out the 80% which we know is almost certainly going to bed in really really smoothly and easily, and focus on the 20%. But it's not having to emerge everything. We don't have to emerge everything. We need to really understand that 20% has to be unique to our situation.

Peter: 8:28

Yeah, and understand what's going to, what's different about it here that we need to sort of adapt to our world, to our context, to how we work, to the structures that we have, the existing cultures or ways of behaving that drive different aspects of the organization and make sure that we're not disrupting things, as well as the element of not disrupting things too fast. Yeah.

Dave: 8:52

Or out of control right, accelerating change in an environment where it's not the right thing to do. I'm reminded I think you just in preparation, we were just chatting about it and you were talking about it's not will it work, but will it work here?

Peter: 9:04

Yeah, and it's the and finding things that are the patterns that are going to. People are going to latch on to and say that's great. I love that. I can take that and I can apply it here. I can see how that's going to help you. This is the. I can get passionate about this. I can use this.

Dave: 9:20

It's I just you remind me completely of that conversation that we had about I think it was my iceberg is melting and how important it is to get that enthusiastic response, because sometimes we see this as some sort of like project that we have to deliver and it has to be serious and change, and I've just you just reminded again so much of it is is that engagement and enthusiasm that comes with it. So that's a great takeaway.

Peter: 9:44

Yeah, yeah, the what's in it. For me is the important part of it, as we, because anytime you're introducing change, you people are going to initially they're like sort of, that's not going to affect me, I don't want to do it. And then they're going to be like I really don't want to do that. It's tough, but it takes time for people to get used to new ideas, and there's a lot of literature on this, of course, and lots of ways of explaining that. But the anytime we're introducing things, that it is, it is different from how things have been done before. So the the smaller you can make that change, the easier it is to consume. So it's the if. Trying to do massive changes all at once to everybody can be very disruptive to the organization. So as you look to scale as well, it's better to apply it in small bits and learn as you go and find out what's going to work, even even within your organization, depending on the size and what sort of things you're looking to introduce.

Dave: 10:37

And this is really interesting because it wraps up what I was trying to use as our our thread that we're going through, which is the final section of the learning objectives that we ended up discussing, was about organizational transformations being a change problem. Organizational change problem and and again we've discussed this a number of times but organizational change problem as sort of agile doing agile right.

Dave: 11:00

An incremental, like evidence driven, sort of iterations of change, rather than the communique that goes out to say, as of you know, monday, this is the way the organization will operate, and I think one of the things that came out of that so it's so, and I'm really happy about this, getting into this conversation around scaling was the idea of scaffold, of how to help organizations change, because this is where you and I work, so that scaffold is a temporary structure that we're going to put into an organization to allow them to get used to how that transformation works.

Dave: 11:35

And, of course, having an agile coach alongside you for the journey for six months or a year, whatever it might be, is the classic scaffold, but not the only one, right? And and I I'm so happy that that conversation is had in the learning objectives because it speaks to what you and I do all the time with our clients, which is how do we help them get comfortable with the new process and the new way of working, not just selecting what it might look like, but actually bedding it in so that it becomes the de facto way of working instead of being an idea that's thrown up on a wall.

Peter: 12:08

Yeah, and this is the how do you go from it being that idea up on the wall to it being something that people do as practice and you can always tell when it is or it isn't because the moment something else, something changes, do people go back to the old way of doing things or do they continue doing things in the new way? How brought up in are they to that new way of working? And so that's a clear indicator that whether or not people have actually started to say, okay, this works for me, I can see how this makes things better, and and we should- definitely do this Well and I think it's.

Dave: 12:40

It's important to recognize that you know we're all busy, we're all overloaded, we're all trying to work on something. You know the priorities that we're, that are in front of us and we're aware of, and you need those those little kind of structural supports to keep you in the right place, just like if we sprain an ankle or whatever some sort of you know break a bone or something. We need something just to make sure that we protect that so that it can get strong, before we take all of those those supports away and leave people to run around and do it all over again. Yes, yes, well on that note.

Dave: 13:14

Speaking of doing it all over again, I really appreciated a bit of a chat around that sort of scaling idea that I've been working on for some time. Takeaways, what kind of stood out?

Peter: 13:24

I think the the agnostic nature of it depends on patterns is good in that it helps people to remember to focus on what is it you're actually trying to do. It's not. It's not about really trying to scale the practice as much as it is. You're trying to get better at delivering products or better at doing the service that you provide, so you're trying to improve these things and make it more responsive. Do get all of these other benefits. What are the reasons? It isn't about scaling the framework?

Dave: 13:53

I'm just going to hog back to like that's the beginning of the journey. If you like, I'm just going to go to that end. One to recognize it is it is an organizational change process and use Agile to be Agile. But I just wanted to call out that whole idea of what supports do you put in place so that your organization can get good at the new ways of working as they evolve and emerge? Awesome, well on that note.

Peter: 14:16

I think we wrap it up there for today and I'd like to thank you. As always, Dave, always an interesting conversation. And for all our listeners, don't forget to hit subscribe so you can hear our latest chats about all sorts of interesting topics and give us the feedback, at feedback@definitely maybe agile. com, till next time, Peter. Thanks again, till next time. You've been listening to Definitel, Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital agile and DevOps at scale.