The standards, the operating models and the flow work behind running several teams towards one outcome.
A programme is not a large project, and the difference shows up in funding, benefits and the dependencies between teams rather than in the size of the plan. This list is for programme, portfolio and delivery leads accountable for an outcome no single team can produce. It starts with the two standards that define the discipline, moves through the operating models organisations actually adopt when several teams share a product, and finishes with the governance and flow material that keeps a programme honest about whether the benefits arrived.
The official guide behind the MSP qualification, built on principles, themes and a flow that runs from identification through to closure. Read it for the benefits management chapters, which cover the part of the discipline most often skipped and most often missed.
Martinelli and Waddell treat programme management as the discipline connecting strategy to cross functional execution, with chapters on programme organisation, financial management and the programme manager role itself. The closest thing here to a textbook for the job as it is actually staffed.
Kersten replaces project funding with long lived value streams, and the Flow Framework gives you flow items and flow metrics a finance function will accept. This is the argument to make when your programme has to be re justified every budget round.
Most programme risk is dependency risk, and dependency risk is usually a team boundary problem in disguise. The four team types and three interaction modes let you propose a different structure instead of adding another coordination meeting.
Martin and Osterling cover work as it crosses functions, with the current state map, the future state map and the transformation plan between them. The technique that shows a steering group where the waiting actually happens.
The condensed account of the Scaled Agile Framework, covering programme increment planning, the release train and the roles around it. Worth knowing properly whether or not you adopt it, because so many of the organisations you work with already run it.
Larman and Vodde on many teams working from one product backlog with one Product Owner, and on the structure you remove to make that possible. A useful counterweight when the default answer to scale is more coordination roles.
Nexus adds a single integration team and a cross team refinement practice, which keeps the framework small while making dependencies visible early. The lightest of the scaling options here and a sensible first step before anything heavier.
The Disciplined Agile toolkit presented as decision points with options and tradeoffs rather than one prescribed method. Useful when teams in your programme genuinely need to work differently and you still owe a sponsor a consistent view.
Humble, Molesky and O'Reilly on governance, financial management and experimentation at organisational scale, including how to fund work without committing to fixed scope. The budgeting chapters are the ones a programme manager returns to.