Advocating Against: Razor Blades

Despite my concerns about experienced coaches advocating against practices that are often quite useful, there are a few things where I’d at least advise great caution.

I sometimes use the phrase “giving razor blades to babies”, in reaction to advice from experts. This will typically be advice to use some approach that is quite powerful in the hands of experts, and quite dangerous in the hands of the less experienced practitioner.¹ In this article, I’ll talk about some ideas that fall in or near the Razor Blade class.

I see that I plan to start with some well-known and commonly recommended ideas. Read on to find out how firmly I’ll advocate against these ideas. I look forward to finding out as well.

The Backlog

Mary Poppendieck, of Lean Software Development, has long objected to Scrum’s notion of the “backlog”. As I’ve said and written before, she makes some strong points. Here are some of the issues that can arise with the backlog:

Limited Collaboration

Among those of us who have been swimming for a long time in the Agile seas, it is clear that collaboration is at the center of real success. The backlog need not work counter to collaboration, but it often does. Often, the Scrum Product Owner brings in tightly-specified solutions, and the Dev Team’s job is to implement them.

This is usually quite wasteful of the team’s capabilities. Agile works best when the whole team, business-side and technical-side, collaborate on the creation of solutions to problems. Working from a backlog of features that are already thought out reduces this collaboration, and leaves valuable ideas unexplored. The unexplored ideas would often create a better product, and just as often would have come up with a less expensive faster way to solve the problem.

Reduced Agility

Presumably “agility” is about the ability to change direction dynamically, as needed, in order to deliver the best possible results in the shortest possible time. When we have a predefined backlog, a list of the things we plan to do, that flexibility is limited, because the team’s stakeholders feel that they have been promised a certain set of things, and are reluctant to adjust that set, even when in fact it would be a good idea to do so.

Scrum, of course, calls for a Product Owner who is fully empowered to adjust the plan for best results, but most teams exist within a system of stakeholders who have expectations. The backlog tends to get nailed down, and this tends to reduce agility, and thereby, to reduce the return on the investment in the team.

The Razor’s Edge

A backlog made up of “big” problems, and an understanding of their rough priorities, works better than a detailed list of requirements renamed “The Backlog”. My experience suggests to me that the great majority of teams are working more from a laundry list of requirements than from a much less detailed list of problems needing solution.

These teams are probably not delivering at the pace they might, nor delivering a product that is as appealing and valuable as it could be.

I’m not prepared to say that a backlog is always a bad idea: we need a growing sense of the problems we’re to solve, and how we might solve them. I do think, however, that a long detailed backlog is probably a razor blade, and you should proceed with caution.

Story Estimation and Story Points

You’re probably aware of the controversial “No Estimates” topic that shows up on Twitter as well as conferences and blogs. I’ve written about estimates before, and surely will again. Like now.

You can make a pretty good argument that estimating stories is inherently wasteful. There are decent arguments that it is “necessary waste”, although many of those arguments don’t bear too much scrutiny. And certainly, if you’re required by management to do story estimation, with or without story points, you’d probably be wise to do them. However …

Abuses

There are many ways to abuse story estimates. They could fill a book, and in fact probably have. We’ll just touch on a few of them here.

Estimates as Promises

Too often, despite all the effort we put in to make it clear that these are just estimates, and that they’re not guarantees, management sometimes treats them as promises. This interferes profoundly with the management-team communication flow, and almost inevitably results in inflated estimates and inferior results.

Story Points as Target

Too often, management looks at a team’s estimated and actual story point delivery and demands “improvement”. While I’d agree that every team can very likely improve its efficiency, the way to bring that about isn’t by putting pressure on them. Instead, they need detailed and wise support for finding things that slow them down and removing those obstacles. The pressure from management, again almost always, creates sandbagging and slows things down, while creating trust issues in communication.

Story Points as Comparison

“Team B is doing 25 points per Sprint. You’re only doing 15. You need to improve.” This is a particularly pernicious but all too common result of using story points. Someone decides that they should be standardized, and teams should be measured by how many they do. This despite the fact that the teams generally are solving different problems with different people, and quite often with different technology. Very bad idea.

The Razor’s Edge

Quite a few teams have measured both story points completed, and stories completed, over time. They have invariably found that the two variables track one another quite well, and in general stories per unit time is more stable than story points. This leads many Agile “thinkers” to the conclusion that counting well-sliced stories is a better way to track and forecast results.

There’s good reason to believe that small stories are inherently more stable in how long they take to complete. Mind you, this is not a perfect prediction, but it’s a decent one. A small slice of story is likely to be better understood, and therefore to be resolved in a shorter amount of time.

Here again, I’m not prepared to say never to do story estimation, with or without points. However, focus on estimates, and especially on actuals, within a team or across teams, has some pretty sharp edges. Proceed with caution, and think about trying alternatives.

Backlog Estimation

But what about long-term planning? Don’t we have to have a complete list of all our stories (see Backlog), and estimates for each one (see Story Estimation and Story Points), in order to know “when we’ll be done”?

I would answer “No”, for two reasons. First, I think that management will do better with any effort, but especially with an Agile effort, to pick a ship date and manage content to meet that date, rather than estimating effort and picking a date from that. (One good reason for this is that whenever I’ve seen developers estimate everything and add it up to get a date, management always insists on negotiating that date inward anyway. Once that’s in play, about the only thing we can be sure of is that everything isn’t going to be done by that date.)

The other reason, and to me it’s a more powerful one, is that Agile methods allow us – arguably require us to have a running, tested, shippable version of the product all the time, and to demonstrate that product and review it with management very frequently. This means that we have ample opportunity to focus on a lean version of a product that resolves the key problems, and to have it ready to go on the date.

If it does turn out that there’s more to do than is possible by the date, everyone sees that coming down, and everyone participates in deciding what to do about it. Do we cut scope (my recommendation)², or do we extend the date? Either way, everyone sees the same changing product and the same changing world, and gets to participate in the decision.

Forgive what may appear to be cynicism. It’s really not. Making the date is a big deal in everyone’s mind, and the details of what was in the package are generally long forgotten.

A random idea

I haven’t tried the following, and I don’t know anyone who has. Suppose we are planning some new product, and we have some idea of the problems it solves, and we really need an estimate to use for that first release date.

We’re probably stuck with creating at least some kind of backlog here. The more abstract we can keep it, the better we’re likely to do, as discussed above. But we’ll probably have to create something a lot like stories.

But what if, instead of estimating those stories in time or points, we sliced off a few one-acceptance-test sized slices, and then estimated how many slices there would be in each story? To do this, we’d have to look at a bit of detail, but we’d be sizing things in a fashion that is relatively easy and relatively accurate.

Then we add up how many slices we think there are, and multiply by how many days (one, I hope) we expect slices to take.

Again, I’ve not tried this, but if I were trapped and needed to do a date forecast for a first release date, I might try this first. For extra checking, we might even estimate a few of the stories both ways, to get a sense of how well this approach tracks.

Caveat Emptor, but I think I’d try this.

More To Come

I’m sure I’ll have more to say about razor blades. Hit me up on Twitter with ideas.