Risk Management for Agile Projects Again

I wrote about Risk Management with Scrum not long ago. I re-visit this topic again as a translation assignment for InfoQ. There are some new interesting points as well as old but important points.

The more interesting input is from James Shore. He suggested the use "Risk Multiplier" as a way to make solid commitments.

There are a number of issues behind this approach:

  • The meaning of "solid commitment", how would these solid commitments be used and interpreted by the users? It is meaningless if this were taken as argument points in case if the team could not make it. Afterall, this is merely probability. What would be the difference between we would try to finish 140 story points or we would try to finish 78 points?
  • How do these multipliers came from? James Shore has this line on this: "I'm guessing somewhat at how accurately they apply to XP. The most accurate approach is to calculate your own risk multipliers from past project history, but most companies don't track that data". So, in my opinion, don't take these as magic numbers.
  • Following the points above, if we have to collect that data for the purpose of giving such commitments, is it for the best of the benefits with the customers? What could justify the customer or product owner to invest money and time for the team to do these statistics? More importantly, how do customers and product owners know they get positive return for what they invested to the team on these activities?
  • Possible decrease in velocity, imagine the team begin with suggesting possible of 140 story points for 10 iterations, and "commit" 78 points. Since the remaining points are only "extended goals" or even impossible, the team could be happy for finishing 78 points, and get slower for the remaining stories.
With these issues above, I wonder how practical the "Risk Multiplier" would be useful. Iterative development, by nature, enables the development team and product owner to "inspect and adapt" to what happens at that moment. Making commitments far too early easily gives product owners neglect on "Inspect and adapt" nature and rather expect what is "committed" 10 iterations ago. This, in turn, defeated the risk management nature of iterative development.

As I read about Agile over these years, I found there are more and more attempts to add new things to Agile. However, the best of the ideas is always the original steps of Agile, the Agile Manifesto and the Principles.

Share with: