Can we learn anything from giving birth early, about early project delivery?
On the 19th July 2012 we welcomed William Maximus Elbourn into the world, and since then I have had limited time to blog. However I was inspired by the workings of the NHS enough to plant a seed of thought in this blog. My wife Samantha was induced earlier than expected because they detected a volume change in the womb, we had an early delivery.
Giving birth is the end result of what is a 9 month project. Usually started by a brilliant idea. Timely project delivery is such a huge issue in the software delivery, and early project delivery is often desired but a relatively uncommon occurrance.
early delivery
Occasionally with natural birth you can get complications, sometime mild, sometimes major and sometimes tragic, but the NHS deals with these complications in a way that seems contrary to most software delivery projects. The NHS to reduce risk, often deliver early.
However with software projects it seems the reverse, perhaps the project needs to be delayed by a week, just to fix some critical bugs, or a month to add the correct features often leading to many months…. With pregnancy delays would be easily fatal to a baby in a womb as the placenta begins to disintegrate as the body prepares for release (birth). Sadly lots of these software projects get abandoned, canned, mothballed or go way over budget as a result.
Before a baby is born, there are lots of unknowns, for example – experts still occasionally misinterpret the gender, the same (and more) goes for software projects, especially around the requirements.
The NHS also use a “burn up chart” (nah they don’t call it that but I guess you can see what I am doing here), this chart records the estimated growth based upon the scans and measured volume of the womb. As long as the baby is within a certain range then there is no cause for concern. Should the baby be gaining or losing weight, particularly near delivery time, an early delivery is often performed.
Why?
When the baby is delivered early, more people have access to the baby, and the right people can help the baby, you also get clearer diagnosis of any issues and greater feedback from the baby in terms of response to stimuli etc. The baby (and the mother) has a much greater chance of survival.
So why not with Software
Imagine it, you have a certain amount of functionality ready to go, you have a product backlog longer than your whiteboard will allow room for. This product backlog contains unbuilt untested functionality, that is needed for this project to be live. But what if you delivered early, what if the benefits of your ready-to-go functionality could be realised early? What if feedback from that functionality would negate half of your backlog and emphasise something new, more profitable and as yet unseen. What you deliver might not be super shiny, or gold plated but it may be an (often unconsidered) option giving early benefit to your customers.
from one end of the scale….
“But you cannot deliver garbage into production…!”
I am talking in the context here of a team that is delivering releasable software, and I acknowledge that you cannot just put something that puts a business at risk into production, I am talking about incremental units of functionality (vertical slices if you like).
If the project is in a worse state than this, (lets say a less developed state) but is releasable you can still deliver it into a different environment, perhaps if its greenfield development deliver it into UAT then. Or put it somewhere where people can see it, and give valuable feedback instead of sitting on the problem.
When you expose the project to others, the right people can help the “baby”. This takes a certain amount of guts from project managers who dont want to appear to be asking for help, or perceived as a failure. It takes teamwork. The problems and uncertaintities faced in software development are rarely unique, and often outside help or feedback help tremendously.
…to the other
“Hmmm… what features shall we deliver first (or at all) into production”
The software industry already has established something called multivariate testing (or A/B testing) where you can deliver multiple (potentially conflicting) features live, which are proportionally split across your customer base, feedback can quickly gained and used to ascertain which is the better feature, and you can then roll out the more successful feature at will. This is particularly applicable for online marketing / ecommerce applications, you can read more about it here. http://en.wikipedia.org/wiki/A/B_testing. While this might not be delivering early it does reduce uncertainty and get early feedback which can affect your backlog.