The power of small development phases.
A 5 minute read, written by Mike Carter on 17 December 2018.
Imagine this scenario — someone in your company proposes a new software feature with the potential to save the business thousands of hours of human effort per year. It’s going to replace it all with error free, instant, cheap automation.
Planning of the feature begins, and strategic stakeholders add scope with “could it also…” questions in order to maximise benefit to the business. Then, as possible edge case issues are identified, operational stakeholders add scope with “what about…” questions so that every angle is covered.
Discussions drag on for weeks, and before you know it, the small feature has grown into a large project. At this point, getting agreement between everyone involved has become very difficult.
Eventually a compromise is reached and development on the feature begins. However, progress is slow as all the additional requirements and edge cases are worked through. Unanticipated blockers are frequent, and the non-technical stakeholders start to wonder what’s taking so long.
Over time confidence in the work drops, and eventually other urgent changes take priority. Work on the feature is paused, scaled back significantly, or sometimes even cancelled altogether. Stakeholders and developers are all left frustrated and disheartened by the experience.
Sound familiar? It doesn’t have to be this way. All of this pain can be avoided by just breaking your projects into small and separate phases.
Using simple numbers, if there’s a 20% potential improvement from some new feature, there’s nothing wrong with implementing that in eight 2.5% phases; each one agreed, worked on, and deployed separately. In fact, this approach has many benefits:
- Small phases deliver results quickly. Instead of waiting 8 weeks for a 20% benefit, you accumulate a 2.5% benefit each week for 8 weeks, starting from the end of the first week.
- Small phases are resilient against competing priorities. If you have to abandon things half-way through, you’ll still have developed, tested, and deployed a 10% improvement.
- Small phases avoid sunk cost. If your planned improvement doesn’t work, you can change course without throwing away months of effort.
- Small phases build trust. Specifically, this occurs between developers and stakeholders. No more wondering whether anything will ever be finished.
- Small phases are easy to get agreement on. Fewer people need to meet and discuss fewer changes, and contentious points need only hold up one phase, not the whole project.
- Small phases are easy to renegotiate. If alterations need to be made, small changes can be renegotiated without needing to re-check agreement on everything else.
- Small phases are simple to estimate. Smaller changes to a system are easier to estimate accurately, so everyone gets a better idea of when things will be done.
- Small phases are less risky. Bugs may occur, but by keeping each deployed change small you risk deploying fewer bugs at a time, and make any that do creep in easier to identify and squash.
So, next time you‘re struggling to get things done, try breaking your project up into small phases, and see how much easier it is to release features, keep stakeholders happy, and build trust.