In agile programmes people prefer to talk about roadmaps rather than plans. This post is about the reasons behind this and the benefits of using a roadmap rather than a gantt chart to manage pure agile, or mixed methodology programmes.

Peoples' Front of Judea

Plans can be a cultural battleground between the traditionalist and agilistas. They needn’t be. Both camps need an artefact to guide them towards a longed for future and a roadmap provides something for everyone to cling to.

Managers and stakeholders often ask when something will be ‘done’; What are the milestones? Are we on track? What are the dependencies? What is the critical path? These are natural questions to want to ask. Waterfall and agile methodologies answer them in different ways with very different artefacts.

The Waterfall-istas reach for MS Project or equivalent gantt tool to make sense of the world. The agilistas use a backlog, prioritisation, continuous delivery and feedback loops to make sense of theirs.

Agilistas will say “we love planning… just not plans”. They hate gantt charts because they offer only false certainty and often do not sufficiently accommodate change. In the wrong hands they will stifle learning and continuous improvement, as teams switch the focus from delivering outcomes to keeping to ‘the plan’.

Continuous, adaptive planning is an awesome part of agile. Good, informed prioritisation, that factors in the cost of delay, risk, business value and dependencies is perfect for wholly agile teams, but it’s not for everyone.

Not everything is software or agile

My particular experience is in the delivery of digital public services for government. Mostly these programmes of work are not just about digital. They may include a change to an organisation’s operating model, training, buildings, telephony… Often the (least lean) bits of service delivery that many agile teams sometimes consider as “the business-y bit” – bywords for “waterfall” and “dealing with the non-converted”.

Traditionalists charged with managing these types of programmes see no alternative but to add agile sprints to the large MS project plan. In the past, for example, I’ve been asked to provide themes by way of labels for six months of two week sprints and this is not good — for anyone.

They get frustrated with agile's lack of plan and I understand their concerns. I’ve seen agile planning ceremonies used as a smoke screen for short-term planning only. That’s being über agile, right? Yes it is, but sticking with that mindset can alienate stakeholders and co-deliverers who demand a better picture of the future.

A roadmap is the droid you are looking for...

A roadmap bridges the gap between worlds.

• Something for everyone - it is an artefact that traditionalists recognise enough as a 'plan' and agilists recognise as 'not a gantt chart'.

• Focuses on outcomes not deliverables -it promotes the right sort of strategic conversations within teams and with stakeholders.

• Provides stability but evolves - it sets a clear, stable sense of direction but I find teams and stakeholders feel more comfortable discussing change resulting from iterative delivery and learning.

• Promotes buy-in -good people will feel out of control and disengaged when deliverables are dictated up-front and/or from above. Self organising, multi-disciplinary teams love to own and be empowered to meet outcomes in creative ways.

• More coherent - it allows you to knit all aspects of your programme together (e.g. software, infrastructure, ops, policy, security, estates, human resources, procurement) without freaking out any horses or doing up front requirements specs or giving false certainty.

• Better performance metrics -outcome based planning allows programmes to more easily measure the evolution of a service through early stage delivery into full blown operation and iteration. Some metrics will be a constant throughout, others will only have relevance in later stages. This approach keeps you iterative and chasing incremental improvement. It also makes for joyful dashboards.

• Better governance -roadmaps work well with time-boxed or target-based governance gates -- you choose.

There's something for everyone to like about a roadmap.

In my next post I'll talk how to put one together and how language can be used to find common ground.