The word deadline reminds me of uncivilised times when guards were shooting prisoners who were trespassing a line, sometimes even invisible, representing a limit beyond which there was freedom.
Prisoners died for going beyond the deadline. Software projects die for managing to stay behind it.
What kills projects that respect deadlines
How can a project fail if it delivers within the deadline? Isn’t it what they are supposed to do?
When managers set deadlines, developers feel that they must meet them at all costs.
Deadlines may be unrealistic and force developers to work long hours, or may be reasonable. In the latter case they may still cause problems.
Deadlines don’t make developers more productive
Contrary to popular belief, developers who are required to run against a deadline are not more productive.
Researchers have found that developers who have no deadline to meet may be 50% more productive.
Deadlines cannot be correctly estimated
They are easily underestimated, particularly when people who define them have little knowledge of how the software development process works.
Even if a deadline originates from accurate information, it may still have large statistic variations because developers may encounter technical problems, the task’s definition evolves or the application has to undergo unexpected redesign.
It’s very common for the development team to have to change the scope of an application sometimes even radically. This makes deadlines even more dangerous. The solution is not to enforce the deadline at all costs, results would suffer or just be zero.
Developers who run cannot think
It’s already hard to think in most working environments where interruptions are galore. Some developers take refuge on a hammock to be able to mull over complex problems.
Deadlines will chase them even there and disrupt their ability to figure out a solution.
Deadlines tend to become a developer’s major concern. She will see thinking as a waste of time. She will rush to write the code that first comes to her mind as a possible solution.
Quality gets put aside
When rushing to stay within time limits, developers sacrifice quality. Their code will barely work, bugs will abound, documentation will be absent and structure will be precarious.
This will make developers less motivated. Who can be motivated to build something mediocre? Loss in motivation will make developers less productive.
What about cooperation?
When developers have to run, they run alone. Managers measure their individual performance forgetting that it’s the team that produces results.
Developers are reluctant to help others because this will slow them down or so they believe.
Actually cooperation motivates and improves productivity, at least the team’s.
Time limits shut developers up
Time limits are a motion of no confidence. Managers set them because they don’t trust developers with getting things done without deadlines.
Developers who are not trusted think that they have no right to ask questions, they just keep their heads down and produce.
Asking questions is the most important activity developers do to achieve good results or sometimes any result at all.
How did we get here?
How is it that we are still using deadlines to organize work when they are actually harmful?
If a company is making shoes, workers’ tasks are simple, well-defined, organized in procedures and ask for no problem solving skills or only for elementary ones.
Everything is predictable and setbacks that cause delays are under control most of the times.
Managers don’t need to understand how things work. They have just to single out the worker responsible for a delay or a mistake and reprimand or fire them.
It’s called train-wreck management, from a train accident that happened in 1841.
It doesn’t improve quality or productivity, but, when activities are simple, it doesn’t do much harm either.
In the years 1950s, workers’ activities started to become more and more complex.
Software development is one of the complex activities that begun to emerge and become increasingly common in that period.
IBM failed hard to create the factory of software
Still in the second half of the 20th century, IBM tried to create the factory of software.
It was just natural to organise the production of software in the same way industrial activities were.
IBM designed well-defined processes, set deadlines, assigned specific goals to each developer and measured productivity.
They invented the waterfall model showing little originality since they just duplicated the idea of the assembly chain.
It was a disaster. A very high percentage of projects collapsed under the weight of their own complexity and ambiguity.
In human history it often happens that we don’t learn from past mistakes. We are still pretending to manage software projects — and any other complex human feat — in the same way we manage the production of shoes.
Enter the System of Profound Knowledge
We owe it to Edwards Deming, a management consultant who first realised that
we have to deal with complexity in more sophisticated ways.
Deming helped many Japanese companies to figure out how to successfully handle complex production.
Agile to the rescue?
Agile is a set of values and principles 17 software developers elaborated in 2001.
These developers distilled decades of profound knowledge about software development and the post-mortem analysis of innumerable projects.
It’s not a case that we can’t find deadlines anywhere in the Agile manifesto.
Its signatories knew, back in 2001, that hard-to-define, changing, unique tasks are not likely to survive deadlines.
Agile didn’t survive either. In most cases it’s badly implemented. The train-wreck management killed it.
What to do with deadlines?
If you can do without, you will see motivation, productivity and problem solving improve, sometimes radically.
If you can’t, you have to treat a deadline as a risk. You have to design a plan B to try to save the project. If the deadline is so disruptive that it forces developers to produce useless code, the only plan B you can envisage is to scrap the project and restart from scratch.