Leadingagile Blog Planning Your Agile Transformation

Video TranscriptWhat 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 TeamsA 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 BacklogsBacklogs. 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 ProductSo, 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 ScaleThe 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 TransformationNow, 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