The Dead Line

Deadlines strike fear into the hearts of programmers. I am on a mission to reduce unhealthy stress in the workplace so I am going to look into what “deadlines" mean, if they are entirely evil or can be incorporated into our working lives successfully.
"The term deadline originated from prison camps during war, and referred to a physical line or boundary. Guards would shoot any prisoner who crossed the deadline."
Pretty scary stuff! Unfortunately it can still feel like you are going to be shot when an imminent deadline is approaching.
"The term was later adapted in its use to time lines, perhaps to show the seriousness of an end date in a timeline by referring to it as a "deadline."
The anxiety and stress associated with a deadline arise in response to the ‘seriousness’ a deadline should carry. Not hitting deadlines, a few in a row particularly, does make me lose the feeling of job security and motivation to be subjected to Yet Another Deadline. This twitchy feeling makes me want to change something, anything, to avoid this scenario again.

"Agile" has an answer to this. Even though there is a debate around the use of deadlines I prefer the faction that views them more as ‘release dates’. The practices around roadmapping encourage sequencing and prioritisation.

I would like to highlight that deadlines do not go away just because you are being agile. There are reasons we put limits on work. To me this comes down to Parkinson’s law:
"work expands so as to fill the time available for its completion."
If there was not a point in time that marked the finality of a project, then that project ‘in theory’ could last forever. As a programmer I’m sure you could think of many activities that you could spend years doing even on simple projects to get the code, architecture, performance, maintainability just right!

External expectations are the other side of the coin. I don’t have much experience in this area, but from being a freelancer in the past I am aware that this is really hard to manage. Hats off to people that make this their day job!

The project exists to be an investment. Not an expense. Setting a deadline tries to maximise profit, and not turn a project into a sinkhole of cash and resources. This is the time to bring in how being agile is aligned with this goal.

Using agile practices we would sequence and prioritize stories / tickets / backlog items to:
  • Ensure that the most important features are completed first
  • Ensure that the completed features are usable, in the sense that they don't depend on features that haven't yet been completed
  • Ensure that development continues at a sustainable pace

That last point is particularly important to my personal values of only creating healthy stress for the mind and body. Overall, the desired outcome is to only leave the least important peices not delivered. Maximizing on the value delivered for the least effort expended.

There is a difference here. A deadline requires all tasks to be completed, whereas being agile does not. This is not a disconnect. I hate reading that ‘deadlines are just reality, live with it’ for I believe instead that sequencing and prioritization are a realization of reality. I would back up this belief with a small excerpt of my favorite philosophy book:
“A finite player is trained not only to anticipate every future possibility, but to control the future, to prevent it from altering the past. This is the finite player in the mode of seriousness with its dread of unpredictable consequences."
This is how I see a deadline. Someone trying to predict the future. Contrary to this I see being agile as being the infinite player:
“Infinite players, on the otherhand, continue their play in the expectation of being surprised. […] Surprise causes finite play to end; It is the reason for infinite play to continue."
Grounding this back to deadlines, they are rigid points in time that mark the end of a period of effort exerted in a specific direction to deliver on a prediction. This is the point of helplessness for development teams, for we all experience surprise every day regarding our work, be it a bug or mis-understanding of requirements, a performance bottleneck or a piece of UX that doesn’t sit quite right. All of these surprises work against us when a deadline is set. These surprises create unplanned work that was not taken into the account.

Fighting an uphill battle is mentally and physically exhausting. There are techniques of driving change that you can use to turn your deadline into a calculated date that marks an ‘optimised’ point in time to get value delivered.

When talking to client engagements they need proof and re-assurances. I was taught and re-discovered the ‘release burndown' after the current project had been using JIRA for a while:
This ‘sprints remaining’ number flitters around too much to be communicated to a client as a deadline. It really represents a prediction of continued trends. Another view of this data is the real release burndown chart which includes pessimistic and optimistic release dates:
Even though the burndown uses historical performance to determine a date with supporting evidence, this still doesn’t completely fit in with taking surprises on board. This is still a prediction even though a computed generated it.

"Change is the only constant in life."

Advice from experienced project managers, and my original mentor, say to add a 50% buffer to your dates OR only guarantee 50% of the backlog that the prediction shows can be achieved. The people who have preached this have been unshakable for years on this point and I can see why.

Using internal factors rather than external factors and communicating expectations up as opposed to down removes some of the bad stresses from the development team.

Taking this as a tool to fighting bad stress: if given a two week deadline I would only give a guarantee to hit what my average historical velocity trend would complete for a single week. Who knows what is going to happen over the next two weeks? Any number of things could happen, QA comes back with unanticipated side effects, the test suite breaks, the requirements were not completely understood, the list is infinite…

Anything additionally delivered is win win, and we hold no negative feelings towards items not delivered that were not guaranteed.

Pulling this full circle and back to deadlines. Yes they can be incorporated successfully into a project, but they need to be based on supporting evidence, use prioritization and a 50% buffer to account for unpredictability.

comments powered by Disqus

Contact

joe@joejames.io. You wont find me on social networks (because I'm not there).