How our project managers learn from each project

At Brew Digital, finishing a project isn't the end of the story; it's an opportunity to learn. The project retrospective, or 'retro', is a structured process where our teams reflect on what happened—the wins, the challenges, and the surprises. This isn't just a debrief; it's a vital part of our commitment to continuous improvement. Here’s a look at our approach to making every retro count.

Phase 1: Planning for a productive retro

Before getting started, we consider the context of the project to choose the right format for the retrospective.

• For scrum teams delivering in sprints, a retro is critical for identifying actionable improvements to the team's ways of working. Running these in a consistent format helps the team become familiar with the process and contribute effectively.

• After a significant project milestone, a retrospective is a valuable moment to draw out feedback and feelings about events that have taken place over a longer period.

We always frame the retrospective by defining the specific period it covers. For longer projects, we might run short framing exercises, asking people to map their emotions or their view of how well the work met the defined scope over time. This helps focus the discussion.

Phase 2: Running an effective session

To ensure a retro is a good use of everyone’s time, we focus on maintaining momentum and creating a balanced discussion.

Manage the allotted time We keep each section of the meeting time-boxed to stay on track. A typical structure includes:

• Introduction: A brief recap of the retrospective model being used.

• Framing: A reminder of the project phase being discussed.

• Collect feedback: Dedicated time for participants to add their thoughts.

• Review feedback: Time for everyone to read the collected comments.

• Discuss feedback: The main part of the session, where feedback is clarified and explored.

• Actions and close: Defining the next steps.

For some projects, it can be beneficial to invite an external chair who isn't too close to the project to help guide the team through the process impartially.

Look for bright spots, not just negatives It’s human nature to focus on negative experiences, but a great retro gives equal weight to what went well. Success is not a given, nor is it easy to recreate. If the team did something well, we identify and reinforce it so it has a greater chance of happening again. It’s also a key moment to celebrate successes that may not have been acknowledged yet.

Phase 3: Closing with clear actions

A retrospective is only useful if it leads to action. As part of closing the session, we capture clear next steps.

For example, if the team identified that reviewing pull requests was inefficient, an action might be for all team members to dedicate time to it each day. If a more significant problem was raised, like a need for stable test environments, we capture the immediate first step—such as scheduling a follow-up meeting with the relevant people to discuss it.

There can be a tendency to make "solve the whole issue" a single action, but this is a trap. Large, vague actions are often forgotten. We keep initial actions small and achievable, which gives the wider issue a greater chance of gaining momentum. We also assign owners and deadlines to maintain accountability.

Phase 4: The follow-up that drives change

Our responsibility carries on after the retro has finished. For the process to be truly successful, it’s vital to check in with the team to ensure that actions have been completed and that positive changes have been implemented. This might happen naturally for a team that works together regularly, but we always make time to follow up.

Making change happen is hard, but it’s what separates good projects from great ones. By treating retrospectives as a core part of our process, we ensure that the momentum from every project helps us—and our clients—move towards even greater success.