Program Retrospective

What is a Program Retrospective?

A Program Retrospective, sometimes referred to as a “retrospective of retrospectives,” is a meeting that focuses on continuous improvement, as Sprint Retrospectives do. Below is a summary of some of the primary ways that a Program Retrospective differs from a Sprint Retrospective:

  • Representatives from multiple teams attend (rather than all the members of a single team)
  • People who are not on an Agile team attend (e.g., Managers and other stakeholders)
  • The timeframe is variable, for instance, it could cover multiple Sprints, rather than a single Sprint

What are the Benefits?

Benefits of conducting Program Retrospectives include:

  • Providing a cross-functional/cross-team perspective on what’s going on
  • Providing an opportunity for individual team members to surface issues or pain points that may be broad in their impact, with people who may in a position to mitigate or completely address those issues or pain points
  • Serving as raw material for organizational improvement

When?

The cadence for when to have a Program Retrospective varies. For example, it might be appropriate to have a Program Retrospective under any of the following circumstances:

  • At the end of a Release
  • After introducing a significant change in terms of process or products
  • When decision-makers gather to assess a particular change effort or other significant initiative

Who Attends?

The following people often attend Program Retrospectives:

  • Representatives from individual teams
  • Product Managers/Program Managers
  • Representatives from one or more other levels of management
  • Stakeholder representatives (often representing business functions such as IT, Information Security, and Release Management, to name a few)

Inputs

  • The primary input is the sum total of the events and interactions that took place during the Program/Release/initiative
  • Other inputs might include topics surfaced at a previous Program Retrospective, or a similar gathering 

Outputs

  • Clarity about potential changes to the group’s way of working, stated as one or more actionable steps that the group agrees to, which can help them work together as effectively as possible.
    • These outputs are often captured on an Improvement Backlog or Continuous Improvement Board, so that the group does not lose sight of them

Preparing for Success

A Program Retrospective is more likely to be a productive use of time when the facilitator has prepared in advance for what activities and what types of conversations are most likely to help the group, based on its particular context.

Note: For an example of a detailed retrospective agenda that was designed for a particular context, see Complete Agenda for a Program Retrospective. 

Execution

With the help of the facilitator, the group reflects on the period of time under discussion.

  • It is important to never lose sight of the positive. A good way to help ensure that positive observations are included can be as simple as asking something like “who would like to thank another member of the group for something they helped with during the Program/Release/initiative?”
  • Given the cross-team nature of the conversation, it’s common to spend a significant amount of time discussing dependencies, how those dependencies were manifested, and possible steps to take to remove the dependencies altogether, or at the very least, mitigate the impact of the dependencies
  • The actionable steps that the group agrees to are made available in a visible place, which helps ensure that the group works together to address those areas of potential improvement. As noted previously, it’s common to capture these sorts of things in:
    • An Improvement Backlog; and/or
    • A Continuous Improvement Board

 

Note: In contrast to what is discussed during a Sprint Retrospective, which is considered confidential (i.e., often not shared outside the team, other than any action steps they identify to help them improve), for Program Retrospectives, it’s particularly important to share a summary of everything that was discussed, unless the group decides that one or more topics under discussion are not to be shared. By sharing the outcomes, the attendees model transparency, and ensure there is cross-team alignment, with a particular focus on addressing issues that impact multiple teams.

 

X