Agile Transformation Requires More Than Agile Practices

Many people believe that the practices associated with Scrum and SAFe will reveal what’s getting in the way. They assume that, over time, the ScrumMaster and the team will have the ability to resolve those impediments. But what happens when the teams run up against a tightly coupled mainframe system, or cross-cutting concerns amongst multiple teams, and dependencies in the technology stack? Agile begins to break down because these impediments are outside the teams’ span of control. So, you’re going to need more than Scrum and SAFe. You’re going to need a plan to deal with the things that are getting in the way of Business Agility. 

Video Transcript

If you’re thinking about going through and doing an Agile Transformation, training is important and we believe in training and people need to have skills transfer. But if we don’t get the underlying buying attributes of the organization, if we don’t get the underlying System of Delivery right, then what we’re going to end up with a lot of people doing Agile practices and like the phone calls we get, not getting the business benefit from it.

(Music Interlude)

Hey, everybody. Thanks for joining us today. Over the next few sessions, we’re going to explore the topic of Agile Transformation and some of the common misconceptions we see around Agile Transformation. The first thing you should know if you’re not familiar with LeadingAgile and what we do, is that we are a boutique consultancy based in Atlanta, Georgia, that focuses exclusively on helping companies adopt Agile more effectively.

One of the biggest things that we see and that we believe, and we think is a huge barrier to adopting Agile. What makes Agile unique in a way is that Agile is largely dependent upon how you structure your teams, how you do governance, how you do metrics, how you do planning. One of the things we talk about internally quite a lot is the idea of encapsulation and orchestration.

So Agile, in its an ideal state, requires a really high degree of encapsulation at the team level, at the work group level, at the organization level. In short, what that basically means is that any time we have dependencies between one part of the organization and another part of the organization, or between one team and another team, that’s going to reduce our ability to be Agile.

If you think about it, it makes a ton of sense because if I am connected to somebody, right, we have a deliverable that requires us both to work on it in order to create something of customer value, then we have to coordinate. At scale, sometimes that level of coordination can get totally out of control.

And so, the common misconception that we see is that Agile is a set of practices. It’s something that you can go to CSM training, or go learn about the Scaled Agile Framework, and then just go start doing. What seems to be underneath this misconception is that if we just start doing the practices associated with Agile, if we just start doing the things that are in Scrum and the things that are in SAFe, that we will identify our impediments and that over time the ScrumMaster, or the team will work to reduce those impediments.

Basically, what we’re seeing is that when we go into large-scale organizations where there’s like, you know, tightly coupled mainframe systems, dependencies between different teams across the organization, really complex requirements and, you know, integrations and such that are happening at scale. What tends to happen is that when you start applying the practices of Agile, that these dependencies, these impediments, get in the way and they’re largely unresolvable at a team level.

And so, what happens in practice is that people are going through the motions of doing Scrum, but they’re not actually getting the business benefit from it.

When somebody calls up LeadingAgile and says, Hey, you know, we’re interested in doing some Agile Transformation work with you, a lot of times what they’ll say is that we’re doing Agile, right. And that we’re actually good at it, but we’re actually not getting the results. Almost always that comes down to how you form teams, what you’re forming teams around, how you’re generating backlogs, how those backlogs are tied to and nested up underneath corporate strategy.

Can we get to a place where we do a working tested increment of software at the end of every sprint? Because what we found is that if we can create teams like that that operate with that level of independence, with really clear backlogs and have the ability to produce a working tested increment—Scrum is a fantastic methodology.

Scrum and XP, you know, with all the craftsmanship stuff, excellent ways of building software. But largely dependent upon the idea of teaming strategies, right? Encapsulation strategies, backlog strategies and working tested software strategies. So, what we tend to recommend is let’s get your teaming strategies together first. Let’s figure out how we’re going to get strategically aligned backlogs, and how we’re going to connect those backlogs into a lightweight, Agile governance framework.

And then how are we going to hold those teams accountable for actually producing something of working tested value, and not only get stable velocity the team level, but steady flow across teams at the program level, and steady flow across teams at the portfolio level.

So, if you’re thinking about going through and doing an Agile transformation, take that into consideration. Because training is important, and we believe in training and people need to have skills transfer. But if we don’t get the underlying attributes of the organization, if we don’t get the underlying System of Delivery right, then what we’re going to end up with a lot of people doing Agile practices and like the phone calls we get, not getting the business benefit from it.

So, thank you very much for joining us. We look forward to continuing this conversation with you and good luck in your Agile journey.