Scaling

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. We're back again. Peter, good to talk to you again. Yeah, what are we talking about this week?

We're going to be talking about scaling, everyone's favorite topic.

It's an interesting one. You say it's everybody's favorite topic. And I would argue a few years ago it was everybody's favorite topic. What I found quite interesting, just to kind of kick things off, if you like, is there was a few years ago when everybody needed to know about scaling. They needed a framework that they could bring into their organization. What I find interesting is that question, how do we scale or what framework should we use? I never get that anymore.

Yeah, and I and I I'd like to think that's because the industry's maturing. Um they're learning. Uh what do you think's driving it?

Yeah. Well, I was just going to say, I think it is, I still think the problems that scaling was trying to resolve, those problems still exist. So I think to your point, it's more about the language changing. And if I go down a layer from scaling to think about, well, what I'm really worried about is say release, how can I get releases out of the door? Or what do we do around dependencies, or what do we do around governance and oversight, product ideation? That's sort of that next level down. And I think that's the language has the vocabulary has broadened, and now the questions are a little bit more directed.

Yeah, and I think the one of the problems that uh I know both you and I have seen in organizations when they uh go and say, okay, where's this magical scaling framework that we can come and adopt and slot onto our organization? And you know, it's like get a big stamp and we're just gonna stamp this onto the organization, and that's how we do things now. Uh the that it just doesn't work because there's just so many nuances in how the organization operates, the network of interactions between the people within the organization, how work actually gets done, uh that by trying to shove it into this giant framework just doesn't work.

And we we talk a lot about complexity in our conversations here, and it's actually more it's even worse than that in the sense that organizations today very definitely are complex adaptive systems. And the reason a cookie-cut approach doesn't work in a complex adaptive system is as soon as you put that in, it's going to adapt its way around it. So you're continuously chasing a goal that's just never sort of standing still long enough to actually be achieved. But let's so I think that's part of that conversation, which is the realization that frameworks that you can effectively buy off the shelf in and of themselves, that simple cookie cutter thing, doesn't work. And now you go down a level to start saying, right, how do I bring some of the benefits that I get with you know aligned prioritization across different products? For example, how do I we start? And that's where that language now we're going beyond scaling or below, beneath scaling to start dealing with what's really happening.

Yeah, and then solve some of the problems that you brought up at the start there. Like, how do I govern this? How do I how do I create that coordination across my organization? How does all of this work when I'm dealing with multiple teams, with multiple areas, with uh lots of complexity in my big mess of an organization? Um I I always liked um one of John Smart's quotes out of the BVSSH um space around like uh don't scale the framework, descale the work. And at least that's where I first heard that term. But this this idea that rather than saying, hey, I've got this this framework, it's worked in this one piece, I'm just gonna blow that up and do the same thing everywhere. Instead, look at like how do I get the work to be smaller? And then because by doing that, that'll start to make where the impediments in the system actually are, and that'll make those bits visible. And as you start to do that, then you've you've got that will become your roadmap because now you've got to start to look at those impediments, and then uh solving the impediments is the direction to go in, and that's what's going to enable you to scale.

Well, I I've had a number of conversations in the last kind of few weeks around this idea of scaling versus transformation, and and I think in having those conversations, one of the realizations I came to is I think there is a space where scaling is a conversation, like is a valid conversation. And I think it touches on exactly what you're saying, which is that idea that you don't scale the framework, you descale the work. And if I take that one, you know, if I descale the work down to a single team with their backlog and they're doing what they need to do with that, that scaling now becomes well, a single team might be able to do wonderful things for a certain you know scope. But if I need more wonderful things, I need more teams. And so very quickly you get into a conversation where you've got six or ten or twelve teams. And I think at this point, there's a really great conversation of scaling because I've got a single backlog and a single team moving to two or three or six or ten teams, and there are some very well-known practices, starting points that we can use and create the right scaling there. So when I think of scaling right now, I think of that sort of multiple teams, not a hundred teams, but multiple teams working on a single product. How do we align decisions, priorities across those teams? How do we make things work well together?

Yeah, and this is where concepts like value streams and value stream management and OKRs as an alignment model, that's where that that piece comes in. And we've talked about that before. Like, and uh, I've got a uh an online course on LinkedIn Learning you can take if you want to learn more about uh value stream management. Uh so that there's lots of um that's kind of the space that I go into when I start to think of like how do we start to create that alignment across these teams and the models that we can use for that. Um there's a there's an important part as we do that, uh, where often I see this fall down, is where if you're bringing in and focusing solely on the framework and then saying, okay, this framework worked in this part, I'm gonna roll it out everywhere else, and it becomes inflicted on other parts of the organization. Quite often it ignores the fact that uh there are dependencies of of various forms between different parts of the organization, either technology or otherwise, that prevent them actually being able to do the activities that are being constructed.

And I think um this is where if if you now if we for the moment park this sort of scaling to be what you were describing from the um uh BBSSH model, if you like, of that don't scale the framework, descale the work, and you end up in a place where maybe one team isn't sufficient, so you've got a handful of teams, whatever that is, that's one bucket. But now when you look at that across many dozens of teams, you can still keep that framework of don't scale the or that model in mind of don't scale the framework, descale the work, but we still have alignment conversations, prioritization conversation, funding, technical issues, dependencies, people dependencies that go across those individual groups. And the headache there is that's where these frameworks come in. And I think what we want to take there is to clarify my comment about the headache is there isn't one framework that's going to make that work. But the elements of those frameworks can be, depending on the situation in hand, can be a great place to start because maybe they're going to solve a chunk of that problem. But they shouldn't be taken as a you know, peel it out, open it up, and go, ta-da, this is it. It should be maybe I'm maybe I'm close to the solution that's going to work in my organization.

Yeah, it's it's the uh this this panacea, there are no silver bullets, it's the you you there is no one place, but but I I agree with you, they can be a really good place to learn and to look at and to understand and to to start to apply from that perspective. Uh as and I usually say as long as you realize that it's it's the starting point you're going to be looking to evolve from, it's it's not the destination. Uh and being and and that's actually I think where some of the danger is, that by having that there, it often becomes the destination in in of itself, just by the fact it exists.

And then that can drive documented, and this is the way that we're going to use so it's it's quite an interesting balance because we definitely don't want to stay in this space where everything is kind of amorphous. Because how do you how do you share the best ways of working or the commonly good ways, you know, the things that have proven to be pretty solid? How do I get that across an organization? Well, I'm going to document it, I'm going to put together templates, I'm going to standardize a lot of those things. But you want to standardize and document and make that nuanced within the organization that you work in the particular context that you have, rather than pull something off the shelf and try and do that too early. Yes, yeah.

And there are various models out there that we we see around that. The concept of lighthouses and like and uh we we use principles to create commonality and language and an understanding of like what is what do we consider good and how do we move forward. And we uh and we take the successes and we radiate them and we we bring people to them, and then these these are also very much a part of that uh that scaling mechanism.

Well, and I think you're beginning to describe change models that really allow you to to bring people to you rather than send policy documents out to them, I guess would be one way of thinking of it. Yes.

I can help you. Um I'm inviting you to come on this journey with me, um, but you don't have to. It's up to you. Um so and that that but that could be a difficult thing, especially within a large organization that's quite bureaucratic or dictorial in nature, for them to uh accept that uh I'm not actually just gonna go out and tell everybody how to do their jobs.

There's uh I was just uh having a chat with a good friend yesterday, and um he mentioned a book. I haven't read this book yet, but he gave me the idea of the concept behind it. And it's I think it's something to do um orbiting the giant hairball. And uh what's interesting there is this continuous challenge between spinning off creative, you know, pockets of creativity, if you like, or parts of your organization that are creative, while at the same time knowing that there's some sort of corporate entity that's trying to retain control over those creative entities. And in a it and it it's to it's written from the perspective, I think it was uh uh uh an executive at Hallmark that pulled this together and the balance of creativity that Hallmark Cards has to manage within the need for a corporate guidance. And I again I'm sort of quoting from the conversation I had. Um, but what's interesting there is if you think of agile teams and value streams and those as being these creative entities that are they they need to be close to the corporate center, but not tied really, really tightly into it. And I and this is that space where frameworks have to be the right, you know, they they can't be a prison that try and keeps everybody in line. And it's a really difficult mindset. It's like yeah, it's not about getting control or keeping everybody in line, but it's about making sure they have the support they need and they're still aware of a true north and they're moving in that same direction. So there's some really interesting mindsets to accommodate there as well.

There is, uh there's some there's some always a balance between these two pieces. And uh I'm always careful of not going too far off the deep end because you because one part of um of this is well, if we have truly autonomous teams that uh operate completely independently of the total of the central organization, then but we still have to be able to demonstrate that they are following um either regulatory or other types of uh standards, uh you see you there's obviously a conflict between these two pieces because you cannot be fully autonomous and uh beholdened to a central standards. Yeah, like it's uh that that's just um these two things uh cannot coexist in the same place. Uh the because they're just because they are counter to each other. One is a centralized, you must do things this way, and the other is well, I can operate completely independently. Uh no, we we want to create as much ability to operate independently as possible, but we still need to make sure that uh those central requirements are being followed, the principles that we need to operate under. And uh that becomes even more so if you're operating in a highly regulated environment.

So maybe let's kind of bring a few thoughts together on this one. Scaling and transformation, how would you summarize the two or differentiate the two?

Oh, that's uh that's an interesting question. Because I I think the the goal of the scaling is the transformation. Right? It's like so so from that perspective, I'm not sure I necessarily differentiate the two uh so much as see them as uh as one being the uh intended uh deliverer of the other, uh, although so often it isn't, because because they if if you actually want people to change um and to to help people go on a journey, you need to to invite them onto that journey. And scaling a framework is unlikely to do that, um, at least in most of the cases I've seen, but it can act as an initial sort of guide to like where I should go. So I think that might be how I'd frame that.

And so what you're describing there, Peter, it sounds to me, and and maybe I uh I posed the question in the wrong way, but transformation as an umbrella, scaling, if we take that view, and I'm putting my definition in there, but that view of you know a small number of teams all aligned delivering a product or service, let's say that value stream of some sort, right? And then framework is perhaps how everything hangs together when you've got many of these entities.

I've got many value streams delivering different uh creating value for customers in different ways. And I I need to I need alignment across those to understand that if we're creating value that could be perceived as a customer journey that may cover different elements of value that could create by different value streams. And this is where we start to look at a that that's the scaling of the concept almost.

I I do wonder if there's a kind of a little change in terminology that might be quite interesting here because frameworks tend to feel like they're fixed and you've got framework A, framework B, framework C, but you don't want to sort of move them too much. But I'm reminded of a concept that I've um seen from the complexity space around scaffolding. And scaffolding has a completely different feel to it. Scaffolding you put up just enough to do what you need to do. You can take it down, it's it moves around, it provides you what you need for as long as you need it, and then you can take it down and build it up somewhere else. And sometimes you keep that scaffolding there permanently, and sometimes it shifts around a lot. And that maybe if we think of frameworks as really building scaffolding around the many teams or value streams, that gives us a model that's a little bit more fluid, a little bit more what exactly do we need here to do the job we need to do. And again, we can come back to the frameworks being maybe we've got some good ideas to steal from to be the starting point of those kind of evolving uh scaffolding frameworks.

Yeah, the scaffolding to support you as needed to get the to where you need to be. That that's uh yeah, I like that as an analogy.

I feel like a little bit of a light bulb moment that we can come through just from this conversation. So thank you for that.

Awesome. Uh well, you're most welcome. I always enjoy these conversations. Um so so I think um for anyone listening, if you'd like to subscribe, hit the subscribe button or find your favorite way to do so. And uh if you would like to provide us some feedback, you can do at feedback at definitely maybeagile.com. And uh and as I think Dave was saying last time, we were also uh looking to invite people on to join our conversation and uh and have lots of uh discussion.

Anything else you'd add, Dave? Looking forward to it. Always uh enjoy the the conversations. Thanks again, Peter. Likewise.

You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps scale.