Driving out uncertainty
Agile practice irrespective of flavour (Scrum Kanban XP …)can often be reduced to:
- Work in small batches
- Deliver often
- Build the most valuable chunk first
And it’s the “value” bit that can get us in trouble.
How do we determine which is the most valuable bit? Particularly early on in a project we need to be careful about how we prioritise. Do we just get a bunch of business folk to fight for their favourite features or do we have some hard won lessons to apply from many years of technology project management?
One of the first projects I was responsible for was fixed scope and fixed price. The customer was documenting requirements to be handed into the “agile” development team who built and tested software prior to a traditional system test cycle. Not very agile!
However, we benefitted greatly from the rhythm or scrum, the rigour of agile engineering practice and the predictability the the planning and tracking approach provided.
Most significantly, by taking the Product Owner role I was able to prioritise according to my own definition of value. Put yourself in my seat, you work for a software consultancy, it’s your first project and it is fixed everything, what makes one feature more valuable than another? The answer is risk. When everything is fixed value is in the reduction of risk. In fact I combined prioritisation according to risk with other engineering considerations such as profile of the work to bring the project to a successful conclusion.
So what about other interpretations of value? I’ve been helping a client with a project initiation over the past couple of weeks and found myself using the word uncertainty a great deal. It seems that driving out uncertainty held a great deal of value in that context. In fact, when kicking of a project we look for information generation first, then seek to identify key risk areas and mitigation strategies such as finding new stakeholders or driving out technical risk with proof of concept work.
Uncertainty isn’t new; I often use the “cone of uncertainty” model to express the value of reducing uncertainty. As wikipedia will tell you, this model is primarily concerned with project estimation. At the beginning of a project, skilled estimators may have a factor of 4 error in either direction. Over time error should rapidly reduce as information arrives and the project progresses. This dynamic is known as the Cone of Uncertainty and is the inner line on the graph.
The outer line is the cloud of uncertainty. This is what could happen if uncertainty is not driven out of the project. Right to near the end of the project there is significant error in estimating the size due to missing information.
When we execute agile projects lets not forget the value of driving out uncertainty. This isn’t an excuse to analyse everything to death. Our goal is to recognise where the uncertainty that matters is hiding. Those innocuous features that come along and prove the architecture is flawed are a prime example. We must do enough to understand the risk we are carrying while being sensitive to the cost of gathering detailed information pertaining to speculative requirements.
Technorati Tags: cone of uncertainty
.
) was focused on applying TOC in a software engineering context so I guess it’s not surprising that he wold choose to spend a little time explaining the connection between Kanban and TOC.
