Run a retro

The retrospective provides time for the team to regroup and reflect on the experience to date. This experience, especially over time, allows teams to improve not only the way they navigate projects but also the collaborative workflows, communication styles, task handoffs, and many other minutiae of working together. The retrospective often adapts generic rituals to the type of engagement and maturity of the team—improving that team’s velocity and trust.

The full working team attends the retrospective, which takes place after the sprint is over. Stakeholders are typically not invited because this session is a safe environment for colleagues to be transparent, air what they found challenging, and provide feedback.

A retrospective is our internal feedback loop for the delivery mechanism. Small, incremental improvements compound over the life cycle of the project and make for winning teams.

The session takes from one and a half to two hours. The project lead or the product manager owns the retrospective and tracks action items from sprint to sprint. Here’s an example of a session structure used by one of our teams:

• Review retro resolutions (actions noted, taken, and process improvements) from the previous sprint.
• Set up a whiteboard to capture three buckets of feedback—“continue doing,” “improve or stop,” and “start doing.”
• Have team members document feedback on sticky notes.
• Collect feedback notes from the team.
• Vote on top priority items to include as actions for the next sprint.
• Discuss what went poorly in the current sprint.
• Capture and document in Confluence with assigned action items.

Some teams introduce games (e.g., a box for anonymous ideas, which made the environment safer for feedback and conflict resolution) into the retro to improve the solicitation of ideas.

Take note of the team’s mood. Everyone on the team should feel like they are being heard, their contributions valued.

A few ideas collected from the team to improve retrospectives:

• Get outside perspective. Rotate a senior employee into your own retrospective and have them retro the retro.
• Use conflict as a benefit. When conflicts arise (which they often do), use the discussion to achieve a result. Remind all team members that conflict is simply a necessary device by which all members of the group are trying to arrive at a better state—a resolution.
• Value alignment. Ask the team if the work is evidence of Devbridge’s values. For example, implementing fixes on a security flaw for a client application may seem like a stretch in terms of “making great things,” but a contribution does not have to be glorious to have great value. Reflecting on the purpose is just as important as the work itself.
• Learn from failure. Failure is a natural state in building software. Each failure is an opportunity to learn from the mistake so as not to repeat it. In retros (and anytime failures occur), discuss issues openly. For example, if refinement fails because the team isn’t prepared, or a story fails and takes more time to produce . . . talk about it. Remember, we value taking ownership and being transparent, say something. Repeating a failure shows incompetence and needs to be addressed by the whole team.