Planning Your Agile Transformation
Video Transcript
What is it that we’re actually going to change and how we’re going to get it there? Okay? We have to be really, really clear. This isn’t like make people aware of Agile and then they’ll just figure it out. All self-organized, right? We have to have a hypothesis. We have to have a point of view on what it is that we’re actually going to impact and how we’re going to impact and how the things we’re changing are going to tie back to our business objectives. And so the three things, if anybody’s ever heard me give this talk before probably four or five years ago, is one of the earliest iterations when I really started thinking about transformation and change strategy is that I talked about this idea of the only way to know if Agile is working is to test for the presence of these three things.
And we get hung up often on the practices and everything around Agile. And what we’ve lost is what are the elements of the ecosystem that make Agile actually work. And so what I’m going to do is I’m going to walk through what a scrum team needs to be successful. What they need basically is I’m going to, I guess I’ll walk through this. So I like to, I need to actually rejigger this. I like to talk about the middle one first. So a team in Agile is a group of six to eight people that have everything and everyone necessary to deliver something in their backlog.
On Forming Teams
A team typically has no external dependencies. Now, I know that doesn’t sound very realistic, but that is the ideal state. We want that team to be able to pull stuff off the backlog, to be able to deliver what’s in their backlog, and to be able to validate that it was done at the end of the sprint. So in my opinion, scrum doesn’t work, and unless we form the right kinds of teams, unless we form the right kinds of teams, we will never be able to establish a stable velocity. If we don’t have a stable velocity, we will never know the rate at which we are completing backlog. If we don’t know the rate at which we are completing backlog, we will never, ever be able to make and meet commitments. So a team is the thing, and so figuring out how we’re going to form teams enterprise-wide is a key element of going down this transformation journey.
Forming teams should not be an accident. It should be part of a strategic direction that you’re going down. Now, if you want to go super deep into this, you can talk about business capability analysis and the alignment of business capabilities to technology architecture to organizational architecture, and how you create strategies for doing this. There’s stuff, right? I touch on it in the paper just a little bit, but having a point of view on how to form the kinds of teams that can do Scrum is the key to success with Scrum is the key to success with large-scale scrum discipline, agile, delivery, SAFe, what have you. Okay? We need that team to be complete and we need it to be encapsulated. And ultimately we needed to have no dependencies. Go back. Where are we at? My goodness, this is not working very well. Okay, cool.
On Building Backlogs
Backlogs. So once we get the teams formed, they have to have their marching orders, they have to have their instructions and instructions for an agile team comes in the form of backlog. The product owner says, this is what we want to build. Team gets to decide how it gets built, and then they get to validate with the product owner at the end of the sprint. Most organizations that we go into do not build the kinds of backlogs that are necessary for a Scrum team to operate. They’re typically small. The team can do a handful of them in the sprint. They meet kind of Mike Cone, bill Wake’s, INVEST model, independent, negotiable, valuable, estimatable, small, testable. We can swap them in and out. We can just all the different things that make user stories work. The first time I ever did this talk was at a scrum gathering in Vegas with 500 Scrum enthusiasts in the room.
And I say, who builds backlogs like this? Nobody in the room raise their hand. Who forms teams like we need to form teams. Nobody in the room raise their hand. If we do not form teams that are encapsulated and we don’t give those teams clear backlogs, then that teams will never be able to produce a working tested increment of the product in some sort of stable velocity kind of way. The magic of agile that separates, in my opinion, agile from total chaos is if I know the size of my backlog, I know the velocity of my team, I get to a definition of done at the end of every sprint, then I can start to measure how much of the backlog I’m going to get through when my time runs out, or I can tell you how many sprints it’s going to take to get through it.
On Working Tested Product
So, if you can’t put together backlogs if you can’t form complete cross-functional teams, and then the last bit, if you can’t get to a working tested increment of software at the end of the sprint, then scrum is not going to work. And if Scrum is not working at that level, it’s not going to work at scale. So the transformation is really about how are we going to make that work. Not how are we going to teach people the practices of scrum, but how are we going to systematically organization-wide across 2.2 million people, get everybody into a team like that operating off of a backlog, able to produce a working tested increment of the sprint. That sounds like a way bigger job, doesn’t it? That’s way bigger than necessarily what we signed up for. The interesting thing is that it’s often way bigger than what your executive signed up for.
On Business Agility at Scale
The next thing I want to talk about is the expression of those three things at scale, because this is going to form the basis for how we start to think about the reference architecture or the fundamental underlying patterns that we’re shooting towards within our enterprise. So backlog at scale is fundamentally governance. And I know governance is a big heavy word and we don’t like to use it, but governance is basically how we make priorities, prioritization decisions, and how we make economic trade-offs in the face of scarce resources. That’s all. It’s the governance mechanism for a scrum team is the product owner. So governance is not ugly. It’s applied ugly often, but it’s not an ugly thing. So how we do backlogs at scale is governance. I’m going to talk a lot about the word structure. I introduced the idea of structure earlier, but structure is what is our organizational hypothesis for how we’re going to form teams?
What are we going to do to coordinate teams and to govern teams and what does that look like across the organization? This is where we start to think through what is the operational model within the enterprise that we’re shooting towards. So governance is backlogs at scale, structure is teams at scale, and then less direct is what I call metrics and tools. So what you find is that scale, the performance of any given team is not an indicator of the performance of the organization. The fact that your scrum team is awesome, probably actually doesn’t matter. What matters to us is how the overall system of delivery is performing and how those teams are working together in concert to overcome dependencies, to balance constraints, all those different things so that the whole organization can deliver with agility.
And so teams, backlogs, working tested software at scale start to become structure governance and metrics.
Planning for Transformation
Now, the next thing I want to introduce is once you understand that, now we have to look at where is the organization. And again, this is a whole talk unto itself, but I’m just going to blow through it. What my hypothesis is, and we found this to be a very useful thinking tool, is that most organizations are built for one of two things, predictability or adaptability, predictability or change. PMO, you’re built for predictability. You’re pure play agile, you’re probably built for adaptability. Markets are similar. Markets are built for what I call emergence or convergence. Either I’m inventing something new and I’m figuring it out, or I’m trying to converge on fixed time and costs and scope. Depending upon how your market receives your work and how your organization is built, you can basically be what we consider in one of four states.
The first two states we started talking about were predictive convergent and adaptive emergent. When I was building this model out, I was thinking traditional organizations versus agile built for predictability, fixed time, cost and scope, built for change, trying to figure it out as we go. As I started noodling on it a little bit, I didn’t realize that I had actually invented own little two-by-two quadrant. That’s how you’ve arrived. When you have your own two by two, that’s your good. And so the other two quadrants are the predictive emergent quadrant and adaptive convergent quadrant took me a while to figure out adaptive convergent, but the predictive emergent quadrant was really obvious. Anybody in a situation where they have big heavy PMO, annual planning cycles, budgets, all this kind of stuff, but stuff’s changing around you all the time. Anybody? Oh, come on. You guys are lying, right?
I mean, seriously, right? That’s where everybody in large organizations is. Okay? So you’re trying to put all this really structured discipline governance around it, but stuff’s changing so that quadrant feels very chaotic. The lower right is really where agile lives actually, and it’s about making meaty commitments, but in smaller batches. So the way that this kind of played out is the predictive emergent quadrant is ad hoc, chaotic, heroic. You’re probably getting something done, but it’s fire drills, death marches, things are falling out of the portfolio. You’re working on the highest things, but you’re not getting everything you planned done, okay? The lower left is where traditional typically lives. The lower right is where we put Agile as a home base, and the upper right is where lean startup goes. And so think about it, upper rights like r and d, lower rights making in competing commitments in smaller batches, lower left is more traditional.
The idea is that more often than not, you don’t have the ability to form teams and create structure. You don’t have the ability to get clean backlogs and to do governance. You don’t have the ability to produce working tested software and to create metrics and flow across the whole system. You’re probably in a quadrant. You don’t want to be in trying to move to a quadrant that you can’t actually go to. Am I depressing you guys yet? And so you’re like, you need a plan. That’s all I’m saying is you need a plan. And so what we do is we talk about most of the companies, and this is probably people self-select out before they call us, but people that call us tend to be in the upper left quadrant dealing with all kinds of low trust issues. A lot of times what you have to do is you have to come down into the lower left.
On Creating the Conditions for Agility
You have to stabilize the system in place. You have to get predictable, but not doing waterfall. We’re going to do something with lean agile there. As we start improving the system, we start being able to reduce batch size. We start being able to break dependencies. We start creating the conditions where we can form teams, build backlogs, produce working tested software, do structure governance and metrics at scale. We can home base down in the lower right quadrant, and then for the pieces where we can truly break dependencies and let teams operate with autonomy, we can fully decouple and get up into that upper right r and d lean startup kind of quadrant. So it creates this model. So take it back with you. It creates some really rich conversations. It’s not uncommon for me to get a room full of executives and to walk through this and they think they’re in different places and they think that they’re heading to different quadrants.
Can you imagine trying to lead a transformation where the executives can’t agree on which quadrant they’re in, or they can’t agree on which quadrant they’re going to? So it’s a focusing tool to help figure out where we are now and where we want to get in the future. It’s an alignment tool with the organization. And so my fundamental theory of transformation is that adopting Agile is about forming teams, building backlogs, producing, working, tested increments of software. Its scale. It’s about forming networked team structures, adaptive governance models, and a metrics and tooling program that enables agility.
The Work of a Transformation
And here’s the money slide. Anything that gets in the way of doing those three things, technically six, but we’ll just call ’em three because it rings better. Those three things is an impediment to transformation and it has to be removed. So creating the conditions to form teams, build backlogs, produce, working tested software is the work of the transformation. It’s not training people, it’s not introducing Scrum, it’s not introducing safe, it’s not doing all the other things. It’s not hiring Scrum masters. It’s not calling people product owners, it’s not doing daily standups, it’s none of that. It’s about creating the conditions organization-wide to create teams that can operate with autonomy that are operating off of really clean backlogs that are tied all the way up to the strategic governance and to be able to produce a working tested increment. Anything that gets in the way of those three things is the work of your transformation.
And so solid agile practices are going to help operationalize the system. We’re going to create alignment across the organization. We’re going to try to help culture emerge over time. All that stuff’s important, but if we don’t get the fundamental ecosystem of the enterprise working, there’s an absolute incongruence. There’s cognitive dissonance between what you’re asking people to do and the world that they live in. And if there’s cognitive dissonance between what you’re asking from a behavior perspective and what they believe can actually happen, you’re going to get resistance to change, period. So we got to get the structure, we got to get the practices, we got to get the mindset shift, all of that stuff. We have to get it into alignment. And that takes time. You guys with me? Okay, cool. Okay. So how are we going to start to get there? So I’m going to introduce just kind of a general pattern that we’re going to use for the rest of the talk.
So first of all, we want to decide really if we’re in the methodology. I got a couple of folks in here that I know that I know are adopting SAFe. SAFe is totally fine. I think SAFe is awesome, but even SAFe requires a specific kind of ecosystem to operate in. You want to do large-scale Scrum. It requires an ecosystem to operate in. And so what I did is I kind of took a stab at trying to figure out where would these different methodologies be in our quadrants? This is kind of an imprecise thing, but you can start to see how the different methodologies spread as you’re choosing a methodology. What you have to think about is what is the methodology most likely to yield the business benefits that I want that we talked about in the first business case. What is the value system of my organization and my customer?
What are my size constraints? What are my dependencies? What are all those different things? And based upon orienting to all of that, you have to decide what’s possible today, and then you have to create a list of the things that you need to fix to get into the system that you want to be in tomorrow. And then one thing that I kind like to do is anybody, Gartner, Gartner Mode I, Gartner Mode II, you guys talking about that. The other thing that I just want to give a nod to is you guys are thinking about your theory and approach to transformation is that Gartner Mode I. Gartner Mode II doesn’t mean Waterfall and Agile. What it means is systems of record and systems of innovation. It means things that have to be structured and disciplined and controlled versus things that can move fast. It’s APIs versus app stores, right?
Closing Thoughts
I can innovate all day long up in my mobile and up in my web, but what about that mainframe transaction process processing engine on the back? So sometimes, and this is the reason why I put this slide in here. Sometimes we want to be more agile than the business problem we’re trying to solve necessitates. And what we generally find is that most organizations of this level of scale that we’re talking about, give or take, 2.2 million, that kind of a thing, 80%, 60% probably need to be lower left quadrant. They need to operate in a incredibly structured, disciplined form of agile. There’ll probably be another 20, 30%, maybe not that much, that can go straight to the upper right quadrant. Some will camp in the lower right quadrant. There’s going to be some pieces that need to move all the way through the stack. So just because we can do lean startup doesn’t mean we necessarily should do lean startup, certain business problems, certain technology environments, certain whatever, don’t require it.
These are all things that go into forming how you’re going to tell the story. Once you have all of this stuff sorted out, you can begin to start mapping the journey. And so we kind of coined this little thing we like to talk about called base camps. And the idea is is that I’m going on a journey. I’m taking a group of people with me called an expedition, and I’m moving them through a series of intermediate steps to help enable agility as I’m improving the system. And so a very common path, this isn’t the only path, but a very common path through this material is that I go to base camp one, I stabilize the system, then I get some predictable results, and then I start reducing batch size. Then I start breaking dependencies, then I start doing team-based funding. Then some of that, I start to go and do RD around.
So what you can start to think about is, I know where I’m at today. I know where I’m going to get in six to nine to 12 months. So what are the intermediate steps along the way that are going to help me stabilize the system that I have in place to start to lay the foundation for where it is that I want to go? And then as I improve the system over time, then I can start to deprecate some of that control. One of the guys that works with us on our leadership team is a guy named Chris Beal. He’s running our largest account right now. And when he joined me, he didn’t fully have his head around what we were doing, and he kind of summarized it in a really cool way. He said, it’s about organizing for the company that you want, realizing that all the pieces are not in place, putting compensating controls around it to help it deliver better.
And then as we improve the system starting to deprecate some of that control, it’s not, you can’t expect it to happen overnight. There has to be a stepwise process. We’re building mission-critical systems for our companies, and we don’t have the luxury of stopping production while we retool the line. We are retooling the line in place. Okay? It’s the only way that I can think to safely and pragmatically do it. Okay? Create a plan. Recognize that we’re not going to get all the way to where we want to be on day one, but to create a stepwise measurable approach to leading change focused on removing the impediments, reducing the organizational barriers to forming teams, building backlogs, producing working tests and software.