There are some useful parallels between the delays in the easing of England’s national lockdown and the challenges Agile teams members see with delivery roadmaps.
Without wishing to comment on the specifics of lockdown easing, it highlights what can make a difference in a successful agile implementation, and underlines the importance of managing expectations. In short, it shows that a commitment to transparency is a critical part of Agile, rather than an optional extra.
“Data, not dates”
The government’s messaging previously used the phrase “Data, not Dates.” That was back in February when the roadmap was first laid out and presented to the public. This is a similar philosophy to the one we like to use during a delivery. It links to a key part of the Agile Manifesto which emphasises the importance of “responding to change over following a plan.”
However, although the logic of such a philosophy is sound, it comes with a very real challenge; one we like to call the immutability of dates. This refers to the way a date in a roadmap will almost always be taken as gospel, even if you put a caveat against it.
Why ‘the immutability of dates’ poses a challenge for Agile delivery teams
If you mention a date, that’s often all that people hear. Regardless of the caveats, the qualifications, the reasoning, and the doubts you may have, the date takes on a life of its own. It plants itself inside the imagination of just about every stakeholder.
In the case of initial communications surrounding lockdown easing, caveats were explained. The difficulties began once the message (and date) settled in the public’s consciousness.
This is something that we often see in an Agile setting, when Product Owners try to articulate a caveat date to the wider organisation. The majority of stakeholders will hear the date and not the caveat. This then encourages people to take the date to be gospel, even if it was supposed to be conditional and subject - even likely - to change.
What might an alternative message look like?
Here’s an alternative message that could have been used:
On the 14th June we will look at the 4 key data points and assess whether it is safe to unlock in the coming weeks. The measures are as follows: (list the 4 measures and how people can see them for themselves).
The change is obvious. The date has become a date for ‘observation’ rather than ‘action’. It allows the team to easily assess the data once the noise of the previous milestone has diminished. This means the team can be confident that the data is now measuring the new state as a result of the previous easing of restrictions. Mature product teams will typically look at data after a release to measure against success metrics and minimise any noise that the initial release may have caused.
In Agile, emphasise data not dates
In client engagements, we’re often looking for ways to stop talking about dates - instead allowing data to give us clarity on when to expect delivery.
We measure the speed of delivery, as well as understanding what success will look like, so that leadership is clear about success. This allows everyone to focus on what really matters, whilst leaving some flexibility for unexpected issues and changes.
Examples of this include:
- OKRs / KPIs - accurately measuring key success metrics, which will drive the decisions and ultimately, release
- Outcomes, not outputs - framing the result of the delivery (not just the thing being delivered)
- Flowchart diagrams - showing work sequence and identifying critical paths to delivery
- Burnup charts - showing how quickly delivery is progressing, and highlighting anything that affects progress
- RAID chart - listing obstacles encountered, and allowing escalation of anything that could jeopardise delivery
- Scatter Plot cycle time chart - working out outliers from the normal cycle time, and investigating what may be slowing down flow of work