Part 4.4 – How can tech and non-tech work together?

A picture showing the English language on one side and Klingon on the other.
This entry is part 5 of 5 in the series Part 4 – Klingon or English?

The programme plan has been around for a long time in business. As software development evolved into the waterfall software development, 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. This 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 light weight way for tech and non-tech teams to interact. Roadmaps also naturally tend towards helping creating epics of work. Epics should always be simple to summarise as deliverable features, which, in turn, helps show how your roadmap is progressing.

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 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 forego the function and change strategic direction.

Actions from this section

🗺️

Constrain with roadmaps

Help you communicate about the “now” problems, ignoring future problems.

Anchor with epics

Enable conversations and designs to focus on a clear aspect of the problem.

Part 4.3 – Buzzword bingo