Agile Transformation is a Journey

Agile Transformation isn’t about a big-bang rollout of Agile, and then Presto! You’re done. It’s about meeting the organization where it is today, and iteratively and incrementally rolling out Agile capabilities over time. As your ability to be Agile matures, today’s Transformation will look a lot different than your Transformation a year from now.

Another reason why you can never really be done with Agile Transformation is that the market is constantly shifting and your customers needs will change. That’s not to say that you need to have consultants on the ground forever, but it is to say that improving the organization, maintaining its ability to inspect and adapt and respond to change, will be an ongoing initiative that is never finished.

Video Transcript

Agile isn’t something that you just install, and you’re done with, but it becomes part of not only how you’re thinking about managing work, but how you’re thinking about adjusting the organization to satisfy the long-term needs of your customer.

(Musical Interlude)

Hey, everybody. Thanks for joining us. We are continuing our conversation around common misconceptions around Agile Transformation. So, we’ve covered things like is Agile transformation just as simple as learning practices? We’ve tackled the issue of is Agile culture change? Do I need to change the culture in order to be able to create an Agile operating model? We talked a little bit about one of the common misconceptions being that if I just get my teams working, it doesn’t matter what the rest of the organization does. We kind of tackled that from the perspective of it has to be an integrated operating model across the entire business to really achieve the business benefits of doing Agile at scale.

The last common misconception that we’re going to cover is the idea that Agile Transformation is a one-time event. Now, here’s the interesting thing about that. Can Agile Transformation be a program with a start and finish? Yeah, 100%. I mean, that’s kind of what LeadingAgile’s bread and butter is. You know, we come in and we take a look at the organizational design, we look at the business architecture, the product model hierarchies. We look at the technology architecture. And you can create an operating model that is team-based with lightweight, flow-based governance at the program and portfolio layer. You can tie that up into OKRs and KPIs.

That is a system that can be designed. And then you sit there, and you think about, okay, how do we incrementally and iteratively install that system into an organization? How do we go through and how do we form teams, how do we install the new governance, how do we put the new metrics and controls? Once the system is performant, how do we start to teach the business how to exploit that system to its economic advantage? Those are all things that you can do, and those things do indeed have a start and a finish.

What we generally find is that the things that you need to do in an early-stage Transformation, in the presence of dependencies and while you’re creating the conditions to really do Agile at scale, sometimes you need more governance, more control, more planning than you would like to end up with. So, what I would suggest, maybe the first thing to tackle in this misconception is that when you’re thinking about Transformation, you think about Transformation like a journey.

You can do certain things in an early-stage Transformation, but there’s compensating controls that you need to put in place because you haven’t fundamentally improved all of the underlying, really dependencies and staffing issues and all the different things that get in the way of being able to do Agile well. You haven’t actually improved those in an early-stage Transformation. But there’s a lot of Agile you can do. And then as you move and you start fixing how the organization is staffed, how it’s run, where the dependencies exist, how the dependencies are managed, how batch sizing is happening in the organization, you can start to improve the underlying operating model and start to deprecate some of the planning. And you can start to deprecate some of the dependency management. And you can start to operate more in a pure play way. Okay.

So, the idea that Transformation is a journey, and the Agile operating model is going to look different over time as the system improves. That’s one angle that we want to cover. The second angle that we want to cover is the idea that the organization itself also has to be able to respond to change over time. And so, the business capabilities and the product areas that we organize around, we have to be constantly mindful that those capabilities are reflective of the needs of our customers. So sometimes macro-level economic things change, sometimes the needs of our clients change. So not only do our backlogs and teams have to be responsive to change, but our organization and how we deploy our capabilities to satisfy customer demand. That also has to change sometimes as well.

So that’s where you get from the idea of doing a, you know, a one-time Agile implementation, you know, maybe via like an Agile Transformation Office to actually creating some long-term support. So not only can the backlogs inspect and adapt over time, but also the core organizational design and what we’re deploying our assets towards to where that can change over time.

Point being is that Agile isn’t something that you just install, and you’re done with, but it becomes part of not only how you’re thinking about managing work, but how you’re thinking about adjusting the organization to satisfy the long term needs of your customer. So anyway, thank you so much for being part of this conversation with us and we look forward to engaging with you in the future.

Have a great day. See ya’.