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:



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