Oct 5th, 2020
End to End Delivery
Part 7: Being Predictable
Written by: Craig Vosper, Chief Delivery Officer
How many of you have had, or are in, a project where you have turned to witchcraft, voodoo, or even scarier, Microsoft Project (never touch auto-level!) to help predict when the project will be delivered? Well, do not fear, predictability is one of our 4 delivery tenants and we’ll review it today! As a refresher, here are all 4 tenants:
- React to change
- Deliver value sooner
- Become more predictable
- Ensure high-quality work
Below you will find a representation of the “typical” software project, of which I assume many of you can likely relate to.
The vertical axis represents features, the horizontal time. The purple line represents when those features are “code complete” and the blue represents when those features are “production ready”.
Most projects spend significant time defining all requirements with the idea that if we get it “right” up front, we can be more efficient in our development. This is followed by development teams cranking out substantial changes in order to build those requirements.
In every project, since the dawn of time, we learn three things. First, we did not know all the requirements at the start. Second, the solution was not built to meet those requirements. Third, the amount of code introduced can make changes both time consuming and difficult.
This tends to place most projects in the blue zone of our chart, and the gap between code complete and production ready becomes your total “Release Risk”. While in this zone, its nearly impossible to estimate when we will be done with the project. So how do we avoid being in the blue zone?
Well, we already started down that path last week, talking about how to decompose work. The smaller the work estimated, the more accurate we become.
Define a set period of time in which work will be done and what “done” means within that period. For us, “done” means coded, tested, reviewed, and accepted by the customer. This provides the team a way to focus on what must be done within that time frame and helps them achieve a rhythm; doing it over and over.
Keep your team together. When projects are managed by moving resources all over, the teams are constantly in the “storming” phase of maturity. Move work to teams, not teams to work.
Minimize disruptions within your set period. These tend to come in two ways, either critical production defects or wonderful new ideas. One way to define your set period is identifying how long you can go without making changes. We tend to land on 2-weeks.
These processes will help you achieve a constant “velocity”. Velocity is a measure of how much work a team can do within your defined period. We will talk more about how to use this when we discuss reacting to change.
The chart below shows how you want your projects to look – you can see that release risk is always confined.
These techniques will help your teams become predictable and allow your business to make better priority and delivery decisions. Next week, we will talk how to ensure this predictable work is of the highest quality!