Beyond Practices: What’s at the Core of Agile Transformation?

Everyone wants to focus on practices first. That’s because it’s easy. We can get trainers to come it, we can get coaches to come in, we can teach practices. But we don’t really have to make any hard organizational changes when we do that. Maybe it works sometimes, but in most large companies practices first is never the right way to go.

Join Mike as he debates the general consensus on Agile and encourages you to start thinking about Agile through the lens of systems so that you can finally achieve the change you’ve been searching for.

 

Transcript:

The idea here is that there is no way from here to there if we are only thinking about Agile practices or we are only thinking about Agile mindset, because at the end of the day, those practices and that mindset is going to go head on into like the skeletal system, the infrastructure of that organization, the way that it is structured, the way that it is governed, the way that it is measured is going to be told.

We are orthogonal to the practices and cultures that you’re trying to get to. So you can start with practices and cultures and try to back your way into the structural elements. But what we believe is that if you start with the structural elements, you take the big things, you systematically break them into smaller things. You work on reducing batch size and breaking dependencies and increasing local autonomy and giving those smaller objects some degrees of freedom through that core transfer nation effort.

You get the fundamental underpinnings of digital transformation. You get the fundamental underpinnings of the composable enterprise. You get the fundamental underpinnings of the product driven organization. You get the fundamental underpinnings of a project to products type infrastructure.

Okay, everybody, welcome. Welcome to our show today. And just to give a little bit of context, one of the things we’ve been doing for the last couple of weeks, months, something like that, is probably two or three months ago, I listed a group of about 20 different tweets for my marketing team, and they were just basically things that I talk about all the time structure, governance metrics, teams backlogs, working tested software dependencies, things like that.

And then one really cool thing happened is I posted it up into our internal Slack channel and one of our one of our senior engineers took them and ran them through, ran all the tweets through chat. And and the first thing he asked is he said something like, why is this statement controversial? And then and then he asked Chad GB to rebut the comment.

So why don’t you start with today is just a really explicit treatment of that. And then I’m going to branch off and I’m going to do I’m going to connect the dots to a few other things and I’m going to try to see if I can open up the conversation all that. So so bear with me here. So the tweet was trying to apply Agile practices and into an environment where they weren’t designed to support or enable is a recipe for disaster.

Alignment is everything. It is always the systems first structure, governance and metrics, then practices, then culture. It doesn’t work any other way, right? So basically trying to make the case in a short 140 characters, even though you can do more than that now that that you know LeadingAgile’s core approach that if we don’t get the teaming strategies right, we don’t get the ability to produce backlogs right.

We don’t get the ability to produce working tested software, right? We don’t put the RAID governance strategies in place, we don’t put the right metrics, strategies in place. You know, our core belief is that there is no amount of scrum, there’s no amount of scale to Agile, there’s no amount of large scale scrum practices that are going to help you be successful.

And so one of the big challenges I have with our industry is that is that we want to try to do practices first. And the big reason is, is because it’s kind of an easy button, right? We can get trainers to come in, we get coaches to come in, we can teach practices, but we don’t really have to make any hard organizational changes when we do that.

Does it work? Maybe it works sometimes. Maybe it works in pockets. But for enterprise class stuff, practices first is never, in my opinion, the right way to go. Obviously, the other thing I talk about a lot is the idea of culture first, that if we can get attitudes, mindsets, beliefs, behaviors to change, then agility will happen, you know, again, in the presence of dependencies and presence of large corporate systems and the presence, the presence of legacy monoliths, all that kind of stuff, it just doesn’t work that way.

So so that was like my core point. And then so the controversial the controversy statement said this tweet challenges the conventional idea of implementing practices first, proposing that systems structure governance should come first. So that was catchy and and what I thought was interesting is that based on all these large language models, it kind of agreed with me that this idea of practices first is an dede are conventional wisdom.

That’s what the preponderance of information on the Web has to say about it. And so then the rebuttal to that was while alignment of structure and governance is important, the emphasis on systems first could lead to an overengineered, inflexible environment, iterative and adaptable practices can drive effective, Agile Transformations. So what’s fascinating is in some of these responses that Chad GPT gave, I understand why they gave them, but if you look at what the what catch up is doing is it’s taking the information that is publicly available in effect kind of the general consensus.

And it’s giving me a rebuttal based upon the general consensus. And so like so the way that I would think about this is that is that, yes, if you put in a large scale static structure, you put in a a governance model that was inflexible, you could absolutely create a rigid hierarchy that was not responsive to change. But but there’s kind of like two different things that are at play.

When you’re talking about Agile, There’s there’s like the agility of the product backlog, the agility of the work that we run through the system. And then there’s the agility of the organization itself. So a lot of times in an early stage transformation, what we have to do is we have to put a certain level of rigidity in place so that we can demonstrate to the organization that any new Agile world we have the ability to make and meet commitments.

We have the ability to do what we say we’re going to do. The thing is, is we just do it in much smaller batches at the team level. We’re talking about user stories and sprints and releases at the program portfolio layer, the investment tier. We’re talking about much smaller batch sizes of features, EPIX initiatives, things like that. When you do that, you can tie all of that up into OKRs and KPIs and connected strategy and and get a really clear idea of how the strategy of the organization, the investment thesis, is being cascaded out and articulated into the organization.

So you come in with a lot of structure and then you you increase the ability to adapt by breaking things into smaller pieces and creating a system where we can kind of sense and respond a little bit more. Now, the approach that we take to doing this is we tend to start with like business capability models. We look at kind of the domain driven design of the organization.

We look at product model hierarchies, we look at the org chart and we create hypotheses for how we want to form teams around this notion of things that the business cares about. Now, what’s interesting is that for the most part, not every organization, but for the most part, the preponderance of things that the business cares about are not incredibly dynamic.

Okay? But if you go through this transformation. So in our world, Basecamp, one, two, three, four and five, we put a fairly rigid hierarchy in in the early days so we can make any commitments. But then as we start to, you know, systematically reduce batch and break dependencies and change funding models and then change, you know, go to market strategies and things like that, what we do is we inherently decouple the the in effect, the organizational model, the legacy technical monolith into smaller objects.

Now you think about if you want an organization that is resilient to change, it has to be organized around individual elements that can be easily changed. Again. It’s just like, you know, think about like a 50 year old COBOL mainframe system. If you want to change one small little thing or change, you know, some behavior of something in that system, it’s inherently coupled to everything else in the system.

Same things with organizations. So this argument that if we start with structure that it’s somehow going to lead to greater rigidity, I would actually suggest it is the exact opposite. If you lead with structure and you understand what it is that you want to encapsulate, which big things you want to break into, smaller things you actually create a lot more fluid in the organization so that you can take those objects and you can point them at new things, new opportunities.

When those new opportunities exist. Now you could say if if the total business model is being disrupted, then you know, would that would that cleaning strategy? You know, we get into things like, you know, do you just have people float across projects dynamically and stuff like that? Like if again, I don’t dismiss that there couldn’t be an environment where that level of fluidity was required.

I just know through our experience with working with a lot of Fortune 100 and some Fortune ten companies, is that is that that level of fluidity is not the norm. That level of dynamic resource allocation is not the norm. And I’m not saying you can’t go there, but you have to meet the organization where it is. And so again, I’m going to to make the assertion that chatbot in this case is actually incorrect because it’s based upon this general understanding that if we start with practices, then we’re going to achieve the right kind of agility, Agile practices on top of a legacy COBOL mainframe, Agile practices on top of a functionally siloed hierarchical organization are

not it’s not going to work right. The reason why we believe it will work is we say if we just start with the practices and the organizational and spec and adapt and it will, it will deconstruct itself into objects. I just don’t believe that to be true. Right? It’s very similar. And this is the this is the bigger point that I was going to make.

There’s there’s a lot of things and a lot of things being talked about in the broader IP product development context that I think are super interesting. And I’ve ignored a lot of these words because I don’t I don’t fundamentally like the buzzword bingo that we tend to play in our industry. And so like back in the day, you know, we had, you know, whether it be rational, unified process or scrum or say for XP or whatever, but before that critical chain project management, we had Lean concepts.

You know, Six Sigma was, was all the rage. Nowadays we’re talking about digital transformation, we’re talking about composable enterprises, we’re talking about product driven organizations, we’re talking about projects to products, all that kind of stuff. What’s interesting is I finally decided over the last year or so that I was going to start engaging with some of that language a little bit with our clients.

And at the end of the day, like what? What organizations are hunting is exactly this thing that we’ve been talking about. It’s the technologies are largely legacy monoliths. The organizations are largely legacy models. And so my belief is that the key to breaking up organizations, the key to composable enterprises are product driven or PTO or projects. The product is this idea of taking monoliths and breaking them into services or taking monoliths and breaking them into smaller products.

Right at the end of the day, if I want to do a successful digital transformation, if I want to do a successful cloud migration, if I want to do a successful air transformation, that’s something that’s being talked about right now. If I want to do a successful cloud migration, maybe I already said that. But any of these things that fall underneath that umbrella, it all comes down to how do you systematically take big things and break them into small things?

Because at the end of the day, what actually allows for agility is small groups of people that are organized around a technology that have a singular focus on us, on a particular kind of business problem. And then, you know, again, think services oriented architecture, think, you know, smaller abstracted products moved to the cloud. Right. And and what we’re trying to do is we’re trying to get the people and the process and the technology and like everything encapsulated into a thing, they can make independent decisions.

They can respond at the speed of market. And again, in these large systems. Right. What the problem is, are you got all these dependencies. And so the the process of moving to Agile is about taking big things, breaking them into small things, minimizing the dependencies and then orchestrating the dependencies that exist. And I’m going to make the argument over time that it’s the same for digital transformation.

Like anything that we want to do with new digital products, new digital strategies, digital channels, digital innovation is going to require these same kinds of loosely coupled, the same kinds of loosely coupled independent teams, typically using Agile but not required. But typically in Agile, it’s the decomposition of the big things and the small things that matters. It’s inherent in the word composable organization, composable enterprise with it basically means is that we have an organized may an organization made out of services and those services can be composed into higher order things that we want to sell to our clients.

It’s inherent in this idea of product driven organization. It’s inherent in this idea of projects, the product in order to do projects, the products you fundamentally have to have your organizational design organized around those products. And what does that mean? Taking big things, breaking them into small things. The idea here is that there is no way from here to there if we are only thinking about Agile practices or we are only thinking about Agile mindset, because at the end of the day, those practices and that mindset is going to go head on into like the skeletal system, the infrastructure of that organization, the way that it is structured, the way that it is governed, the

way that it is measured, is going to be totally orthogonal to the practices and cultures that you’re trying to get to. So you can start with practices and cultures and try to back your way into the structural elements. But what we believe is that if you start with the structural elements, you take the big things, you systematically break them into smaller things.

You work on reducing batch size and breaking dependencies and increasing local autonomy and giving those smaller objects some degrees of freedom. Through that core transformation effort, you get the fundamental underpinnings of digital transformation. You get the fundamental underpinnings of the composable enterprise. You get the fundamental underpinnings of the product driven organization. You get the fundamental underpinnings of a of a project to products type infrastructure, right?

You want to do product innovation, you want to do digital, any of this stuff. It goes way better if you have an organization that’s just built natively to support it, right? So the core is this idea of transformation, whether it be Agile, digital, composable products or otherwise. And so I’m going to go on record saying I think, Chad, GBP is wrong on this one and LeadingAgile got it right. So you guys have a great day and we’ll see you next time. Talk to you later. Bye bye.