Close this search box.
Close this search box.
Close this search box.

Risk-aware Product Development (a.k.a. Agile)


“There’s no predictability/commitment in Agile”

Over the years I’ve heard my share of these kinds of statements from various levels of executives:

“When my guys run a product development release I really want to know what I will get at the end so I can make business plans accordingly”

“In the old days when we ran projects we knew the timeline, we knew the scope, there were no surprises. These days it seems like the inmates are running the asylum. Product Management keeps telling me in this Agile way of doing things there is no committed scope, no plan, only ‘Responding to change. I can’t help but think they are using it as an excuse for thinking short-term”

“When an important new/existing customer asks for a feature I really want to know whether I can commit to him that it will be delivered in the next release so I can get him to commit to a purchase”

“When you talk to people here, I want you to be very clear on the fact that agile will not take away the predictability they have so that they will not oppose the agile initiative we are trying to kick off”

This post is dedicated to you guys out there trying to make sense of the confusion surrounding predictability and Agile (Or as I often refer to it these days Risk-aware Product Development), whether you consider yourself one of the people quoted above or one of people working for them trying to bridge the desire to work in an agile nirvana-like flow and dealing with those pesky executives stakeholders and customers bent on interrupting that flow.

Back to the roots

Let’s make it clear upfront. I totally empathize with these executives. They are either already victims of “Bad Agile” or are basing their concerns off of a lot of “Bad Agile” going on out there. It is such a shame though because in reality agile product development actually maximizes the predictability you can have in your environment. Wait, That was a complex sentence. Why didn’t I just say “Agile provides great predictability” and get it over with? Because that won’t actually be true…

Let’s start from the beginning. Let’s talk about the contexts where agile approaches are required. One of the first things I discuss with executives is the concept of uncertainty and specifically Stacey’s Uncertainty Matrix.


Types of Uncertainty in Product Development

I explain the concept of Requirement/Business uncertainty as the chance that you are aiming at the wrong target and Technology uncertainty as the chance that you’ll have execution problems getting there. I then ask the people in the room to classify the projects they are currently working on and typically get a picture somewhat like the one above with different projects having different uncertainty profiles. At this point, it is typically easy to get to the understanding that when you have low uncertainty predictability and success is a matter of careful and disciplined execution of greatly crafted plans.

Dealing with Technology Uncertainty – The Waterfall Passive/Buffered Risk Management Style

When uncertainty starts to mount, it is a different ballgame. Teams facing technology uncertainty with big-batch waterfall approaches only get REAL predictability (meaning the one that stays valid all the way through the release of a high-quality product with the committed scope) through huge buffers. These buffers serve to hide those horrible big bang integration hells that are the source of statements like “We are totally on track all the way through development but when we reach the code freeze period all hell breaks loose and we don’t trust a word we’re told about when the product will be released”.

Dealing with Technology Uncertainty – The Agile Active Risk Management Style

Agile teams in this context should be able to provide predictability by weighing the amount of effort required to achieve the business’s expected outcome, taking into account the amount of uncertainty, and making some buffered plans at the high level before going into low-level iterative product development aimed towards achieving those high-level commitments. You not only get predictability of “If we said we will deliver this feature in this release then that is what we will do” you also get visibility of progress towards meeting that commitment by seeing working product frequently and getting reports based on real integrated progress.


Dealing with Requirements/Business Uncertainty

Here, the definition of success is actually a bit different than what executives are used to. Success doesn’t necessarily mean delivering according to commitments. It means hitting the target if it is indeed a real target and alternatively learning as quickly and cheaply as possible if we are aiming at the wrong target. This is not some theory we’re talking about. Data from more than 50,000 projects suggests 50% of features developed are actually not used. (See Chaos Report 2013).

Is Predictability what we want?

So aiming at the right target is not a trivial task in Product Development, especially if you are in a more innovative space where it is not even clear that there is a market need for your product, but also when you are working on internal IT projects where this kind of uncertainty seems irrelevant… In the Lean Startup movement, we typically talk about the “Build it and they will come” fallacy. Actually, we are NOT sure they will come, so we want to be very careful with what we build without knowing. Predictability might be a dangerous thing to wish for in this environment.

The Risk Burndown Exercise


An exercise I often use to get this point across is to ask people in the room to draw a chart of the amount of risk/uncertainty in their projects from initiation all the way to the moment all risk/uncertainty has been exposed. the X axis reflects the time or stages in their “Stage-gate process”. The Y axis is “remaining risk/uncertainty” in either the Business/Requirements/Technology domains. One answer I typically get is a line curving up at some point only to go down later on. That is impossible. The risk is there. If the line curves up what you mean is that you actually just become aware of the risk at that point. I guess this is the best indication of the fallacy of “predictability” people have. Others start with the maximum risk and then go down quite quickly – telling me that they learn everything they need to learn at the point of “Requirements/PRD/Design” and from then on it is a matter of execution. I then typically ask whether they find surprises/defects later on in the cycle and whether they actually know all of their features are in use. This typically gets them closer to the epiphany… Others get it by this point and draw a chart where a lot of the risk is there active until you finally get to have your software/product in the hands of real users. At this point, the discussion very quickly gets to the main way to reduce the time of active risk – cutting projects/products into smaller pieces so they can get to be “Working products in the hands of users” faster. (Which is, by the way, one of the key differentiating factors of successful projects regardless of the methodology according to the Chaos Report)

A reverse correlation between Business uncertainty and the need for Predictability?

Luckily enough it seems like Predictability is typically required when there is a strong business need on the other end of the line (if there is a partner/customer adamant on having that feature it kind of reduces the business uncertainty of whether it is a real need…). So effective classification of projects into the right uncertainty/predictability profiles will typically help satisfy the business executives without creating unrealistic expectations from the product development group. There’s still the need to understand you are sometimes running small “startups” or “venture capital” inside your product development portfolio, which might be tough for an execution-oriented IT/product development executive to fathom. Geoffrey Moore talks a lot about these kinds of struggles in “Escape Velocity”. Which is highly recommended reading by the way.


So, with all this in mind, what can you do?

My advice to executives is to make sure they and their teams understand the uncertainty profile of each of their projects and act accordingly:

  • When uncertainty is low, use whatever kind of process to deliver the desired outcomes with high predictability.
  • When dealing with technology uncertainty and medium/low requirements uncertainty (Sustaining Innovation) and it is desirable to be predictable, use effective agile release planning approaches to set up a reasonable plan with maneuvering space to account for some requirements/execution uncertainty using either a time or scope buffer (a set of features that are considered stretch / extra-weight to be jettisoned in case of problems).
  • When dealing with serious business uncertainty (Disruptive Product Innovation space?) make sure that a fast iterative approach is used to minimize “building it before knowing whether they will come”. Learning needs to be emphasized over predictability in these environments.

This blog post was originally published on my personal blog back in 2015 but since I refer people to it so often – I thought it makes sense to bring it over here and republish it…

Subscribe for Email Updates:



Engineering Practices
Accelerate Value Delivery At Scale
RTE Role
Kanban Game
Implementing SAFe
Keith Sawyer
PI Planning
The Kanban Method
Sprint Iteration
Enterprise DevOps
What Is Kanban
Agile India
Achieve Business Agility
Professional Scrum Product Owner
Agile Mindset
Lean Startup
Quality Assurance
Agile Exercises
Product Management
Team Flow
Agile Development
Agile Project
Lean Agile Basics
Kanban Kickstart Example
System Archetypes
Release Train Engineer
Scrum Guide
The Agile Coach
Continuous Planning
Sprint Planning
Agile Delivery
Lean Software Development
IT Operations
Sprint Retrospectives
Lean and Agile Techniques
Daily Scrum
Continuous Delivery
Continuous Improvement
Agile Program
Acceptance Test-Driven Development
Development Value Streams
Lean Budgeting
Iterative Incremental Development
Elastic Leadership
Scrum Master
Nexus Integration Team
Lean-Agile Software Development
Agile Games
Nexus and SAFe
Software Development
Managing Risk on Agile Projects
Introduction to ATDD
A Kanban System for Software Engineering
Lean Agile
SAFe Release Planning
Managing Projects
Program Increment
SAFe DevOps
Lean and Agile Principles and Practices
Agile Outsourcing
Portfolio for Jira
Jira Cloud
Agile Israel
Lean Risk Management
Systems Thinking
Agile Release Planning
Continuous Integration
System Integration Environments
Agile Community
Agile Release Management
Agile Techniques
Risk Management on Agile Projects
Agile in the Enterprise
lean agile change management
Large Scale Scrum
Agile Basics
Change Management
Coaching Agile Teams
Scaled Agile Framework
Entrepreneurial Operating System®
Scrum Master Role
Principles of Lean-Agile Leadership
speed at scale
Lean Agile Leadership
User stories
Pomodoro Technique
Professional Scrum Master
Product Ownership
Scrum With Kanban
Risk Management in Kanban
ScrumMaster Tales
Agile Assembly Architecture
Agile Testing Practices
Story Slicing
Kaizen Workshop
Artificial Intelligence
Process Improvement
Implementation of Lean and Agile
System Team
Agile Risk Management
speed @ scale
Agile Project Management
PI Objectives
Continuous Deployment
Agile Israel Events
Professional Scrum with Kanban
AI Artificial Intelligence
Operational Value Stream
Scrum Values
Lean Agile Management
ALM Tools
Agile and DevOps Journey
Perfection Game
ART Success
Agile Games and Exercises
Scrum and XP
Hybrid Work
Rapid RTC
An Appreciative Retrospective
Agile Product Ownership
Legacy Code
Applying Agile Methodology
Effective Agile Retrospectives
Jira Plans
Agile Product Development
Agile Marketing
Agile Contracts Best Practices
Business Agility
Value Streams
Kanban 101
Built-In Quality
Legacy Enterprise
Test Driven Development
Games and Exercises
Manage Budget Creation
Nexus and Kanban
Lean Agile Organization
Certified SAFe
Advanced Roadmaps
Scrum Primer
Agile for Embedded Systems
Introduction to Test Driven Development
Kanban Basics
Jira admin
Reading List
Limiting Work in Progress
Risk-aware Product Development
Lean-Agile Budgeting
Releases Using Lean
Nexus vs SAFe
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart