During a workshop about success factors of projects, many participants put down “a positive time constraint” or similar words as an important part of a successful project. No one seemed keen on using the word “deadline”, but that was in essence what they meant.
I have always actively tried to avoid deadlines when possible, for a number of reasons. Chiefly:
- Deadlines have a tendency to become the focus point and weigh heavy on evaluations, even when scope and quality are said to be a priority.
- They are a significant cause of stress in team members – especially when development and maintenance are conducted by the same team (which is almost always the case).
- In a properly functioning chain of continuous delivery, deadlines are unnecessary – push to production as soon as you’re done.
A deadline is only a “positive time constraint” when used as a tool to focus resources and scope. In a properly run organisation, this should be obtainable even without a deadline – it’s all about priorities.
The magic is not in the deadline, but in the focus of resources and scope.
This usually becomes increasingly hard to maintain over time, especially when service and maintenance enters the picture.
In every IT department and development team, there are varying and unpredictable amounts of fires to put out and legacy systems to duct tape. This easily eats a lot of time, causing stress among developers, as they don’t feel they’re “doing what they should be doing” to meet the deadline. Because deadlines have a tendency to become a focus point. A missed deadline can cause feelings of failure, even when scope and quality are said to be a priority.
As development drags on, clients and product owners come up with great new ideas to shoehorn into the development cycle, and happily pile more feature requests into the pipeline. The project manager or agile coach will constantly have to fight off scope creep and defend the sprint or previous prioritisation to meet deadlines.
It’s a waste of time and energy, since a lot of deadlines are arbitrary by nature.
In my experience, product owners tend to throw in more or less random deadlines to secure development time during scheduling. It’s a negotiation strategy, to up the importance of their particular development needs. The date in itself carries very little value or significance outside of project documents. Deadlines are often set, rarely met, and when missed have no real consequence.
Deadlines may of course be necessary at times, for legal or technical reasons. My point is not to eradicate them, but to use them sparsely and wisely – especially when using continuous delivery.
Push for a well defined scope, dedicated developers and head room during planning, and you’ll get the same – perhaps even better – results as with a deadline, while reducing causes of stress among developers.