All right agile heads, buckle up because this one’s a doozy. In the first two posts of my Rethinking Agile series, I proposed two new methodologies to add to your agile practice. Those were “deload” periods and “Stand Down” meetings. In part three, I recommend removing something. That is, stop estimating effort or time.
Specifically, I mean estimates related to how long it will take to complete a backlog of work. There are many ways to estimate this time. In scrum, the predominant form of agile we use at Atomic Object, teams assign “story points” to individual work items.
Story point estimation is a “look ahead” measure that involves making a prediction about how much time the next thing will take. Some other agile flavors, like Kanban, don’t employ story estimates and instead rely on “look behind” measures such as cycle and lead time. These calculate how much time the last thing took.
In either case, though, the end goal is the same: to predict the completion horizon of a project, made up of many individual and interlocking pieces of work. Of course, it’s a fool’s errand, and the sooner we can all admit that, the better.
But don’t worry. In part four, I’ll give you an alternative practice to employ. It’s something everyone’s doing already, so we might as well be explicit about it.
There’s a famous aphorism in project management that comes from economist Charles Goodhart:
Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
— Charles Goodhart
This can be more simply stated as, “When a measure becomes a target, it ceases to be a good measure.”
For example, the purpose of estimating story points in scrum is to provide a software team with a predictive measure of progress. A team estimates its “velocity” from a rolling average of story points completed in a sprint. Thus, you can calculate a prediction of the completion of a project by dividing the remaining story points in the backlog by the velocity.
This is fine as long as the team works in isolation, ignorant of any business pressure on the project.
And so it’s never fine.
Inevitably, the measure of velocity becomes a target. Then, the company places expectations and goals on that velocity to make business decisions about roadmaps and budgets. This pressures the software team to sustain a velocity or do extra work to justify when velocity lags. Or, worst of all, the team might game the system to meet expectations.
And when velocity ceases to be a good measure, the effort expended to estimate story points becomes an exercise in wastefulness. This argument can be made about cycle time, throughput, and other similar metrics. We need to avoid making time a target.
Some teams accomplish this through a lot of hard work and discipline. These teams parry the thrusts and fleches of “business demands” to keep their velocity a pure and holy abstract number used only to plan the next sprint’s work. I think there’s a better way.
Dodging Goodhart’s Invisible Hand
There’s only one real measure in software development that bucks Goodhart’s Law. And, it’s right there in the principles of the Agile Manifesto:
Working software is the primary measure of progress.
When working software is the target measure, it’s very difficult for it to cease being a good one. Even if we spend time on a feature that ends up being the wrong one, we learn a lesson quickly through the application of working software. This is the core of agile’s value: we can pivot quickly and waste as little time as possible on experiments that don’t work out.
This leads us to an interesting corollary: when we measure progress in working software, we’re also inherently measuring its value. A feature that is “working” but not providing any value to the business or users is hardly progress. Ideally, the team learns why that feature wasn’t as valuable as previously believed. They can then adjust remaining project priorities accordingly.
In fact, the very first Agile Manifesto principle reads:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (emphasis mine)
So the question you should be asking yourself at this point is, “How do we make sure to continuously deliver value?” I’ll have an answer for you in the final post of this series.
Read the complete series:
Rethinking Agile, Part 1 – Deload Periods
Rethinking Agile, Part 2 – The Stand Down Meeting
Rethinking Agile, Part 3: Stop Estimating Effort