System of Delivery: An Intro to Our Governance Model

Our governance model and team design may look a little complicated at first glance. However, there’s a lot of intentionality within our system of delivery to ensure that you’re solving the right problems, at the right time, to maximize throughput and the value delivered to your customers.

In this presentation, our Chief Methodologist, Dennis Stevens will remove the noise and walk you through our governance model and team design to help you better understand the LeadingAgile system of delivery.

View Dennis’ System of Delivery Deck

Video Transcript

So what I’m going to talk about today, I’m going to talk about our system of delivery and the intentionality that’s built into it to solve the types of problems that organizations run into that make it difficult for them to respond to markets, difficult for them to deliver value to their customers.

When you first look at our governance model or some of our team designs, it might look complicated, it might look really busy. But what’s interesting is, if you can understand how that governance model and that team design make sure that we’re solving the right types of problems at the right time to maximize throughput — to maximize value delivered to our customers — it begins to make a lot more sense.

So let me walk through that a little bit.

We talk about the goals of going agile. Just briefly, walking through this is you know: predictability, quality, early ROI, lower cost, innovation and product fit. And you’ll hear us talk about the way that you deliver that is by designing your organization so that the governance — the way that we manage the flow of value through the organization and make economic trade-off decisions — is defined effectively.

We talk about the structure — how we form teams and how teams interact together — is clear and we talk about having the right metrics and tools. But what problems are we actually solving for? There’s five classes of problems that we’ll talk about that that can get in the way of an organization solving problems.

The first one is the one around risk, around scope rather. Are we solving the right problem? Are we putting the right type of work in, in order to get the right results out of the organization. A really interesting thing happens in organizations where we spend a ton of time trying to get the scope really clear, is we don’t pay attention to some of these other categories.

Do we understand our capacity and the impact of how much work we’re putting into the system and our ability to be predictable and how much we can actually deliver? So we have to be able to talk about capacity and really understand how much work we can do.

We tend to make strategic decisions and project decisions that are not informed by the amount of technical debt or technical discovery that’s involved, until very late in the decision-making process. So we want to be able to have those technical debt and technical discovery conversations early and at the right level as were decomposing the work and feeding it through the system.

And then dependencies — dependencies kill us. Eventually, we’d like to get rid of all the dependencies, but when we can’t, we have to be very intentional about when we identify them and when we manage them.

And the final one is our quality of solutions. When are we learning whether their product is solving the problem? When are we learning whether it’s going to work as designed? And in a lot of cases, we learned that too late to create any optionality around resolving that as we’re learning.

So, if we look at our governance model this four-tier governance model, one of the first things to really get clear about is this word governance is overloaded in a lot of organizations. A lot of people look at governance as being,  “What artifacts do you need to complete? What are the behaviors, what are the checklists you need to turn in?”

To be really clear, the governance model here is shifting from controlling handoffs and accountability for artifacts to getting the organization to focus on the flow of value. Trying to create intentionality around who’s involved in which conversations when, and designing the delivery so that we’re going to get the most value produced as possible.

We also do these team designs. With who’s on the portfolio team, who’s on the product team, who’s on the delivery team? So that as they’re operating as the work flows through, they’re tiering the governance model. They’re — have the right people in the room, have the right conversation. So the team design, interacting with a governance model, focused on the flow of value, and managing those five categories of risk, are what our governance model and our team design do.

We’re talking about the system of delivery, that’s what we’re driving towards.

I’m going to do a simple walkthrough of the three-tier governance model to show how work flows through there. And then I’m going to break down a little bit more detail where each of these five categories of risk are handled. So here’s a three-tier version of the governance model. The portfolio team gets an epic. It might come in collaboration with the product team, it might come from outside the organization, but an epic starts in portfolio alignment. In conversation with the product team and the intake stuff, we’re focused on getting an agreement. Is this the next most important thing to work on, and is this a problem that we actually need to solve? And we understand the problem?

That epic then moves across to portfolio prioritization, based on a high-level estimate and all the other things that are in the pipeline, and our current capacity, is this the next most important thing to start breaking down for the organization?

As that epic moves over to solution definition, we begin to decompose it down into detailed features. The changes we’re actually going to introduce into the organization to achieve the outcome that’s defined in the epic.

As capacity starts to become available to do those features, we’ll move the features into release planning.

So here you see two features and release planning, and we’re breaking the stories and those features down to begin to make them ready. The epic has been targeted for release. We have an idea about when we’re going to deliver it. And, we’re starting to now interact with the team to break the stories down. As we start to finish stories and get stories ready for consumption, once all the stories in that feature are ready, that feature moves over to “Feature Ready” and we can actually start building that epic.

Here, we see an epic in process, and the delivery team is building the stories… Finishing up all the stories within it…  Moving that to done. And you see that feature moves over to “Feature Validation” while the stories are finished. We have all the features moving over and all the features are completed. We validate the epic, and the epic moves to completed.

So there’s a couple of important things here. One is, we’re trying to move work intact through this process. We’re not starting (by)writing every single feature on day one and delivering them on the last day. So there’s some importance to the order, the sequencing of these features.

Also, by having the work visible like this, and having our cadence of meetings and clarity of rules, we know what it means to be done with portfolio prioritization before we start writing code. We’re not starting the code and we’ll figure out the problems as we go and resolve them in real time, because that’s just not pragmatically possible to do in large, complex organizations.

So we break this down a little bit. The five types of risk: Are we solving the right problem? Are we optimizing for predictably delivering the most value through the organization based on our capacity? Does our tech stack enable or hinder our pace of change? Are we orchestrating across our solution component? And, is our solution solving the defined problem and does it work as intended.

When we get into “Are we solving the right problem?”, there’s a lot of product management work that can be done and here you see a list of 22 potential artifacts that might be being built. Some of them being built for each epic. Many of them are persistent but are being referred to as we’re having conversations around it. Around each piece of work. So one of the examples we would talk about is, there’s an opportunity canvas up at the investment level talking about why this is a market we’re going after, and what it means to solve that market and how important that opportunity is for the organization.

Down at the portfolio tier, then, we’re turning that opportunity canvas into an epic – an outcome that we’re going to deliver to the market that’s going to help us achieve the market strategy. Down at the program tier, they’re breaking that epic down into features. What are the pieces of functionality we need to deliver to the market in order for that epic – that outcome – to deliver on the strategy we intended. So these all inform each other.

So what’s important is that by understanding where this work is produced and which collaborations are taking place between the tiers, we actually know what artifacts, what staff work to do beforehand, to bring – to ensure that we’re generating shared understanding.

Again, it’s really important: the goal is not to produce the artifacts. The goal is to make sure we’re having the right conversations, with the right information at the right time. And that’s what we’re enforcing in the governance model.

When we start to talk about capacity risk, the challenge we run into — there’s this exercise that we run sometimes called the airplane game and in the airplane game Station 3.

There’s these four stations work has to go through all four stations to get to the customer and Station 3 has a lot more work to do. It’s harder to do their work than the other station. So as we start to run through the simulation, what you find is at some point, the organization a ton of work begins to pile up. And what that means is after some point in time, it’s very difficult to predict when the next piece of work will get through the system. Because it’s backed up by this pile of airplanes at station three. You can imagine this being developers, or requirements, or testing in an organization. The point is that pushing stuff into the system faster than you can pull it out actually makes the system very unstable. It makes it very difficult to be predictable. And, starting work earlier actually slows you down and creates problems. It doesn’t speed you up.

Our visualization of the kanban boards lets you begin to understand what your maximum capacity is for throughput and what the actual state of work is in the organization. Work that’s piling up at basecamp 3, at Station 3 — at Station 3 in this case, is work that’s actually going to make the system unstable, unpredictable, impact quality, and make people generally miserable as well.

What we’d like to do is, we’d like to balance capacity and demand. So we need to understand what our capacity is. We need to put work into the system at the rate that we can pursue it. The  Kanban helps us do that. The governance model makes that actionable. The other problem we run into is, when we have multiple items that we’re working on, that all need to get finished, and they’re all equally important.

In this example here, you see that we’re working on all three pieces of work through a team, all at the same time and everything gets delivered in Period 9.  What that does is that takes away all of our optionality. There’s no way to apply learning. There’s no way to actually test and validate that we’re building the right things till we get to the end. And so what we want to do, is we want to be able to flow work through in a more cohesive fashion.

So this is limiting WIP and making work flow. Following the governance model helps us instantiate this new organization. It also begins to make it really clear to us what our capacity is and when to apply it. Here’s an example of — we’ve done the work, we’ve delivered everything in Period 9. Another example is to actually work on the work and finish work, schedule work to completion and finish it, which finishes everything in the same time, theoretically, as the previous version. Actually, it probably finishes it faster because we’re not having to deal with the impact of increased coordination and task switching, and the burden that working on everything at the same time puts on the whole organization – so, we actually probably get work through faster.

The other thing we get by operating this way, is we begin to get the ability to adapt to options. So we’re getting A done. Partway, a critical new piece of requirement comes in. In this case, it’s D. We can work on D, and it’s sort of without disrupting any of the work. We can then continue working through, and do the lower priority features, and finish work as we get it done.

In this case, we were actually still able to deliver B and C on time. And, in fact, because we minimized the amount of work we had to deliver in B, it created capacity for us to deliver all the rest of A. So we still delivered everything on time. We created some adaptability in the system. So this is how we learn to manage capacity.

Where that comes from in the governance model is understanding when features are completed, how frequently I can deliver working tested product out the back, not just how fast I can write the code, but how fast I can get it ready to ship. And then we use that information when we’re doing our release planning and our story mappings. Our governance model instantiates the flow but also gives us the data that we need in order to effectively manage it.

An example of the type of data that Lean Metrics and the problems that we’d be measuring — shifting from shoving everything through to this flow model, you’d see improvements in all of these metrics across the organization.

The technical debt and discovery problem is, real often when we’re starting work that’s not only capacity unaware, we’ve defined strategies that are technically unaware. We don’t know what our efforts are going to be for discovery or the hindrance of technical debt.  And, we don’t really have the amount of time it would take to go do this type of research up front. So how do we plan effectively as we’re flowing work through the organization?

And there’s a couple of things — there’s a technology trade-off matrix that we’ll talk about which is: Okay, this piece of work that I’m putting through, it’s changing this part of my system. Where does it fall on my suitability of architecture relative to the required pace of change in the future? If it’s poor architecture, it’s not very easy to change, but we’re not going to be changing it very often. We’ll take a different approach to trying to fix the architecture and manage the technical debt.

If it’s something that is broken architecture, but the pace of change is going to be very high, we need to be building time into the model to go do that discovery and repair that technical debt. This trade-off matrix allows us to have conversations when we’re in solution validation,  to begin to really figure out what the impact is on this work and everything else in flight.

One of the things that tend to kill organizations is not planning for the impact of technical debt either in the development of the code or particularly in the testing. I’ll talk about testing in a minute as well. But, by late discovery of these things and already having our organization fully committed in the future, anything that slows us down automatically causes a problem that makes the capacity problem be worse.  So, by being really clear about when we need to manage the technical debt and having those conversations before we commit the work into the system, we can manage our flow better.

We look at dependencies. We’re also looking in solution validation and all the way down to making the work ready, to really understand where the dependencies are, how we sequence the work to maximize the flow of features and epics. We’ve got all the right people in the room before we’ve committed to any individual piece of work, to have these conversations very strongly, and inform the sequencing of work.

So our governance model makes that be very explicit in the solution validation, story mapping, and the make ready of work.  And then we get into the testing of the product. There are many types of testing — the testing quadrants have been used broadly in the agile community. In a perfect world, a team can push a button and run all of these tests at the last minute, and we always know where we are. Pragmatically, it doesn’t work that way in organizations. So what’s critical about this is, is in solution validation, solution visioning, and demand planning, we have to talk about how we need to slow the work through to maximize getting it tested and remediated, not just getting the code built. And so here’s an example of where we’ve taken the different quadrants of the testing quadrant and talk about when they’re going to take place in the work, and these definitions have become part of what it means for work to be completed before it moves through the system.

So again, looking at the governance model at first, it looks like it’s really busy. It can be hard to understand without understanding the intentionality between making the right decisions at the right time with the right people to make sure that you’re maximizing the flow of value through the organization. Looking at the five categories of things that cause us to fail: Unclear scope, not balancing capacity and demand, not taking technical discovery and debt into account, not managing dependencies, and not validating our work until it’s too late to do anything about it. All those can become very clear in — what the state of the work is, who needs to be involved, what the cadence of the meetings are.

So our governance model, our team design, and our metrics come together to create a system that explicitly and intentionally manages the things that tend to make organizations fail at product work.