Agile ways of working: Continuous improvement through retrospectives

The effectiveness of individuals and teams is drastically improved when you take the time to regularly review what worked and what didn’t work. Retrospectives are the key to building high performing teams. 

Solving complex problems can be, well, complex. If it were easy, anybody could do it, or at the very least, it wouldn’t be worth the attention of a dedicated team. Leveraging Agile ways of working, a team comes together and utilises their skills to incrementally find the solution over a period of time. The challenge for a group of people working together over time is to continually improve how they solve the problem, as problem solving is more effective when there is a focus on continuous improvement. 

Continuous improvement has been the focus of many industries, particularly manufacturing, since the 50s. It was a technique that transformed manufacturing processes creating efficiency and in turn transforming the world. Increased production and reduced costs meant that more products and food were available and the standard of living went up across the world. Continuous improvement in manufacturing meant that society literally improved continuously. Advances in medicine, agriculture, food processing and storage, housing, infrastructure and even the internet have provided the opportunity for populations to expand and in some cases, thrive. While the downside of this may have been on the environment, people are literally alive today because of this revolutionary approach. Maybe we can use it to reduce our impact on the environment and solve the problems we now face!  

Continually reviewing our efforts generally encourages incremental improvement over time. Improvements are based on many small changes rather than the radical changes that might arise from large research and development initiatives.

By having a structure where you can shine a light on things that worked and things that didn’t, teams can focus on improving and behaviours can change. In ‘Getting Things Done’, David Allen suggests setting aside time each week to review your ‘To Do’ lists of what was completed and not completed in the preceding week. This level of self reflection can allow you to prioritise your work, ensure you don’t miss anything important and then start the next week fresh.

In agile, this concept can be extended and applied to teams by scheduling a formal workshop, called a ‘retrospective’. Retrospectives are essentially planned sessions that follow a period of work (e.g a two-week sprint) that focuses on what did or didn’t go well, and what can be done to improve the next sprint.

The goal of an agile team is to continuously improve how they work as a team.  While teams generally want to work well together, meeting fortnightly to discuss what is working and what isn’t, is a different concept to the traditional post project review. 

Initially, retrospectives can seem risky. The idea of getting the team together, client included, to discuss what worked and didn’t work, could have dire consequences for the team’s ability to work together. One of the challenges with Agile is its demand for individuals to be transparent or, at the very least, open to providing and receiving feedback. The effectiveness of the team can be determined by its openness with each other. Teams generally rely on the social contract (that the team have developed together at the start of the project), as the basis for how they give and receive feedback. Referencing the social contract as a reminder of what the team agreed, can be a good way to start a retrospective in a ‘safe’ way. 

A retrospective needs to include the product owner (the person responsible for the end product) and the entire scrum team, which may include QA, design, development and project management. 

Planning for a retrospective

For the first retrospective meeting, everyone on the team should think about a few key questions and be ready to discuss them: 

• What went well during the sprint? (Continue doing)
• What didn’t go quite so well? (Stop doing)
• What could we do better next time? (Start doing)

If we have honestly and thoroughly thought about what went right and what could be better, we can go into the retrospective meeting ready to have a useful conversation.

For a team’s first retrospective, it is useful to review the social contract. In subsequent meetings, you can simply revisit anything in the social contract that may need discussion. From there it can be effective to simply ask questions about how the team is communicating, collaborating and working together. It can be an effective ice breaker. Essentially the aim is to ensure that the team feel psychologically safe to share feedback openly. If they don’t, then it may be necessary to stop the meeting and deal with individual issues. 

Running a retrospective

Schedule an hour for your first retrospective. Email the team in advance and ask them to consider the above questions before the meeting.  Include those questions in the calendar invite. If you have a team that is distributed across multiple locations, it can be effective to use a tool such as Retrium. This software allows the team to enter their thoughts on the three questions: What should we start doing? What should we stop doing?  And finally, what should we continue doing? 

You can do this with post-it notes or cards, providing 10 mins to answer the three questions. 

Then, together group the notes into related theme areas. The team then votes on which themes to discuss. Team members use their three votes on any theme they like. As a team, discuss the themes with the most votes. 

There may be something controversial among the themes. Encourage this conversation rather than stifle it. While it may be confronting, the theory is that it is better to get it out in the open than have it simmer. The challenge is to ensure that people do not feel under threat. Direct participants to take on the problem collectively, rather than pointing to a single person. For example ‘our meetings haven’t been starting on time and we agreed in our social contract that they would’, is far more effective than ‘Fatima, you are always late to meetings!’ If this approach is raised, remind the team to address the issue raised rather than a person. They may be surprised that the person who is often late actually speaks up and commits to be on time in the future. The focus on the team winning can be enough for people to be willing to change their behaviour. 

Record the actions that the team committed to and share them in your communication channel (or wiki) following the meeting. It may feel like pressure for some team members, so share the information as ‘what we agreed’. It provides people ownership rather than receiving the information as instructions or reprimand. 

Suggested agenda

1. Review. Discuss the previous retrospective actions. (5 mins)

2. Write down. Write / type up items for each of the columns "Start doing", "Stop doing", "Continue doing" on sticky notes. (10 mins)

3. Share. Team members share their items for each column and sort them into common themes, asking for clarity where needed. (10 mins)

4. Vote. Team members vote on themes to be discussed. Each team member gets three votes and they can spend them where they like. (5 mins)

5. Capture. The team discuss the items with the most votes. A nominated team member records actions and assigns to an individual to ensure that action is complete by the next retrospective. Actions need to be achievable by the next retrospective. If an action can't, it's too big or ill-defined, so break it up into smaller chunks. (30 mins)

Achieving better outcomes

The ability to have a retrospective allows the team the opportunity to stop and reflect on where they did well and where they need to improve. This is a core tenet of self-organising teams that can take some time to get used to, however it is highly effective over time to encourage incremental improvements. It is distinctly harder in a scrum team where the client is involved and it can be confronting for them to both provide feedback and receive it! The nature of a cross-company team means that retrospectives are more critical than they would be for an internal team. 

Retrospectives can be effective at recognising what an individual or the team have done well in the last fortnight, as often it can be lost in a post project review. That fast feedback cycle is generally a positive. However be prepared for a situation where a team member tells the product owner that they are holding up the team. A retrospective is an opportunity to be able to highlight the good and the areas to improve, all in a safe environment. If you get it right, the team will flourish and the focus on continuous improvement will lead to better outcomes.

Tips

1. Involve the entire team.
2.  Remember to also focus on the positive stuff!
3. Follow up on previous retrospectives.
4. Consider inviting other stakeholders where appropriate.
5. Retrium is an effective online tool for distributed teams to all participate.
6. Improvement using retrospectives is iterative and can take time.
7. Focus on the issue/task, not the person.
8. Don’t commit to more actions than can be completed before the next retrospective.