Risk-aware Product Development (a.k.a. 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 the 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.

Let’s make it clear up front. 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.

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.

When uncertainty starts to mount, it is a different ballgame. Teams facing technology uncertainty with big batch waterfallish approaches only get REAL predictability (meaning the one that stays valid all the way through release of 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”.

Agile teams in this context should be able to provide predictability by weighing the amount of effort required to achieve the business expected outcome, taking into account the amount of uncertainty, and make 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.

Here, 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).

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.

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 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. 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 product in the hands of users” faster. (Which is by the way one of the key differentiating factors of successful projects regardless of methodology according to the Chaos Report)

Luckily enough, it seems like Predictability is typically required when there is a strong business need on the other end of the line (if a partner/customer is adamant about having that feature, it reduces the business uncertainty of whether it is a real need…). So, effectively classifying projects into the right uncertainty/predictability profiles will 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 challenging for an execution-oriented IT/product development executive to fathom. Geoffrey Moore talks about these kinds of struggles and cultural clashes between different innovation modalities and horizons in “Escape Velocity”.

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 in an environment with reasonable certainty - 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), if predictability is desirable, use agile outcome orientation and 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 / weight to be jettisoned in case of problems).
• When dealing with deep 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.

Matching your operating model to your uncertainty profile — rather than applying one-size-fits-all process — is a core principle in how I work with product and engineering organizations. Explore Product Operating Model advisory or let’s talk.