Structure, Governance, and Metrics on Large Scale Agile Teams

Okay… let’s recap my last two posts. My first post in this little segment was called “The Underlying Mechanisms of Team Based Scrum.” In that post, I tried to make the case that the rules, ceremonies, artifacts, and roles of Scrum… while an integral part of Scrum… weren’t what Scrum was really all about. Scrum is really about having extreme clarity around what we are going to build at least a few weeks out. Scrum is really about forming a team of people who have everything necessary to produce the product and are accountable for actually producing it. Finally, Scrum is about having a working, tested increment of the product that can be measured and compared against what we set out to do. This way we know how far we’ve come and how far we’ve got left to go.

My next post was called “Failure Modes of Team Based Scrum.” Building on the three themes of the previous post, I explored many of the ways that we see Scrum teams struggle getting clarity, accountability, and measurable progress… especially in larger, more complex organizations. Most companies struggle getting the right people together to product a well groomed, prioritized backlog. Most organizations really struggle putting together complete cross-functional teams. Even in the presence of a well-groomed prioritized backlog and a complete, cross-functional team… many organizations struggle to produce a working tested increment of the product every couple of weeks, and have no idea what they’ve produced or how much software is left still to build.

So where does this leave us? Well, it seems that in many organizations we’ve got some things to figure out before we can even really think about doing Scrum. First, we need to figure out what kinds of teams we are planning to form and how we are going to go about forming them. Next we need to figure out where teams are going to get their backlog, how much detail they are going to need, and how the backlogs of many interdependent teams are going to come together to product an integrated whole. Finally, we need to figure how what we are going to measure and how we are going to measure it. This is pretty straightforward at the team level, but can get more complicated as we start integrating the work of several teams that have to come together on an integrated product.

Remember this… we are going to see this again. Before you start your agile transformation, you need to understand how you are going to structure agile teams… how are we going to govern where the backlog comes from… and what we are going to measure so that we know we are making progress against integrated deliverables. In a simple, single-team Scrum implementation, this may very well be one cross-functional team, an empowered Product Owner responsible for creating the backlog, and the means to produce a working-tested increment of product, on a regular cadence, with a stable velocity, against a known backlog. This canonical expression of Scrum is one example of a Structure-Governance-Metrics triad that works in many smaller organizations.

In larger organizations this single team metaphor is likely going to break down. We are going to need a different set of constructs, a broader palette of constructs maybe, to express the Structure-Governance-Metrics needs of the more complex enterprise. As I’ve been noodling on these ideas over the past few weeks and sharing some of my ideas with Dennis and others on my team, we’ve been talking about the other more heavy-weight agile approaches out there, and using them as a way to understand our industry’s attempts at putting together patterns for doing agile at scale. If you think about it, frameworks like RUP, FDD, DSDM… and more recently SAFe… are all attempts at putting some language around the Structure-Governance-Metrics challenges we have with agile in large companies.

Okay… before we wrap up for the day, I want to put some language into play for the next few posts. When I talk about structure, all I’m really talking about is the pattern on which the enterprise is going to form teams. I think in the next post, we’ll talk about different kinds of teams we might need in a larger agile enterprise. Next, when I talk about governance, all I’m really talking about is how the organization defines what the enterprise is going to work on and how that work will get coordinated and communicated to the teams. Finally, when we talk about metrics… we need some agreement on what success looks like, from a product delivery perspective, and a means for measuring, assessing progress, and knowing if we are getting better or not.

I think what we’ll do over the next three posts is explore the Structure-Governance-Metrics framework and talk about how you go about making some of these decisions for organizations at scale. As always… thanks for hanging in there with me ;-)

Check out the next post, How to Structure Your Agile Enterprise.

Check out the previous post, Failure Modes of Team Based Scrum.