Tuning into Predictability
Kanban Eurasia — Minsk, Belarus 2020
You might recognize him as the figure on the US fifty dollar bill. Ulysses S. Grant, the general who ultimately led the Union victory over the rebel army of Robert E. Lee, one hundred and fifty five years ago. Grant started as a commander in the West at a time when most of the fighting was way back east. He showed some initiative and won some battles, and was promoted, but he was still under the control of the general back east. The committee of Washington generals sent him his orders: occupy the railroad lines to deny their use to the rebels. Back in Washington, that had big table top maps complete with cities and the connecting rail lines, with little figures to represent the soldiers.
The rebels didn’t even try to defend the railroad. With Grant’s men stretched thin to guard the rail lines, the rebels just attacked weak spots at will. With all the railroads in Union hands, the rebels just got stronger, and Grant lost more men, every day.
Grant finally got out from under the thumb of the Generals back east when he won the battle at Vicksburg, and then he had the support of Lincoln to call the shots. Grant’s strategy was brutally simple. It was not to occupy territory or even to win battles, but to destroy the enemy army. Simple.
Our goal in Kanban is not the destruction of enemy armies, but it is just as brutally simple. It is an undistracted focus on delivering work. You can think of the Generals back in Washington as Scrum Masters, with elaborate strategies for perfect burndown charts booking Scrum Velocity even while heading for the inevitable missed deadlines. Kanban brings a Ulysses S. Grant focus to software engineering. It’s not magic, and the work is still hard, but there is no substitute for unflinching focus.
The keystone princple of Kanban is “start from where you are” Visualize the work Limit Work in progress Manage the flow Make policies explicit Implement feedback loops Learn and improve
While other Generals complained of the things they didn’t have, Grant embodied the Kanban principle: Start from where you are. Using a stick drawing in the mud he had a remarkable gift for visualizing the work before them. As a former quartermaster general, he was unsurpassed in his attention to the business of managing the flow.
The whole point of estimation is to support decisions. If an estimate doesn’t help resolve uncertainty about a decision we have to make, then it doesn’t have any value. When pro forma estimates are taken as performance targets it tends to result in negative value. But there is substantial value in the estimation process when is is understood as a a quantitatively expressed reduction of uncertainty based on observations.
Estimation vs Prediction
Predictability builds and holds trust, a core Agile value, better than does delivering more with less reliability.
— David J. Anderson
Estimation is not prediction, and predictability does not result for forecasting future events. Predictability in software delivery is achieved by identifying and eliminating constraints on the flow of work. You don’t have to estimate the work in order to achieve flow, at least not in the way most people think of estimation: assigning time values to forecast the effort that will be required, pretty much as waste of everyone’s time.
Many teams embracing #noestimation forego the numbers game altogether, using more reliable flow metrics against unestimated work provide a more accurate read on future team capacity.
Making sense of estimation strategies
As important as estimation is to setting customer/stakeholder expectations and ultimately to paying the bills, there is surprisingly little discussion about what makes for a sound estimation strategy.
There’s an assumption that estimation is something that good developers should be good at, with the unspoken the corollary that failure to meet estimates is somehow the mark of an amateur. Once burned, developers push back that they lack specification. Backlog refinement meetings are scheduled. Time is set aside for technical planning, with expectations set, but often the cycle is repeated, leading to the question, what is this estimation thing?
- Understanding the principle of information entropy as the basis for uncertainty reduction
- How to unbundle assumptions using range estimation
- How to qualify range estimates with confidence interval
- The array of measurement methods using Ration, Interval, Ordinal and Nominal scales
- Analytic, Analogous and Parametric techniques
- Story Decomposition Practices
We’ll go through a number of techniques to verify your estimates.
- When does it take to make traditional time-against-task estimation effective?
- What problems are we trying to resolve with Indirect estimation strategies, such as Planning poker, Story points, Fibonacci spreads or the Cherry-pit Mustang thing?
- What is “no estimation”, really? How would that work?
- estimation calibration, of “sense of size”
We hope to leave you with a better understanding of the various approaches to estimation, and to understand what they’re trying to achieve, to give you greater confidence in the choices you make in this critical area of software development.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.