Agile Development

Arbitrary Deadlines are Arbitrary

What’s so bad about deadlines?

Let me start by saying that deadlines can be a really useful and valuable part of the development process. When they are widely known, and communicated effectively, they can help you to plan, prioritise, and organise your work.

The reason for the deadline is especially important, as knowing why something has a deadline allows to focus efforts into the right place, or even consider alternative solutions if the planned solution is unlikely to be done in the time. Knowing why you are driving towards a deadline can also be quite motivating. Maybe a customer is having a big launch and you need to support them, or big regulation changes are coming into force and there could be serious repercussions for the company if they are not adhered to. Both of these provide different types of motivation, but they have concrete deadlines and everyone understands why the deadline is there.

The problem is that there are far too many deadlines in software development and nearly all of them have been plucked out of thin air, often on the whim of some middle-manager in order to appear in control.

Another likely situation is that a team is asked for an estimate, and then as if by magic the estimate snakes its way through meeting rooms and conference calls, slowly becoming a set-in-stone deadline. It’s added to presentation slides and calendars and discussed at senior leadership team meetings. Eventually slithering its way back to the original team who gave the estimate, to bite them on the arse.

A less obvious example is a sprint. Sure, it’s a staple within agile development, but the rigidity in which sprints are used in some companies means that teams are having arbitrary deadlines imposed on them every two or three weeks. Many would argue that a sprint is a target, not a deadline, but ask anyone who feels they need to rush to finish a task before the sprint ends which it feels like.

These arbitrary deadlines may seem harmless initially, maybe even beneficial. After all, “deadlines can be a really useful and valuable part of the development process”. The reality though is that they cause a lot of problems, in a few different ways.

Speed > Quality

One major issue with all of these deadlines being created is that it often puts the focus on speed over quality. Sure, some people will say that they can work quickly and still maintain that quality, but those people are what I like to call ‘liars’. It’s simply impossible to do the same work faster without a drop in quality.

The reason for this is simple, if you put pressure on someone to go faster, mistakes will happen, and shortcuts will be taken. Of course they will. Designers will be discouraged from trying multiple designs, developers will skip code reviews or deployment steps, testers will miss bugs and issues because they’re focusing on the happy-path.

These things may not be noticed in the short-term, but long-term they will result in poorer software, and inevitably less happy users. It only takes one or two things to make a customer lose faith in a piece of software, and that is especially the case in 2020 when there is so much competition out there.

If everything is the priority, nothing is

You’d be hard-pressed to find someone who’s worked in development for more than a year that hasn’t come across this problem. Multiple pieces of work with clashing deadlines, resulting in everything being seen as a priority. It’s only at that point do you actually find out which deadlines are legitimate, and which are arbitrary, normally because someone from senior management has to step in and make a decision.

These situations make it extremely difficult to plan effectively because it is impossible to prioritise. How do you decide what to work on next, if you don’t know what the priority actually is? You just can’t.

Arbitrary deadlines devalue real meaningful deadlines and muddying the water in this way often results in constant context switching and sprints to the deadline, which as mentioned earlier, will be at the detriment of the quality.

It’s the people that suffer most

The worst thing about all of these arbitrary deadlines imposed on teams is the impact on the team members. It’s easy to forget amongst talk of ‘resource’ and ‘man-days’, but we’re talking about real people here, with real feelings.

Deadlines can be a massive source of stress and anxiety, and they can really take their toll on people. They may work late to get the work done, which eats into their free-time, or they may lose sleep due to the pressures they’re feeling.

Tensions can also build up within a team under the pressure of deadlines. People react differently under stress, and often they will become agitated, snappy, short-tempered etc, and communication becomes more difficult. This not only makes it difficult for the team to work together, but it will have an impact on the mental health of everyone in the team.

Whether or not a team or individual met a deadline can also play into performance reviews, pay reviews and bonuses, which is mental considering everything we’ve talked about in this post. Your future in the company may be decided based on whether or not you rushed to meet a deadline that didn’t need to exist in the first place.

That’s an obscene amount of pressure to put on people unnecessarily, but it happens nearly everywhere. Even at those companies who make a big song and dance about how much they care about their employees’ mental health.

Final thoughts

Sure, deadlines can be useful, but too often the deadlines we see being thrown around an office are arbitrary and serve no purpose other than to add unnecessary pressure on the teams carrying out the work.

We should take a long hard look at every deadline we think we have and ask ourselves whether what we’re looking at is really a deadline, with understandable rationale for being a deadline, or whether it’s simply a target, something to aim for but is flexible.

If we don’t, the outcome will continue to be low morale, poor quality software and unhappy customers.

One reply on “Arbitrary Deadlines are Arbitrary”

I’ve long argued against arbitrary time boxes for many projects. Why are we gathering to put together a bunch of tickets that we think we can get done in a fortnight? If it turns out that it takes us less time, we’ll just pull more in. If it turns out that it takes us more time, we feel compelled to ask why.

In my case, it’s always the same: My estimates are always hopelessly optimistic. My boss used to double them. Now, he triples them.

I’m not saying that the cadence is a problem. Having a routine for when we gather to take stock of a project, adjust course, talk to external people maybe – all good. It’s the board admin that kills me. Why is this better than a prioritised stream of work?

Maybe I’ve been working in the wrong environments, on the wrong projects, or with the wrong people, but I suspect my variety is ample enough to know: sprints best serve a business function, not an engineering or delivery one. They break a thing down into describable blocks, neatly divide some accountability, and generate metrics that (inaccurately) mark some sort of progress or success. Maybe compared with “nothing” they’re good, but surely there’s something actually better?

Leave a Reply

Your email address will not be published. Required fields are marked *