Blog

Lesson Learned events provide a wealth of valuable information that can be applied from one project to the next. For example, on a past project our team assisted a client build and launch a new initiative. Upon completion of the project we attended the project post-mortem (also called retrospective, retro or after action review). We reviewed the project stages, explored processes that were used, and examined team dynamics. There was a lively conversation about communication and process breakdowns, and an encouraging discussion highlighting wins along the way. 

We developed a comprehensive list of recommendations with the client team which were reviewed by the organization’s PMO and adopted into the day-to-day management of other projects. For our TGG team that Lessons Learned meeting was yet another example of the value and importance of retrospectives.  

The Impact of the Retrospective

The result of asking this question in an agile setting is a regular review of the team’s activity, called a retrospective.

The retrospective is an event in agile frameworks, a chance to “look back” while still in the middle of the work. It is a chance to review not only the team’s performance, but the systems, processes, and working culture that lead to performance. The goal is continuous improvement, to review and adjust the way that the team works in order to constantly improve delivery of day-to-day work and digital transformation efforts. 

The main theme of the retrospective is accountability. The team looks back at the past few weeks in order to hold themselves accountable to promises that were made. If the team falls short on promises, they make adjustments. If the team has been successful, they try to understand the reasons for that success with the goal of repeating it in the future.

Regardless of the format, a retro should be a judgment-free space, where the team can openly discuss failure and successes in the spirit of learning. A retrospective is one of the most important ceremonies in an Agile system. There are plenty of books and blogs on different facilitation approaches to retrospectives, each depends on the team and its culture.  

Our take: simpler is often better and can yield a richer conversation, which is why we prefer to focus on two roles and four questions. We’ll explain:

• Role: Facilitator – This is the only defined role in a retrospective. This is usually someone on the team, possibly a scrum master. The first goal is to create an atmosphere of trust, where the whole team feels comfortable engaging. Pay attention to setting, personalities, and culture. The facilitator is always thinking ahead to the retrospective; for example, when the team encounters a roadblock this person records the experience and suggests to the team, “This would be a good topic for our retrospective.” The facilitator is accountable for the success of the retrospective.
  • Tip:  Facilitators, make sure you know your team. Temper the talkers, and engage the less vocal, introspective members by gathering written feedback in advance of the meeting. Work with the personalities you have on the team, ensuring that everyone has the chance to engage. 

• Role: Participants – This is the team closest to the work. In the interest of maintaining an atmosphere of open and honest communication to glean the most meaningful feedback, be thoughtful as to who, specifically, to include in the conversation. It’s best to limit participants to people who know the work and can make changes that would benefit the team. 
  • Tip: Tell the participants, and make them aware, that their candid feedback is the most essential ingredient for an effective retrospective. 

• Question: What did we promise to do vs. what did we actually accomplish? This question provides a baseline for the conversation and aligns the participants around a shared understanding of the exercise’s objective. This question promotes accountability by considering the promises made vs. the promises that were kept. If you’re looking for metrics, some helpful ones include burndown charts or say:do ratios. 
  • Tip: Don’t spend too much time on this question; it’s simply intended to be a foundation for the following questions. 

• Question: What worked well? – Beyond providing a morale boost by celebrating success, this question serves to identify strengths with the intention of converting strengths into habits. Turning positive results into rules for operation is the “machine learning” mechanism for the team. Silence here is an indicator of siloed work, a lack of confidence or cohesion, or even burnout. 
  • Tip: If participants are struggling to think of things to contribute, bring back recent kudos or recognitions as a primer for conversation. 

• Question: What didn’t work well? – This is your chance to learn from mistakes or identify ways to improve. This question promotes accountability for shortcomings, with an eye toward actionable improvement. The keyword is actionable–this isn’t a chance to complain, it’s a chance to change. Keep things constructive: rather than searching for blame, search for improvements. 
  • Tip: It would be rare for a team to be silent here. If your team is struggling to name areas for improvement, be ready with a couple coaching questions to help the team unpack the potential reasons why. You might discover they need more challenging work or perhaps there could be conflict within the team. Silence can mean there is still a perspective waiting to be heard and understood. It’s rare for a team to be silent here. 

• Question: How will we adapt? – Every strength and weakness identified in the previous questions should have an action assigned to it in this question. This is a chance for your team to hold itself accountable by making an agreement. This question only has power if the team can keep its word. In the next retrospective, circle back to the agreements that were made in this question. 
  • Tip: Write these answers down, and make them visible. Once the team agrees on how to adapt, post those agreements on a board, in a chat, or anywhere else people will be sure to see them. 

The beauty of the retrospective is its simplicity. It’s not limited to software development, or even IT. Any team can adopt this ceremony on an iterative basis, adapting it to their needs and situation. The power of the retrospective is in its effects: know your goals, and iteratively improve the way you pursue them. That’s pragmatic; that’s agile.

—

Our goal at The Gunter Group is to help our clients maximize their potential through thoughtful action and tangible results. Click below to connect and discover how the TGG team can help you achieve your strategic objectives.