hypanis.ru Enemies of Agile: Bad Language #2 “Deadline” – Rob Aston

Enemies of Agile: Bad Language #2 “Deadline”

He’s Dead Jim!

OK it’s not because it has the word “dead” in it, however undesirable, there are plenty of other words in the same boat such as deadpan, dead end, that doesn’t offend. No, it’s not that as such. It’s also not because some people would like you to interpret the word literally. The word is often used to emphasise a “cannot miss at any cost” date even when that does not reflect reality. As someone once pointed out, the “deadline” their team had been given was more akin to a “sadline”, i.e. someone will be sad if the team misses it and no one will actually die. This sounds trivialising but underlies the context of the situation. The team was most likely given yet another “deadline” without being clear about what this actually means.

Deadline or Headline

This highlights my actual gripe with the word. It’s the way the word is used and the associated communication that goes with it, or rather, the lack of much-needed communication.  How many times has a team member been working to a “deadline” without the knowledge of the vision and goals and the benefits of hitting the date and the impact of missing the date? There are two sides the coin here: (a) the deadline is communicated with insufficient information as if the word deadline is enough to get the team to hit it, and (b) deadlines are accepted by some teams and individuals without asking for more information.
The word ‘deadline’ alone is too binary. It paints all target dates with the same brush. A better terminology is to speak of a “target date” and crucially state the benefits of hitting that target, the impact of missing it and any tolerances. By tolerances I mean, at one extreme “if we slip by one day the whole initiative has been a waste of time!” versus “for every day we miss the target by we lose X amount of money, business reputation”, etc.

 Context is Everything – Tell the Story

 Of course, the date is really just one aspect of the wider rationale for developing the software in the first place. This wider context is often poorly communicated. It’s not uncommon for a business and the development team to spend many hours in a conversation around a single Epic or even a fairly complex User Story. Yet, when it comes to the vision, goals, benefits and constraints (time included) of the whole initiative or release, how much time is typically spent on this? In some cases, the answer is zero hours. Why is this? (We look at potential reasons later)
This is not only a shame and disrespectful but also a missed opportunity. Telling the story of how the target date was arrived at is highly motivational and helps pull teams together, especially newly formed teams. Any development effort is a journey and the ‘back-story’ sets the scene and propels everyone forward.

 The role of Release Planning

A key pillar of Agile is the approach of iterative and incremental development. We speak of iterations. In Scrum, we speak of Sprints and we do Sprint Planning at the outset of each Sprint. We have a Product Backlog which is essentially a list of the capabilities of the software and the outcomes it is intended to manifest in the World for users. All well and good but many teams also have the concept of the Release with an associated subset of the Product Backlog and usually a target date.
The release needs to be underpinned by a vision and goals which are bounded by cost and time. This is not ‘waterfall’. This is simply saying that the next version of the product aims to achieve X and this is how much time and money we believe this is worth. Note that the vision, goals and constraints are (or should be) allowed to evolve based on feedback. For some types of product, each act of releasing has its own associated cost in terms of money and time. Mobile apps, for example, require, release-level (regression) testing,  device and field testing, performance testing and in the case of iOS apps, Apple’s review process. There is also the associated cost of updating the app store, associated websites and marketing activities. It’s not practical to go through this entire cycle for each user story which is part of the reason a releases process provides value and minimises waste.
So in this context it would appear to be common sense to communicate the background, vision, goals etc to the development team and the details surrounding the target date. Common sense but not necessarily common practice.

 Need to Know Basis

I believe that some business or product people think that the development team really does not need to know such details. The reasoning goes: it’s our job to define and agree the vision, objectives and constraints; according to Scrum (say), all we need to provide is a backlog of user stories and give ‘them’ a deadline! Easy.
The problem with this approach is the development team is actually being disempowered from performing to their full potential.  First of all, user stories are an intermediary step. The vision, goals and constraints are the fundamental drivers of the development effort. This needs to frame the entire process including the conversations around user stories and ultimately their definition and agreement. User stories are a step on the way to a solution. The solution ultimately needs to be a great solution as framed by the vision, goals and constraints. Again, the vision, goals and constraints are (or should be) allowed to evolve based on feedback. But it should exist and be understood by everyone involved.

 Fear of Looking Stupid

Another reason for lack of information sharing and communication may be the fear of looking stupid. The fear of being asked ‘awkward’ questions. It’s OK to not have all of the answers such as how may users will use the feature(s), precisely how much money this release will make the company, what will happen, exactly, if the release date is missed by say a day, a week, etc?  Transparency and trust are not to be undervalued. People know when information is being withheld, either intentionally or not. Knowledge abhors a vacuum and people will fill in the gaps with their own assumptions. This road really can lead to eroding the relationship with a development team within a business and across departmental and organisational boundaries.


The word deadline is often accompanied by a distinct lack of communication and explanation of why the date is significant. Deadlines can get ‘handed down’ to the people that are supposed to deliver.
Instead, speak of the target date and qualify that date by communicating the vision, goals and constraints. Furthermore, make sure everyone involved understands and actively encourage feedback and questions. Have the courage to accept that you may not be able to answer every question that arises. That’s OK. Transparency is worth far more.
If you are on the receiving end of a ‘deadline’ make sure that the vision, goals and constraints are understood. Have the courage to ask questions even if everyone remains quiet. You will be doing everyone a service, not just yourself.

 Further Reading

Mike Cohn – Agile Estimating and Planning
Steve McConnell – Software Estimation: Demystifying the Black Art

Leave a Reply

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