Poor Decisions Made Slowly

In an article published in The Washington Post on July 22, Daniel Carpenter discussed why our government always seems to be working down to the wire. He blames deadlines (both real and conjured), stating that the "eleventh-hour effect" tends to delay decision making until the last possible moment:

When deadlines are imposed, decisions and bargains that could happen more quickly — because of momentum or normal work flow — often end up getting put off until the last minute. Social scientists have referred to this as the "eleventh-hour effect," and we see it both in experiments and in real life.

Furthermore, as a Harvard researcher studying the effect of deadlines on the FDA drug approval process, Mr. Carpenter and his colleagues discovered that drugs approved close to the Congressionally imposed deadline tend to be recalled more often than others:

A few years ago I joined some Harvard Medical School colleagues in examining the deadlines that, since 1992, Congress has placed upon the Food and Drug Administration's drug reviews. Our research found that medications approved right before these deadlines were considerably more likely to be pulled from the market or have significant warning labels attached later on.

In other words, deadlines cause poor decisions to be made slowly.

I must admit, as a proponent of agile software development practices such as continuous, iterative planning, I find more than a grain of truth in this statement — and not just within the bounds of our government. In fact, it has been my experience that deadlines rarely encourage people to complete their work early, as the task at hand tends to fill the time available. And, besides, experience has also taught me that deadlines often seem arbitrary, feel capricious, and demotivate teams.¹

Granted, businesses need to be able to plan around software development projects. There are end-users to train, products to market, and systems to integrate. And, no matter how arbitrary it may seem to software developers, a deadline does provide a business with a stake in the ground around which to plan these other activities. In this sense, deadlines perform a valuable service to the business. However, due to the "eleventh-hour effect" and the rush to finish work on time, deadlines can also do quite a bit of harm to an organization's systems.

Therefore, my preference is to manage projects using a stack-ranked, estimated backlog of user-stories and team velocity. The backlog shows me what's complete, how much work remains, and in what order it will be completed. The team velocity tells me when I can expect a specific story to be completed.

So, if I have a specific business need to see story X completed by date Y, then I can make the appropriate adjustments to the stack-ranking of the backlog without putting undue pressure on the development team. Furthermore, because user-stories are discreet, end-to-end slices of functionality, I can deploy them as soon as there’s sufficient business value to offset the costs of deployment.

Footnotes:

1. Early in my career, I worked for a company that threatened to fire their entire development team if we did not ship all the projects we were working on by the end of the month. This is what I mean by an arbitrary, capricious and demotivating deadline. Oh, we managed to meet the deadline. It took some serious corner cutting. But, we shipped the software. In the end, though, it didn’t matter. We all left the company within three months, anyway.
2. Hat tip to Ezra Klein for the reference to the Carpenter article.