This article is a supplementary appendix to the post: The Power of Feature Hypotheses.
Where We Were: 12 Months to Deliver a Small Feature
The graphic below is an example of a feature that previously took 12 months to deliver when we were working waterfall. This was the typical cycle-time for a small feature. Larger features would usually take over two years to flow through the system. With agile, we would now expect this same feature to be complete in a two week sprint. This article provides the six main reasons for the massive cycle-time reduction.
Please see the blog post, The Power of Feature Hypotheses, for a detailed example of two-week feature delivery.
Six Reasons Behind Cycle-Time Reduction
1. Removing the Gridlock
We’re now in a capacity constrained, WIP limited model. This allows the team to focus on fully completing the highest priority work rather than having a lot of work in progress that is “almost done”.
In the past we had delivery gridlock with a 100% utilised system but still kept trying to add more functionality into the already gridlocked system – resulting in all delivery being really slow.
Henrik Kniberg explains it best in this sort video:
2. Smaller Size = Increased Predictability
By focusing on the benefit hypothesis and minimal viable product (MVP) we slice our feature down to the smallest size that gives the most value. In the example from The Power of Feature Hypotheses, the scope was reduced to one country. A production defect and a nice-to-have (but non-MVP requirement) were excluded. In the past we would have tried to “do it all” – making the feature at least 10 times bigger.
The business would have pushed to “have it all” because they knew that if they didn’t “get the requirement in now” they’d have to wait years before they had another opportunity. Increased size = increased complexity = more things that can and will go wrong = long delays in delivering the feature.
In addition, bigger size = more defects; bigger size = longer time between defect introduced to defect detected = harder to fix defect.
3. Reduce Documentation Waste & Silo Delays
Bigger size means that we must document a lot more because we can’t remember everything. Not only does this take time but it also leads to hand-offs and makes it difficult to prevent working in silos. The developer can’t wait around doing nothing while the analyst documents a long use case so they do other work until the use case is ready.
When they receive the use case to code it’s usually the first time they are seeing the solution and will likely have a lot of questions trying to understand what is needed and why. The same applies to testing.
There are often long delays between documentation done and coding starts (we have plenty of examples where a completed use case sits for 18 months before development starts).
Everything rots while waiting on the shelf.
4. Reduced Complexity
The bigger the solution = the longer it takes = the more likely changes will be required. Changes (and changes upon changes) overwhelm the team and it’s very difficult to keep everyone aligned to the current baselined version of the solution.
With a small feature where the conversation has just happened it’s easy to go back to one’s desk and build a solution that meets the feature acceptance criteria without loads of additional documentation.
5. Learning Together
What needs to be done (and why) has been discussed and agreed by the team collectively. They have learned and solutioned together – everyone is inside the circle.
If I’m outside the circle I’m much more likely to throw stones at the solution and/or waste team members time while they explain the solution to me later in a hand-off.
Learning together fosters team work which is a much better way of working.
6. Minimising hand-offs
Hand-offs are one of the major sources of waste that Lean Thinking tries to eliminate. Hand-offs erode knowledge by as much as 50% per hand-off.
In the past there would have been several hand-offs as the team worked in a waterfall cycle – an analyst would have written up a long use case in isolation; this might sit for several months before it went to a developer; then it’s handed over to testing by someone who’s also got no understanding of the feature.
Now everyone who needed to be in the room was in the room and had the complementary skills to complete the feature.
Afterword
I delivered a presentation on “The Power of Feature Hypotheses” at Agile Africa 2018 using this and other examples. Here is the video link from the conference: https://youtu.be/CUVX1AiqQak?list=PLp6xQ3fl72zIu8FJjDtBUFUS0w1FPQhPZ
I am also more than happy to submit a speaker proposal for your conference. Feel free to contact me via email: therunningmann@gmail.com or Twitter @runningmann100 / @StuartDMann.
Follow Running Mann:
One Reply to “6 Reasons: From 12 Months to 2 Weeks for Feature Delivery”