Category Archives: Innovation

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

Estimated Reading Time: 6 minutes

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

Back to the roots

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.


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

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


Dealing with Requirements/Business Uncertainty

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

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 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)

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



Want to experience agile in an accelerated form and focus on innovation at the same time? Try an agile FedEx day!

Estimated Reading Time: 3 minutes

A while ago I wrote about Slack and FedEx Day and why I think its important to have slack in the system, and why a FedEx Day is a good way to to run an innovation day.

A few days ago we had the first inaugural AgileSparks FedEx Day.

Since we are, after all, a company which believes in agile approaches, we decided to some dogfooding an run our FedEx day in an agile form.

We started with identifying the Goal of the day and then decided on a few key themes the innovations should focus on. This was done offline a couple of days before the actual FedEx day. For example, one of the themes was “Process Innovation – Things that will enable us to do our work more effectively and bring more value to our clients”.

With those themes defined, we opened the floor to brainstorming of ideas to work on. This as well was started offline, by sharing a google spreadsheet where each member of the team could add his ideas. Some of us had some ideas in mind, some of us came as a “Clean Slate”.

At the morning of the FedEx day itself, we started with a warm-up – a great breakfast accompanied by running Presentation Karaoke which was quite hilarious. I drew a presentation covering the lifecycle of a butterfly which I used as a metaphor for an Agile Transition… but since our rule was that things that happen in FedEx day stay in FedEx day, I will leave it at that šŸ˜‰

Then we looked at the ideas, collected on a sunny window, both ideas from the spreadsheet as well as other ideas that came up during the warm-up and gathering time. Each of us had to choose an idea he is excited about, and that is how we did team formation. We came up with 3 teams each working on a different idea.

We then started sprinting! we did 4 sprints of an hour, including planning, demo and retrospective. The demos included the whole team. During the sprints we worked on elaborating our ideas, using Agile User Stories and techniques such as story mapping, as well as started implementation and delivery of “Working Software”. It proved a real challenge to deliver on such short sprints, especially for those of us who didn’t have a somewhat formed idea at the starting point.

In the middle of that we stopped for a quick lunch and great Vaniglia Ice Cream (This is the best ice cream in Israel IMHO btw… and we have an Ice Cream fetish in AgileSparks…)

At the end of the day we gathered to retrospect on the whole experience and choose the winning idea. We decided that it was a great experience, that pushed forward several important ideas, as well as gave us the opportunity to experience on our environment some of the practices and approaches we are helping teams with.

One important insight was that you can use a FedEx day for various purposes. Innovation is just one of them:

  • Product Innovation
  • Process Innovation
  • Business Innovation
  • Set-based approach for Solving a tough and important problem
  • Making a real dent in a cluster of small technical debt areas, or a big technical debt.

Have you thought about running a FedEx day in your team/company? If you have been sprinting/churning for a while now, and want to change gears, consider something like a FedEx day.

If you also try some new lean/agile practices while at it, you get double benefit! We believe that exercises/games bring accelerated learning of any new approach to doing things. One of the cool things about a FedEx day is that its a mix of accelerated delivery as well as accelerated learning.

If you are interested to hear more about this, or would like our help in planning or facilitating such a day – let us know!