Agile Retrospective Doesn't Have To Be Painful (Part 1)

Agile Retrospective Doesn't Have To Be Painful (Part 1): An Empirical Approach

Agile Retrospective with An Empirical Approach

Agile retrospectives are a pivotal aspect of the agile process for any organization, but unfortunately, they are often overlooked or dismissed as dull, time-consuming, or unproductive.

However, these sessions offer a unique opportunity to analyze past successes and failures, track demonstrable improvements, and implement changes that can help organizations continuously improve and refine their processes. A well-executed retrospective can be a powerful and engaging experience that fosters collaboration and teamwork, while also providing valuable insights into how teams can better collaborate and tackle future challenges. On the other hand, poorly executed retrospectives can lead to disengagement, frustration, and a lack of buy-in from team members, who may view them as a waste of time.

In this first article of our series on how to improve retrospectives, we'll explore practical tips and techniques that can help you to create more engaging and productive retrospectives, and ultimately, drive better outcomes for your organization. You can read Part 2 of our series here.

We will first take a look at the empirical approach and how it can improve your retrospectives.

Use Empiricism to Drive Retrospectives

Empiricism:

“The theory that all knowledge comes only or primarily from sensory experience. Empiricism emphasizes the role of empirical evidence in the formation of ideas, rather than innate ideas or traditions. 

Empiricism in the philosophy of science emphasizes evidence, especially as discovered in experiments. It is a fundamental part of the scientific method that all hypotheses and theories must be tested against observations of the natural world rather than resting solely on a priori reasoning, intuition, or revelation.” - Wikipedia

Scrum is defined as an empirical process. If you’ve ever read the scrum guide or taken any scrum certification courses you’ll notice the inclusion of “inspect and adapt” points. In fact, the three pillars of scrum are “Transparency, Inspection, and Adaption.” This comes directly from empiricism. Retrospectives are one of the “Inspect and Adapt” events in Scrum. 

In the Agile Manifesto, regularly inspecting and adapting is not a suggestion but one of the guiding principles. As stated in principle number 12:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

 

agile-retrospective-doesnt-have-to-be-painful-part-1-an-empirical-approach-1.png

 

A simplified explanation of empiricism in practice:

  1. Hypothesize

  2. Test

  3. Review Data and Adjust

 

Getting Started

agile-retrospective-doesnt-have-to-be-painful-part-1-an-empirical-approach-3.png

STEP 1: IDENTIFY THE PROBLEM TO SOLVE OR FOCUS AREA

When reviewing the retrospective items, come to an agreement on what the actual problem is or focus areas should be. In-person, dedicate a wall or board to keep this visible to everyone on the team. If working remotely, you can use visual tools such as Mural which will allow your team to collaborate. You can also check out some more collaboration tools to use in remote work here.

For example, using a basic retro format of what went well and didn’t go well:

What went well: 

  • The first time the team met the sprint goal and also didn’t roll over work

Focus area

  • Sprint Goals

 

What didn’t go well: 

  • The last release had a lot of escaped defects

 Problem to solve

  • Poor Quality

 

agile-retrospective-doesnt-have-to-be-painful-part-1-an-empirical-approach-4.png

STEP 2: CREATE A HYPOTHESIS 

The next step is to create a hypothesis to test for each problem or focus area.

 

Example Hypothesis for Sprint Goals Focus Area:

We believe that by committing to and completing our sprint goals regularly we will build trust with stakeholders, customers, and each other. This should also help us forecast more effectively.  

 

Example Hypothesis for the Escaped Defects Problem: 

We believe that by focusing on increasing our unit test coverage and integrating more often, we will see less escaped defects due to faster quality feedback.

 

agile-retrospective-doesnt-have-to-be-painful-part-1-an-empirical-approach-5.png

STEP 3: IDENTIFY AND PRIORITIZE TESTS TO START WITH 

Now that we have a hypothesis we should figure out what tests we will run, these come in the form of action items. Here is where you will take your ideas and prioritize them to include in the next sprint, week, etc.

 

Example Hypothesis for Sprint Goals Focus Area:

We believe that by committing to and completing our sprint goals regularly we will build trust with stakeholders, customers, and each other. This should also help to forecast more effectively.  

Potential Action Items:

  • Improve sprint goals by using Roman Pichler’s sprint goal template (URL)

  • Review Burn down regularly at the daily scrum

  • Focus on work in progress throughout the sprint, create a starter team WIP limit

  • Create a skills matrix and prioritize skills to grow on the team

 

Example Hypothesis for the Escaped Defects Problem: 

We believe that by focusing on increasing our unit test coverage and integrating more often, we will see fewer escaped defects due to faster quality feedback.

 Potential Action Items:

  • Improve Continue Integration tooling and education

  • Create a working agreement for unit testing. Check out our post on how to coach creating working agreements with your team.

  • Use Gated Check-ins

 

agile-retrospective-doesnt-have-to-be-painful-part-1-an-empirical-approach-6.png

STEP 4: IDENTIFY LEADING INDICATORS AND OUTCOMES

Now that we have a hypothesis and some action items (experiments), we need to identify the measurable outcomes we hope to achieve and a way to measure our experiments without waiting until the outcome is reached or not. These are in the form of leading indicators which we will regularly review to determine if we are on track or not for achieving the outcomes we hope will solve a problem or grow a focus area. 

 

Example Hypothesis for Sprint Goals Focus Area:

We believe that by committing to and completing our sprint goals regularly we will build trust with stakeholders, customers, and each other. This should also help to forecast more effectively.  

Potential Action Items:

  • Improve sprint goals by using Roman Pichler’s sprint goal template (URL)

  • Review Burn down regularly at the daily scrum

  • Focus on work in progress throughout the sprint, create a starter team WIP limit

  • Create a skills matrix and prioritize skills to grow on the team

 Example Leading Indicators:

  • Weekly variability of throughput (Story count)

  • Sprint Goal Attainment Ratio

 Example: Outcomes to Verify:

  • Stakeholder SAT Score (Survey)

  • # of Releases

  • Forecasts met within an acceptable range

 

Example Hypothesis for the Escaped Defects Problem: 

We believe that by focusing on increasing our unit test coverage and integrating more often, we will see fewer escaped defects due to faster quality feedback.

Potential Action Items:

  • Improve Continue Integration tooling and education

  • Create a working agreement for unit testing

  • Gated Check-ins

 Example Leading Indicators:

  • Builds per day

  • Builds per day / Broken Builds

  • Unit test coverage

 Example: Outcome To Verify

  • Escaped Defects

 

Note: You may need to also prioritize the leading indicators if you have to implement them from scratch. 

 

agile-retrospective-doesnt-have-to-be-painful-part-1-an-empirical-approach-7.png

Step 5: Review at Future Retrospectives and Pivot or Persevere

At future retrospectives, review the hypothesis and leading indicators. Use as a data point to drive the retro and come up with action items for the current hypothesis or craft new ones depending on what is needed. Each retro then becomes a review of previous actions, leading indicators, and outcomes combined with potentially new outcomes or problems to solve. 

 

In Conclusion:

Agile retrospectives are critical to the success of any organization using Agile methodologies. However, they are often dismissed as unproductive and time-consuming. The value of retrospectives lies in the opportunity they provide to analyze past successes and failures, track demonstrable improvements, and implement changes that can help organizations continually refine their processes. In this first article of our series on how to improve retrospectives, we will explore practical tips and techniques that can help you create more engaging and productive retrospectives by using empiricism to drive retrospectives. We explain how the empirical approach is used in the agile process and provide four simple steps to get started. This approach helps you identify the problem to solve or focus area, create a hypothesis, identify and prioritize tests to start with, and identify leading indicators and outcomes to track progress towards the outcomes. Interested in learning more about the strategies to improve your team's retrospectives? Check out our blog post on Team Retrospective, from boring to brilliant with inspect and adapt.