Agile Governance Demystified

What is Agile governance? Simply put, Agile governance is a way to maximize the flow of value within an organization in the fastest way possible. Seems straightforward, and it is when you’re applying it inside a relatively new and small organization. In small, lean startups, there aren’t a lot of legacy processes and systems in place to overcome, and your teams are small and conducive to an Agile governance model.

But applying Agile governance inside a monolithic organization with legacy systems and thousands, if not tens of thousands of employees, can seem quite daunting.

So, we’re going to take the guesswork out of Agile governance and pull back the curtain on our three-tiered governance model. We’ll take a tier-by-tier glance at how we think about maximizing the flow of value inside large organizations and show you some of the things you should consider when scaling Agile inside your organization.

The Foundation of Agile Governance

You can’t have an Agile governance model without people and work for the people to do. If you didn’t have those two things, you wouldn’t have anything to govern. And while this might seem like a trivial statement, we can assure you it’s not. The foundation of a good governance model is in the structure and how you bring work to the people within it. Said another way, organizational design is critical to the success of your governance model.

The picture below demonstrates how we usually structure our three-tiered governance model.

Now, let’s take a quick look at each type of team.

Services Teams

Services teams are a particular class of product teams who are typically responsible for an area of a product that’s shared by multiple product teams. In a certain sense, the services these teams provide are a product in their own right. Usually, these teams are staffed by developers, testers, analysts, and any other specialists needed to deliver against their product backlog.

Feature Teams

Feature teams are what most people think about when they think about Scrum teams. A cross-functional group of six to eight people who have everything they need to deliver an increment of working tested product at the end of every sprint. Usually, these teams are formed around an individual product or business capability.

Program Teams

Program teams are needed in more complex organizations and sit between the strategy layer we’ll talk about here in a minute and the delivery/services teams. Their main priority is breaking down epics into features and features into user stories. More on this in a little bit too.

Portfolio Teams

A Portfolio team is a group of leaders who are responsible for identifying business needs, approving funding, and establishing time, cost, and scope constraints. They meet on a regular cadence to move high-level work items through the system of delivery.

*A Note on Team Formation:

At the Portfolio and Program level, we want teams that are built in such a way that they have all the different points of view and concerns within an organization represented. To get good at answering what is going to build, how we’re going to build it, what the details are, and what the schedule looks like, you need a certain mix of people. That said, each of the teams at this level typically has someone to represent the architecture view, the product view, the project view, and the analyst view inside an organization.

Now that we have a good understanding of how the Agile Governance model is structured, let’s begin taking a look at how we’re going to bring work to the teams.

Managing Flow in an Agile Governance Model

At each layer of governance, we want the teams to have a known backlog, stable velocity, and the ability to anticipate time and scope. Basically, what we’re trying to do with the governance layers is make sure that the work is flowing the way it should. That all the dependencies between teams are made visible and escalated so that we can manage them or break them when the time is right.

When we start thinking about how we’re going to sequence the work through the organization in a way that accounts for what we’re trying to accomplish, it looks something like this:

• Portfolio teams running epics through something like corporate governance phase gates. Let’s call them Gates 1-4.
• The Program teams are running featured through a Kanban-style board also. We tend to think about the various statuses as analysis, design, build, test, and deploy.
• The Feature/Services teams are working off a more traditional Kanban framework; not started, in process, done.

So, the goal is to get epics at the Portfolio tier of the Agile Governance model to flow across the board as fast as we can. We do this by getting features at the Program tier across the board as fast as we can. And we do that by getting user stories at the Services/Feature tier as fast as we can.

However, before you can begin doing any of that, we must first get proficient at decomposing the work at the top of the governance model into the kind of stories that can get moved quickly across the board. And getting proficient at decomposition starts with reimagining what a story even is.

Decomposition in Scaled Agile Governance  

Let’s get a baseline going for how we think about the work. In Scrum, we often think about stories from a user perspective. We build story maps where we create a persona and imagine their user journey to help inform the work we’re going to go and do.

In the early days of LeadingAgile, we started thinking about what this process looked like at scale and how we could apply it in a way that was more meaningful to the business and the executives that run it.

We landed on this idea of something we called a value story. Basically, what can we deliver to the market that someone will actually pay for? We know that executives are making decisions, and there are dollar amounts attached to these decisions. So, we started thinking about Epics at the portfolio layer as investment increments.

If the goal is to move these investment increments across the board in the fastest way possible, then we need to understand the constraints. Whether it be time, cost, or scope, we must have the ability to decompose this work in a way that’s respectful of the constraints. So, we must hunt for an MVP investment increment. What’s the smallest amount of value we can deliver within the constraints that someone will pay for so we can maximize the investment?

So that means that the Program tier’s job is to decompose the Portfolio epics into features that are aware of the constraints as well. They’ll run those features through their layer of governance with an emphasis on getting the highest value featured done first to maximize the investment of the organization.

It’s at this middle tier where the secret sauce of our governance model is located. If you recall, earlier when we talked about team formation, the Program teams have all the various points of view in the organization represented on their team(s). So, they’re uniquely positioned to not only understand what it is we’re trying to accomplish but also what it’s going to take to go and execute the plan.

So, the Program teams are not only in charge of decomposing the Portfolio epics into features, but they’re also responsible for turning those features into stories that are aware of the constraints at the Portfolio level.

The benefit of thinking about the work this way and having that middle layer act as a translation hub is that every feature and every story is tied to something that executive leadership has a vested interest in. It’s hard to get leadership to see the value in Agile when it’s seemingly disconnected from the things they really care about.

Explicitly linking value to all the work moving through each layer of governance adds a ton of clarity and purpose to the system of delivery and makes it easier to make decisions and defend choices along the way when something inevitably changes and the organization needs to pivot.

Dealing with Bottlenecks

Ideally, in an unconstrained system of delivery, we’d insert work into the Services/Delivery tier backlog, and they would just work on it in priority order until it was done. As stories got done, we’d see features moving smoothly across the Program tier, and every few weeks, epics would begin passing through Gate 4 at a regular pace.

That said, something that organizations must be aware of is the parts of the system that may act as bottlenecks and cause the work to flow asynchronously across the various levels of the Agile Governance model.

The reality is that when we build a system, especially a system of systems, we know we’re going to have bottlenecks. Especially when we’re dealing with Services teams that multiple parts of the organization rely on. We might have teams that don’t move as fast. Or teams that have more demand on them than other teams.

So the Program team’s job is also to ensure that they’re sequencing the work in a way that respects where those bottlenecks are and still maximizes the flow of value through the organization so that we can maximize the business’ investment.

The good news is that as these bottlenecks reveal themselves, it gives the organization a clue as to where they might make an investment to make a meaningful improvement to the system of delivery and how you’ll address it.

After all, when you have a bottleneck, you only have three options:

1. Elevate it by throwing more money or people at the problem.
2. Subordinate the system to it and have the work move slower
3. Exploit it by having the Program teams build part of the solution 

Agile Works If You Work It

We’ve spent the last 12 years or so implementing this type of governance in large organizations across a wide array of industries. We’ve had a ton of success with it too. But it all boils down to taking the aspects of Agile that work and thoughtfully applying them to an individual organization’s specific set of constraints, bottlenecks, goals, and desired business outcomes.

Agile is easy in the micro. Harder in the macro. But it’s never impossible, and it works when it’s done right.