People come and go in the world of agile development saying this phrase from the title: “We don’t work with deadlines here” or “Agile development has no deadlines”. The curious thing is that at no point in the agile manifesto are deadlines mentioned. Neither in the 4 values nor in the 12 principles. Not even to say that they exist, much less to say that they don’t.

But these phrases are easily found in conversations, especially among developers. And, yes, I’ve been there. I believe I said things like that about 12 or 13 years ago.

I associate this distortion mostly with two factors:

1. A misinterpretation of the agile manifesto values, especially “Individuals and interactions over processes and tools” and “Customer collaboration over contract negotiation”;
2. An exaggeration and wrong decision-making based on the premise that human beings are bad at estimating deadlines.

I will try to separate my reasoning on these two fronts.

Misinterpretation of values

Often the understanding of the two values mentioned ends up being a little wrong in my perception.

I’ve had discussions where these values were used as arguments for not estimating project deadlines and trying to talk to the client that “it’ll be ready when it’s ready”.

The idea behind this is that when you talk about “individuals and interactions more than processes and tools” it would be a justification for not doing any kind of estimation or measurement because that would be “processes and tools”. Furthermore, giving the customer a deadline would be “negotiating a contract” and if we do that “we are not following the values of the agile manifesto”.

The first case is a very easy argument to justify anything I don’t want to do. Don’t want to have to follow some code pattern? It’s a process, so we won’t do it. I don’t want to follow an X or Y architecture pattern that the team has been following? I call it a process 😂.

All kidding aside, for both cases, there is a sentence in the agile manifesto that comes right after the values and that people tend to ignore. It says:

“That is, while there is value in the items on the right, we value the items on the left more.”

The phrase says by itself: we should not ignore what is on the right but rather focus more on what is on the left. We value individuals and interactions more, but there is still value in processes and tools, we just have to be judicious and prioritize one over the other.

When we talk about the value “Collaboration with the client more than contract negotiation” I think that’s where the thing of discussing a deadline ‘screams’ more. Customers/businesses will invariably need to have deadlines, forecasts and predictability for decision-making and competitive advantage. And some of the principles of the manifesto bring this intrinsically when they talk about “satisfying the customer”, “aiming at competitive advantage for the customer” and when they constantly include “business people” in the principles.

Humans are bad at estimating deadlines

That’s a fact, it’s not an exaggeration (and maybe not just deadlines, but to make the text less long I’ll just stay there).

It would be an exaggeration to say that, therefore, nothing should be done about it and remain adrift. As the elders would say, it’s “throwing the baby out with the water”.

As I said above, businesses (whether they own or clients) need data to make decisions that direct them towards a north and that can even help as a competitive advantage. One of these data is the predictability (or deadline) of delivery of a feature or product, even for there to be some kind of planning.

This should not mean that it is necessary to pass an exact deadline with date and time for the delivery to happen, but rather having constant conversations between the team and the business so that there can be predictability. Again I’m going to go back to the principles of the manifesto which says:

“Business people and developers must work together daily throughout the project.”

Paraphrasing what Érica Briones said in a conversation on Twitter, telling the business that there must be a margin of error or even saying that the team will not work making estimates, in a #NoEstimates process, for example, is something very different from saying It doesn’t work with deadlines.

“Solution” to the problem

I’ve said it a few times throughout the text, but it bears repeating: Business needs predictability. One way or another, we need to be able to provide this to aid decision-making.

When the development team is afraid to come up with a deadline or estimate, 2 things are likely to be happening:

1. The team fears that whoever receives this information will assume it is something signed and written in stone that can never change;
2. The team cannot or does not know how to give an estimate because it does not know how to measure these things.

Interestingly, the solution for the first item is precisely in the value of the manifest, which is mistakenly used to not make estimates:

“Customer collaboration more than contract negotiation”

A safe environment needs to be created and everyone is aware that software development is not a complicated scenario, but a complex one (Cynefin). And this collaboration with the client needs to be constant, with transparency and negotiation also constant and on both sides.

As for the issue of not knowing how to generate these estimates, getting metrics, working on continuous improvements in the delivery process, and constantly adapting are measures that gradually correct this problem. But I think this deserves an exclusive text about it.

What is important is a broader understanding of this topic and stop replicating these false arguments about deadlines. And from that, we can better understand how to get the right environment and data to work with the necessary estimates.