From Boring To Brilliant with Inspect and Adapt

Retrospectives are a critical event for any agile team or organization and at the same time are often either skipped, painful, or extremely boring. A Team retrospective should be a time to reflect and track demonstrable improvements, in other words, to INSPECT and ADAPT! When done well, retrospectives can be powerful, effective, and fun to be a part of. When done poorly, people want to skip them, multitask, or argue.

There are several ways to improve the retrospective process. In this post, we explore the most effective ways to approach conducting a Team Retrospective, sharing key best practices that can be applied at different stages of your learning journey. By following these foundational techniques, you can equip yourself with the skills and knowledge needed to implement successful team strategies. However, it's important to remember that Team Retrospective is just one component of the bigger picture. To gain a comprehensive understanding of your team's current process status, we recommend taking advantage of our free agile assessment for Team Agility.

Team Retrospective and The Learning Journey

At Lean Agile Intelligence, we believe that the Team Retrospective is a vital part of the team's ability to inspect and adapt ways of working to increase quality and effectiveness. We have organized the learning journey into four distinct stages - Developing, Emerging, Adapting, and Optimizing - and will cover each of these stages in-depth, providing you with practical advice and techniques to enhance your skills in this area.

Source - Agile LEGO - Toyota Kata an alternative to Retrospectives

Developing

Teams “developing” an understanding of the value of Team Retrospective and adopting the foundational techniques should focus on the following improvements

• The What: A Retrospective occurs on cadence and is attended by all team members, including the Product Owner

  • The How: It’s critically important to inspect and adapt on your own process and performance as a team and include everyone on the scrum team. One of the few mandates from the agile manifesto is the practice of retrospecting in order to improve. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” - The Agile Manifesto

• The What: The team inspects the last Iteration (i.e., Sprint) with regards to individuals, interactions, processes, tools, and their Definition of Done

  • The How: It’s a good practice to regularly revisit team working agreements including the definition of done. For an in-depth look at the definition of done, see this post from our blog. In addition to working agreements, teams should reflect on their own team performance by using metrics and reviewing team success criteria. This could also include individual team member knowledge, motivation, team processes, and the tooling which the team uses.

• The What: The team team identifies what went well and what can be improved

  • The How: Woody Zuill has a saying “Turn up the good.” Before discussing problems, always start with positives and ask the team to reflect on the improvements they have been making and ideas for taking them to the next level.

  • The How: In order to create concrete improvement items, the team must focus on what to improve. This can be in the form of blockers, metrics, poor performance, quality issues, etc. There may also be qualitative issues like team synergy. An in-depth blog post can be found about that topic here.

Teams “emerging” beyond the foundational techniques of Team Retrospective and are embracing it as they become more proficient, should focus on the following improvements

• The What: The team discusses improvement experiment results identified in the previous Iteration (i.e., Sprint) Retrospective

  • The How: Finally, at the end of each sprint, the team reflects on the metrics for the hypothesis as well as an ongoing reflection of the improvement items. By reviewing experiment results, reflecting on outcomes, sharing learnings, discussing impacts, brainstorming next steps, facilitating open discussion, defining action items, and ensuring follow-up and accountability, Agile teams can effectively utilize the Retrospective as a valuable feedback loop for continuous improvement. Here are some specific strategies that the team can use to reflect:

    1. Reflect on Outcomes and Discuss Impacts: Teams can identify successes, challenges, and areas for further improvement based on the results of the experiments through reflection. This reflection can be guided by the Retrospective's "What Went Well" (WWW) and "Even Better If" (EBI) techniques, or other similar retrospective frameworks. Discussing the impacts of the improvement experiments on team performance, productivity, quality, or other relevant areas is also important.

    2. Share Learnings: Agile teams can share the learnings from the improvement experiments with the entire team. This can include discussing the insights gained from the experiments, identifying patterns or trends, and discussing the implications of the results on team processes, practices, and outcomes. Teams can use visualization techniques such as graphs, charts, or diagrams to help communicate the results effectively.

    3. Define Action Items, Follow-Up, and Accountability: Agile teams can define specific action items or tasks based on the discussion of improvement experiment results. These action items can include assigning responsibilities, setting deadlines, and establishing clear next steps for implementing changes or further experimentation. Agile teams should also establish a follow-up mechanism to ensure accountability and progress on the action items defined based on the improvement experiment results. This can include regular check-ins, tracking progress, and reviewing the status of the action items in subsequent Retrospectives or team meetings. Teams should hold themselves accountable for implementing the changes and improvements identified based on the experiment results.

• The What: The meeting results in new concrete improvement proposals that are added to the team backlog

  • The How: One of the most common anti-patterns of a retrospective is a lack of actionable improvement items that can be implemented immediately. Aino Corry has written an entire book on retrospective Anti-Patterns. You can find that book here. Try to make it a rule that the retrospective isn’t over until there is at least one improvement item in the team backlog to be implemented next sprint.

• The What: A team experiments with the most critical improvement proposals in the next Iteration (i.e., Sprint)

  • The How: By defining clear hypotheses, conducting small, controlled experiments, using Agile practices for experimentation, collecting data, involving the whole team, and iterating based on results, Agile teams can effectively experiment with critical improvement proposals in the next Iteration (Sprint) and continuously improve their processes and practices. Preparing Buzz Reports can also be helpful in bringing forward innovative ideas for the teams to apply to the improvement proposals. Here are some practical strategies to follow:

    1. Define Hypotheses: Agile teams can start by defining clear hypotheses for the improvement proposals they want to experiment with. Hypotheses should be specific, measurable, and achievable, and should clearly state the expected outcome or impact of the proposed improvement. For example, "If we reduce the number of meetings in the Sprint, then team productivity will increase by 20%."

    2. Create Small, Controlled Experiments: Agile teams can conduct small, controlled experiments in the next Iteration to test the proposed improvement. These experiments should be designed to minimize risks and impacts on ongoing work. For example, if the proposed improvement is related to changing the team's daily stand-up meeting format, the team can conduct a controlled experiment with a subset of team members or for a limited time period to assess the impact.

    3. Use Agile Practices for Experimentation: Agile teams can leverage existing Agile practices such as Scrum's Inspect and Adapt (I&A) or Kanban's Kaizen to facilitate experimentation with improvement proposals. These practices provide opportunities for teams to reflect on their work, identify areas for improvement, and experiment with changes in a structured and iterative manner. Teams can use techniques like Plan-Do-Study-Act (PDSA) cycles to guide their experimentation efforts.

    4. Collect Data and Measure Results: Agile teams should collect data and measure the results of their experiments to objectively assess the impact of the proposed improvement. This can include tracking relevant metrics before and after the experiment, gathering feedback from team members and stakeholders, and analyzing the qualitative and quantitative data to determine the effectiveness of the improvement proposal.

    5. Monitor and Learn: Agile teams should actively monitor the results of their experiments during the Iteration and continuously learn from the outcomes. This can include regular team reflections, retrospective discussions, and feedback loops to gather insights and identify opportunities for further improvement. Teams should use the results of their experiments to inform their decision-making and adjust their approach accordingly.

    6. Iterate and Refine: Agile teams should iterate and refine their experiments based on the results and feedback received. If an experiment yields positive results, the team can consider scaling it up or incorporating it as a standard practice. If an experiment does not yield the desired outcomes, the team can reflect on the learnings, refine the approach, and conduct further experiments to iteratively improve.

Adapting

Teams “adapting” the Team Retrospective practice to extract the full benefit, should focus on the following improvements

• The What: The team ensures improvement experiment results are measured

  • The How: In our blog post “Retros Don’t have to be painful (Part 1)” we discussed the practice of using an empirical approach to retrospectives. The first step is to come up with a hypothesis and a test for that hypothesis. The test is in the form of improvement proposals and metrics. For example “We have observed an increasing amount of escaped defects in our recent releases. We believe that by starting to practice pair programming and integrating our code daily we will see a reduction in escaped defects in the next release. We will track the amount of work that is done in pairs, code churn before release, integrations per day, and  escaped defects.”

• The What: The team identifies constraints out of their control and provides the information to leadership

  • The How: It’s important for teams to discuss ongoing issues they are facing but take note if the meeting turns into mostly complaining. Try creating two categories for problems titled “In our control” and “Out of our control” and place the appropriate ideas in the respective category. Starting with “In our control” create potential solutions for how to resolve these problems. For the “Out of our control” category, the scrum master and product owner can work with management and leadership in the organization to help address more system issues the team cannot fix themselves. One of the key responsibilities of a scrum master is to help create the right environment for self-organization to succeed.

Source - What is a spring retrospective and how do you run one?

Optimizing

Teams “optimizing” the knowledge sharing of the Team Retrospective practice learnings across the enterprise should focus on the following improvements

• The What: The team does not feel it has to wait until the end of the iteration (i.e., sprint) to run a Retrospective; if there is an issue that needs to be discussed, they stop, inspect, and adapt

  • The How: A sign of a mature team is one that doesn’t wait to address the critical issues at the upcoming retrospective. Borrowing from the concept of an Andon cord, teams can stop to address issues as they occur and continue working once the issue has been addressed.
    • “In manufacturing, the term andon (Japanese: アンドン or あんどん or 行灯) refers to a system which notifies managerial, maintenance, and other workers of a quality or processing problem. The alert can be activated manually by a worker using a pullcord or button or may be activated automatically by the production equipment itself. The system may include a means to pause production so the issue can be corrected. Some modern alert systems incorporate audio alarms, text, or other displays; stack lights are among the most commonly used. “Andon” is a Japanese loanword originally meaning paper lantern; Japanese manufacturers began its quality-control usage.” - Andon Wikipedia Page

*   *   *   *   *   *

"A sign of a mature team is one that doesn’t wait to address the critical issues at the upcoming retrospective."

*   *   *   *   *   *

Conclusion

As the team becomes more proficient in retrospectives, they should follow a framework of “Set the Stage, Gather Data, Generate Insights, Decide What to Do, and Closing” to ensure the full benefit of the retrospective process. They can also use data to gain insights and make informed decisions. It's essential to experiment with the critical improvement proposals and reflect on the results to decide if they should adopt them permanently. By incorporating these practices into their retrospective process, teams can develop a culture of continuous improvement and deliver more value to their customers. Overall, retrospectives can be enjoyable and productive events that help teams focus on their objectives and work together to achieve them. Also, check out our blog post on how to combat dysfunction in retro here. For a thorough assessment of your team's current process status, we offer a free agile assessment for Team Agility that you can take advantage of.