“We delivered twenty points this week!” one of the Zoom squares declared in a proud voice. The rest of the grid in the virtual standup (zoomup?) nodded approvingly. This was apparently a big win for the team. Handing out virtual pats on the back would be a killer feature for videoconferences like this one. Yet the person reporting it was lying through his teeth, and everyone else was just going along with the hoax. And this wasn’t just some harmless half-truth, like the tooth-fairy paying children for dental discomfort, but a dirty, nasty scam that’s been hurting our industry for decades.
A while ago, this deception was “we delivered five hundred function points this quarter”. Today, for teams that don’t use story points, this might be “we delivered a big-ticket feature to production”. All these statements are lies, and people need to call them out as such.
Building code to make a feature, fulfil a story, or add a function to a product is part of our job. But considering that as delivering is a delusion, and quite a dangerous one. The core issue here is declaring victory too soon, which might cause everyone involved to get blinded by an illusion of progress. Of course, this problem is not exclusive to software projects. YouTube is full of professional sports players celebrating too early. Oddly enough, the sport from which the Scrum metaphor came into software is famous for such blunders.
In 1982, during the final moments of the college American football game between the Stanford Cardinal and California Golden Bears, the 144 members of the Stanford music band ran onto the field. Falsely believing that an opposition player had been tackled and that the game was over, they started the celebration. The Bears player, Richard Rodgers, was not done, and neither was the game. Rodgers managed to pass the ball to a teammate, who immediately charged through the musicians. The Stanford band obstructed their own players, preventing them from stopping the runner. In the final four seconds of the game, Bears turned a 20-19 defeat into a 20-25 victory. The chaos on the field, the players running past trombones, and the premature celebration became so famous that they’re now known as just “The Play”. Of course, there’s a YouTube video documenting it forever.
The core underlying issue is that value for software projects is tricky to measure, but tracking effort is easy. And organisations end up measuring stuff that’s easy, not stuff that’s important (for more on this, check Doug Hubbard’s excellent book How to Measure Anything).
Tracking lines of code was the original sin, which was discredited as a measurement of productivity sometime in the seventies. But in disguise, this problem returns over and over. Sometimes, it comes back in the primal form, often with the insanity that happens in large organisations when they adopt whatever they think is Scrum. For example, the “Boeing Agile Software Process” measured productivity as “source lines of code per hour” (according to the Case Study of a Program using an Agile Software Development Process). No wonder that their planes keep falling down. More often, effort metrics get disguised just enough to sound plausible as a way to track progress. The classic example is the Sentinel rewrite at the FBI, documented by Jerome Israel in the fabulous paper titled Why the FBI Can’t Build a Case Management System. The delivery contractor tricked the customer into measuring progress with function points, and kept “delivering” for years until it all fell apart.
Lines of code and function points may sound outdated, but story points are just the same trick in a new disguise. Story points may have some part to play in short-term capacity estimation, but not as a way to track delivery. In essence they reflect effort, not progress. Unless in a very rare case when a story is resulting in removing obsolete features, “delivering” points also results in more code, which makes the system more difficult to document, test and maintain. “We delivered twenty story points” really just means “we made the product more complex”. Function points were at least honest about that. Adding complexity for its own sake is not really what good software delivery should be about. If anything, we should be actively fighting against more complexity. I’d prefer a smaller and simpler system over a complex one if they do the same thing.
The next time you hear someone talking about delivering story points, remember The Play, and consider that you’re actually being played. Imagine the team being surrounded by a marching brass band if it helps. Story points, function points and lines of code aren’t delivered, they are “spent”. Or if that’s difficult to swallow, then perhaps “invested”.
We spend effort to hopefully buy something else. To check for actual progress, we should measure that other thing instead. Just shipping a feature that enables customers to schedule appointments is way too early to celebrate. Don’t let the band on the field yet. Adding features to a product is effort invested into some outcome for the stakeholders. Check if customers are actually scheduling those appointments, and if they’re doing it better, easier or faster than before.
If your organisation is forcing you to report on effort metrics, try changing the language around them. “We invested twenty story points this week” is a lot more honest than “we delivered,” because it begs the question about what’s the return on that investment.
Photo by Frankie Lopez on Unsplash
