How to Make Commitments in the Face of Uncertainty

Here’s my third post in what is shaping up to be a nice little series. The first post I explored what problems executives are trying to solve with agile. I suggested that a lot of times adaptability was not the primary driver… execs are most concerned with delivering predictably, with high quality, and in a way that allows for an earlier return on investment.

In my next post, I tried to untangle two predominate business models… product delivery approaches, if you will… that we see most often in companies trying to adopt agile. The first model we called Emergent. This is where the final product definition is not as important as meeting some goal such as selling advertising or driving traffic.

This was contrasted against a second kind of model that we called a Convergent business model. This is where scope and delivery dates matter a great deal… and where rather than trying to optimize a more abstract goal… you are trying to deliver a predetermined set of features within established time and cost constraints.

So… just to summarize, we have two key ideas presented so far:

1. The goal of many agilists doesn’t align with that of many executives who want to adopt agile. These executives are optimizing for predictability over adaptability.  They might need to be more adaptive, but that isn’t the problem they are trying to solve for now.

2. The nature of the problem many are trying to solve with agile is fundamentally incongruent with many corporate business models. Agile approaches are natively suited for emergent business problems while many companies have convergent business problems.

We have in effect defined two different types of companies. For the sake of clarity moving forward we’ll call these two kinds of companies adaptive-emergent and predictive-convergent.  My basic hypothesis is that most agile adoption efforts start with the assumption that the company is either adaptive-emergent or can become adaptive-emergent once the culture in the company has become more agile.

I’m suggesting that most companies have a core infrastructure that is fundamentally predictive-convergent. Using adaptive-emergent techniques, language, methodology and tools is fundamentally destined to fail in predictive-converegent companies. It’s not that agile can’t be adapted or scaled to work in these predictive-converegent companies, it’s just that it requires a different language and approach.

This series is all about what it takes to make the case for agile in predictive-converegent organizations.

Much of what we are going to do over the next few posts is explore the necessary foundational concepts required to begin applying agile in these predictive-convergent organizations.  The last few posts were me laying down this basic hypothesis so you guys can track what I’m saying and why I’m saying it. This isn’t your Grandma’s kind of agile ;-)

Once you accept that there are two different models at play, there are some myths and preconceptions about agile that have to be dismantled. Today we are going to talk about how to think about time, cost, and scope constraints in predictive-convergent companies. After this, I want to explore some ideas around agile teams, how to form them, and how they should operate. Next we’ll probably end up talk about planning horizons, risk management, and coordination and commitment in complex product delivery.

That said… once I actually get to writing all these posts, maybe even this one… all bets could be off with regard to where we go. Inspect and adapt right?  For now though… let’s get on with the business at hand, good?

Managing the Triple Constraints With Agile

Okay… so that was quite a preamble to this post. Today I want to cover how to think about the triple constants of project management within an agile framework and begin to explore what it takes to make and meet commitments in the face of extreme uncertainty. When we are talking about predictive-convergent companies… if you can’t answer when are we going to be done, what is it going to cost, and what are we going to get when we run out of time and money… you do not have a basis for a conversation with most executives.

Predictive-convergent companies cannot run without the answers to these questions.

Most traditional management frameworks tend to start with the question ‘What do you want to me build?’, quickly followed by ‘How much will it cost?’ and ‘How long will it take?’ In a traditional, waterfall SDLC, this typically means that we need to define the charter, or the MRD, or the PRD up front so that the work can be effectively estimated and scheduled. Riffing off an idea DSDM introduced many years ago, you can think of these three variables as a triangle. The project starts with scope, and you derive time and cost based on estimation and availability.

This approach is powerful because it gives executives the illusion of certainty. I asked for what I wanted, and got back a cost estimate and a timeline, for when it will be delivered. Perfect, right? Well, no actually. The problem is that we don’t know enough about what we want to build early in the project to get good estimates. Even if we did know what we wanted, it’s tough to have perfect knowledge of *how* we are going to build it or even how long it would take if we knew. The estimates are fundamentally flawed.

To make things more complicated, we know that the development team is not made up of fungible resources but with uniquely skilled human beings with hopes, dreams, fears, and families which can make them unpredictable. It’s really tough to know exactly how long it’s going to take for any given engineer to do a given body of work… even if we have the same engineer do the work that provided the estimate. Sure, we can pad and manipulate the date to hedge our bets… but it’s doesn’t solve the problem that we have a fundamentally flawed model.

Agile flips the triangle upside-down and starts with the questions ‘How much time do we have?’ and ‘How much do you want to spend?’.  After we have time and cost established, agile seeks to vary scope to deliver within the constraints. This is an excellent way to think about product development. We have to be in market at a certain time, we only have this team of people to do the work. What can we build for the amount of time and money we have that will yield the most value for our stakeholders.

We know based on the physics of project management that we can’t fix all three of the triple constraints… we do know this don’t we… that if we are going to lock down time and cost… scope has to be the variable that floats. Said more succinctly, agile fixes time and cost and varies scope… at least within any given time box. With me so far?

Using more agile language, this concept is typically expressed with the following explanation… the Product Owner creates the backlog, she meets with the team to do estimates, the team pulls stories off the backlog each sprint and measures the rate at which they can complete the work. The rate they can complete is called velocity.. Since we know the size of the backlog, and the team’s velocity, we can predict the amount of work that can get done within the timebox… sprint level or release level.

What doesn’t fit get’s left out.

Therein lies the fundamental flaw with a agile when applied to predictive-emergent companies. The scope is predetermined. Talking about what we are going to leave out is a language off loss… and these companies can’t leave anything out. When you start telling executives that they have to trust the team to do the best they can, and that they’ll get as far as they can (before the money runs out), and that we can ship at the end of the time box, but that we can always add more time (and therefore more money) at the end of the project… you often get walked out the door.

It’s not that the executives don’t get agile or it’s potential benefits, it’s that you just explained agile using adaptive-emergent language to a company that is operating in a predictive-convergent business model.  Make no mistake… executives want to fix all three of the triple constraints and hold you accountable for making it happen. We need to help them understand how to commit in a way that leaves some room for negotiation. We need to learn how to commit while leaving some room for negotiation.

Predictive-Convergent At Scale

One more point, just to make things a little more complicated… we haven’t even addressed the issues of agile at scale… we are still pretty much exploring the small team space. Predictive-convergent companies face even more challenges. It’s not just that they have to meet commitments to clients for a somewhat fixed scope… they also have to coordinate the outputs of many, often highly interdependent teams to create an integrated deliverable within those time and cost constraints.

The language of adaptive-emergent agilists doesn’t even come close to addressing how complex systems integration will happen, or when it will happen, if every team isn’t going to commit or is changing the backlog as they go. Needless to say the problem is complicated. No wonder executives like it the old way… commit to fixed time, fixed cost, and fixed scope… and and let the organization figure out how to make it happen. Again, not saying I agree… but this is frankly the way it is.

So where does this leave us?

What’s Next? 

Solving the problem involves organizing the backlog in such a way that we can make commitments in the large, but make trade-offs in the small. The approach involves story maps, minimally marketable features, product roadmaps, high level estimating and budgeting, rolling wave planning, active risk management, lean portfolio management, and Kanban… all wrapped around stable, consistent, predictable, high-performing Scrum teams.   

Here is the interesting thing… from the Scrum teams point of view… it’s all just Scrum. In one way, it’s really just a more advanced and well articulated approach to backlog management.  That said, we need to blow this out a little before we try to bring it back. Next post, I’m going to build on this a little, but take it in a slightly different direction. I’m

going to tell you guys a story about the house I was planning to build this past summer… and why I didn’t build it.

Read the next post, Predictability over High Performance? My Journey Learning to Play the Guitar.

Read the previous post, Is Your Business Model A Good Fit For Agile?