Skip to main content

How to Make Commitments in the Face of Uncertainty

Mike Cottmeyer Chief Executive Officer
Reading: 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.

Figure One - Scope FirstThis 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.

Figure 2 - Time and Cost First

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?

Next 10 Tips for Better Story Estimation

Comments (8)

  1. Jeffrey


    Great post. It reminds me of a couple different things. First, your statement about the difference between agilists and executives reminds me of a discussion on Deming I watched last week. Watch the last 5 minutes of this: “Nobody Gives a Hoot About Profit”

    It seems to me, those executives who want a predictive organization have elevated the wrong set of values. If not as bad as painted in the above discussion, then it would seem they are at least “campers.”

    ** begin quote **
    “Campers…have worked very hard to find a safe plateau in life. They admit that they have been aiming for a particular spot all their lives and now they have reached it and are content to just camp there. Stolz’s research indicates that 80 percent of today’s business professionals are campers, and many managers are simply campground leaders who likewise have settled into a safe, shady spot on their career path. At some point on their journey, the toll became so great that they stopped climbing and sacrificed their dreams, goals, and aspirations.

    “The good news is that inside every camper is a climber.”
    Taken from: Summit: Reach Your Peak and Elevate Your Customers’ Experience by Scott Addis, Greenleaf, 2014
    ** end quote **

    Second, Jim Highsmith’s Agile Triangle ( does a good job showing how the Iron Triangle is not sufficient and agile extends it with key components. This breaks your model a touch, and I need to analyze whether it’s primarily a language thing or something else.

    I took a riff off Jim’s post last summer in a paper for a PM Symposium, “Blow-up the Iron Triangle” ( I was approaching some of the same ideas you go into, but I didn’t have the divergent mindsets. If you have (too much) time to kill, I’d appreciate your feedback.

    Lastly, do you mind if I start trying to incorporate your thoughts into the next version of my paper / presentation?

    • Mike Cottmeyer

      Thanks for the comment Jerffery… couple of quick points.

      I have the utmost respect for Jim, but I don’t agree with his take on the Iron Triangle, and don’t consider it authoritative. Here is a post I did after I heard him talk about it.

      I don’t think these executives are campers at all. They are not coasting. Many of them are working hard, running really profitable business, and want to grow. Some don’t see anything broken in the current model. Some may see the need to change, but don’t understand the models or can’t articulate a path forward. Some are riding so close to the edge, that they think it’s safer to stay put than risk a change. I think it’s unfair to generalize a pretty broad group of folks. What we are teaching is pretty advanced organizational thinking.

      I consider my ideas free to use… I’ve always felt like I’ve stood on the back of giants… so use what you want. I’d appreciate attribution, and if you quote me, a link back to would be cool too.


  2. Johnson Chuang


    Really great article.
    By the way, I’m not sure it’s a typo or I’m just misunderstanding the sentence. The first sentence in the paragraph [What doesn’t fit get’s left out.] “…when applied to ‘predictive-emergent’ companies…”, I thought the term “predictive-emergent” should be “predictive-convergent” based on previous paragraphs.

    Anyway, really helpful article for me, thank you.

    • Mike Cottmeyer

      Thanks Johnson… It was a typo. Crap… I tried really hard to fix all of those :-)

  3. Jardena

    Nice post Mike. Sounds really familiar to me.:)

    • Mike Cottmeyer

      Thanks for the comment Jardena. I don’t think that you’ve seen me write much since I’ve known you. I’m kinda on a roll. Trying to untangle and write out some concepts I talk about quite a bit ;-)

  4. Jim Grey

    Totally loving this series. It’s helping me understand why agile has been such a hard transition in the places I’ve worked — convergent-model shops the lot. But one thing’s for sure: agile surfaces project problems sooner, or at least it has in my experience. In a six-month waterfall project, typically you don’t find out how much you’re off track until the last month. In agile, you find out in the first sprint whether you’re off track. Sure, you can manage waterfall projects much better than I’ve seen done, but the truth is most places I’ve been simply don’t. They accept it when the developer says he’s 50% done when it’s more like 25%, and 90% when it’s more like 50%, and then in the last week when he says he’s 95% done yet it seems to take him three more weeks to finish the other 5% and QA gets squeezed yet again…ugh. At least when you do two-week sprints you can see sprint by sprint what you didn’t accomplish so you can adjust.

    • Mike Cottmeyer

      Totally agree Jim. The problem with agile as its often implemented, is that folks have thrown out any notion of the definition of done, or and definition of what will be delivered when the time and money runs out, and replaced it with two week deliveries. We need the two week visibility into working tested software, but in the context of a plan, so that we know how we are doing against the plan. The manifesto says ‘responding to change over following a plan’. We need plans that are resilient to change… agile or waterfall. Thanks for the comment.


Leave a comment

Your email address will not be published. Required fields are marked *