Imagine you wanted someone to build you a house and they told you that it would take a year to build. “Unfortunately”, you tell them, “I already told my family that we’d be living in our new home in 3 months”. Of course they tell you they can’t build it on such an aggressive timeline. But, lets say, hypothetically, you had the power to convince this person to agree to your deadline. Would you feel comfortable living in that house?

Imagine the amount of corners the builder would have to cut to meet your deadline. Building a house that way would probably break all sorts of laws. Yet, we do this on a regular basis in software: A manager tells developers about a deadline that they don’t believe they can meet and the development team has to scramble to try to meet it anyway.

Developers have to have a say in deadlines or you will never be able to build high quality software. This is step 1. I don’t use the phrase “step 1” lightly. I literally mean that this is the whole foundation that quality software is built on top of. You must tackle this first.

If developers don’t have a say in deadlines, any attempt at quality will be undermined by unrealistic schedules. Corners will have to be cut to meet these deadlines (AKA technical debt), but the developers will never have any time to go back and pay off this technical debt. Quality can only get worse in such an environment. No process, including Agile, can overcome this.

The only people that know how realistic a deadline is are the people that know the inner workings of the project: The developers. And if they aren’t involved in setting deadlines, an unrealistic deadline will be picked most of the time. That’s because, all things being equal, delivering a feature sooner is better than later.

Now you may be asking, what if the developers don’t agree with the deadline? At this point the managers and the developers should negotiate.

One thing to negotiate on is scope. e.g., “What if the building didn’t have AC by the deadline but we installed it later?” This often goes back and forth many times as the manager and the developer come to some agreement.

Another thing to negotiation on is the deadline itself. e.g., “Realistically, we’d probably complete that 2 weeks after the deadline. Is that ok?”

And third, quality can be negotiated on. e.g., “These windows are poor quality but they’ll save me a ton of time to install at first. Then we can go back and put some better quality windows in later.” Technical debt is an example of this. But quality can only be negotiated on if there is trust between management and the developers. The trust needs to be that the developers will be allowed to go back and put some better quality windows in later.

By the way, this shouldn’t be unquestioned trust. The manager should ask why the developers won’t meet the deadline. Maybe the developers will say, “Because it takes 5 weeks to lay a foundation for an apartment complex”. Then the manager could say, “We don’t need that. We only need the foundation for a single family home”. This communication is very important.

But, this whole system falls apart when developers have no say in deadlines. The end result is poor quality software every time.