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

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

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

“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.

stacey1

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.

fieldofdreams

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

risk

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.

Takeaways

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:

Categories:

Tags:

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