Deadlines - relics of the past or useful for motivation and scaling?

Something I heard the other day: "Deadlines are oppressive and we should never commit to them". That got me thinking about some of my experience and I instinctively didn't like the over-simplification of this statement.

We should always remember that things that worked for businesses in the past, but are frowned upon in the approach you are using, may still be valid for your business and team. I don't think it is healthy for us to think we now know everything, after all, rather like advice on what to eat, sometimes old things that we stopped doing turn out to be good for us.

Some of this may be against the current flow of thinking, but I think people should always question every hypothesis presented. Here I try to make the case for and against deadlines in the hope that people open their mind and continue to try new and old things.

The case against deadlines

Let's face it deadlines are not the flavour of the month, well century! Waterfall style development practices focussed strongly on setting milestones and tracking performance against these milestones. Change in these circumstances was seem as harmful as it often affected the milestones and therefore the plan.

Iterative approaches like Scrum and RUP set defined periods after which a release can occur. However these are not deadlines other than in a process sense - a ceremony can occur or a new set of processes can begin.

I suppose a deadline involved commitment and the last remaining idea of commitment has lost ground (Scrum no longer incudes the words commitment now uses forecast). Commitment is now almost a taboo word; if anyone mentions this word the resulting sucking through teeth is quite loud.

Why is this the case, after all we all make commitments every day. I will collect the children, get the groceries, turn up for work! Why do we now reject the idea so strongly?

I think the answer comes from a culture of misinformed expectations, a culture of bullying and setting of false deadlines to overtly manipulate employees into doing more than they are contracted to do.

There have been many times when I have worked with team under tight deadlines. I look back on these times and am sometimes amazed how these deadlines were met. Often team members worked late to achieve goals that were set with little knowledge of how long something would really take. There is no doubt that project teams, or at least individuals, were partially burnt out and needed a break. This is counter to the sustainable development principles central to agile and lean.

The case for deadlines

Motivation through deadlines

I'm not going to make the motivational point from a theoretical standpoint as I am not a Psychologist but I learnt very early that it is very important to do 3 things when talking to a team:

Determine the goal of the organsiation - paint the picture
Show the steps in getting there - show the roadmap
and most importantly - show the team role in delivery

Recently I was facilitating a retrospective on a project and the team were already self organising and looking for ways to work more effectively. During a retrospective a conversation started:

"The team are not motivated enough"
"What should we do?"
"I always find a deadline useful"
Why dont we set some deadlines we can commit to"
"Do we all agree"
"Yes"

The team were determined to deliver the vision but needed a clear path to get there. So they set deadlines.

So we did it and people became more focussed and met the businesses expectations. Do I think they would have done it without deadlines - I don't know, but I do know that it had a palpable effect on the atmosphere in the team. I also know that it was an interesting experiment and it achieved the overall project goal.

Cross team dependencies

Cross team blockers cost money, lots of it! Whether it is waiting for a build server or marketing need to know when a TV campaign can be booked or whether another team have a technical dependency on a new service, they all create waste. So when we are scaling agile. Teams depend on each other. They just need to know when something will be ready and they don't want to be blocked.

Having a deadline for a single product or feature can help communicate the prioritisation of a feature and create focus.

Knowing when to stop

Sometimes products have to hit the market in a certain amount of time or spend otherwise the cost may exceed to revenue or an opportunity may have past. I have seen projects with defined deadlines such as a event or a competitor launch.

These must be taken into account from a project stance but also at a feature level. Indeed features are often pursued even though they are proving more difficult than expected. Often a work limit or time-box can act as a useful tool to determine if something is worth completing, in other words whether to ditch the idea.

Conclusion - Beware the false deadline but embrace the real one

If deadlines result from a shared understanding of a common goal and if the team understand the reasons for its existence they can be useful tools in motivating and coordinating work.

If deadlines are false ie if you have seen then set and reset once the work overruns without any apparent business impact either: there is insufficient communications around the importance and effect of the work the team is doing or they are being set for arbitrary management reasons.

In any case I always ensure that I understand any deadlines have been set and why and ensure that all members of the team understand their role in meeting these deadlines and their responses listened to.