The programme plan has been around for a long time in business. As software development evolved into the waterfall delivery, the programme plan became the interface between the technical and non-technical teams – narrated by the programme / project managers.

In the world of agile, which aims to reflect business reality significantly better, programme plans shouldn’t really exist. Agile acknowledges that there are too many problems to solve, and tries to get everyone progressing the ones that are solvable – combined with failing fast for those that turn out not to be. The is isn’t very compatible with the multi-year / hard deliverables that are core to normal programme plans.

Agile delivery works even better when a business adopts a product based mentality – a recognition that your business doesn’t stand still but evolves all the time. This means that the transition between “end of project” and “business as usual (BAU)” is now even more blurred. The team that builds something, runs it and evolves it (“DevOps” 🙂). 

What replaces the programme plan as the interface? For me it’s the roadmap – a lightweight way for tech and non-tech teams to interact. Roadmaps also naturally tend towards helping create epics of work. Epics should always be simple to summarise as deliverable features, which, in turn, helps show how your roadmap is progressing.

As an architect, own the narrative, not just the design.

This combination enables / empowers senior stakeholders to:

• Re-prioritise without needing to understand all the nuances and impacts
• Help trim work to fit timescales 

Other groups that benefit from this approach:

• Squads can get a quick feel of where they are going in the next few months, and can push back where they feel it is wrong
• Product owners should use a roadmap as a “currency” with all parties to negotiate what is done next, or what is paused based on the latest understanding
• Architects can have an opportunity to input, and (in an ideal world) should be allowed to trade items for tech debt or strategic components that will allow faster future delivery

A good relationship between the roadmap and epics should also show up where too many dependencies are building up, making a longer term goal unachievable or undesirable. If that is spotted, senior stakeholders need to decide whether to get behind it and commission a larger package of work, or agree to forgo the function and change strategic direction.