Groundhog-day
Groundhog Day, the movie with Bill Murray from Columbia Pictures, 1993

Deadlines are dead!

SHARE

Share on linkedin
Share on twitter
Milestones have the unfortunate tendency to be written in stone. If you want to be agile, running a project full of hard dates may be counterproductive.

As I am working from home since the COVID-19 crisis, I have the same feeling as the character played by Bill Murray in Groundhog Day: I wake up each morning with the feeling of having the same day again. Does this sound familiar?

Since I am running projects in an agile way, I have some regular requests for providing milestone planning, something that looks like a Gantt chart. Does it sound familiar too? As this is quite recurrent, it reminds me of the Groundhog Day movie…

A Gantt chart (old) sample

Don’t ask me for a (MS Project) plan; actually I don’t have one!

I am not saying that hard dates are not existing, but I am saying that they are and must stay rare. A good example of a hard date is the birthdate of my wife. Hard dates are hard because we’ve made a point of remembering them. But not each and every date should have to be set in stone. Usually, is there a big difference if a software component is delivered on Tuesday, December, 2nd or Wednesday, December, 3rd? Is someone really dying when the deadline is reached?

In an agile project using Scrum, a squad is committing to deliver a work item in a given sprint that starts at a date and ends at another date. This is more realistic, less stressful, and gives more latitude to the team to organize itself.

I am not saying that milestones should all disappear but they should be reserved for a situation when the date itself counts a lot and there is an important impact if the date is missed.

Let me cite some examples:

  • A regulatory change that starts at a given date
  • A marketing campaign using TV or radio advertising that is too difficult to move
  • Something that is linked to investor communication such as the announcement of quarterly results
  • The birthdate of my wife

In the Scaled Agile Framework (SAFe), those hard dates are named fixed-date milestones [1].

For all the rest, the Product Owner and all other stakeholders should talk about a sprint, not a date. The functionality XYZ will be delivered in Sprint 12. This could be organized in Program Increments (PI) as SAFe is suggesting (I am using PI of 4 sprints) and for multiple squads, everything can be nicely arranged in an Agile Release Train (ART).

This means that everybody (up to the Senior Management) should understand the concept of sprints, PIs, and ART. This is probably a challenge but it is key to make sure that there is no disconnect from the people within the squad(s) and the decision-makers at the top of the hierarchy.

These are the other problems you could face if you keep working with too many milestones while running your project in an agile way:

  1. It will be harder to pivot (eg. change the priorities of certain features) if you have announced something on a hard date
  2. With dates everywhere, the dependencies are hard to manage, unless you fall into a waterfall plan. I suggest you use Agile Release Trains to manage interdependencies between squads instead of dates.
  3. You may release your MVP (or additional features) too late because everybody concentrates on a given date rather than what could be the bare minimum to be delivered (see An MVP must be an ugly baby).

With agile methods being massively used everywhere, the usage of MS Project and Gant charts are already dropping dramatically. But, we need now to make sure that everyone is speaking the same agile language. We should encourage everyone to talk about sprints, PI, and ART instead of dates. We must forget about milestones or deadlines unless rare cases where fixed-date milestones are justified.

[1] Source:

Milestones, SAFe

Photo credits

Groundhog Day, Columbia Pictures, 1993

Leave a Reply