Sprint Retrospective

From AgileMe
Jump to navigation Jump to search


The Sprint Retrospectives is an event normally held at the end of the Sprint and after the Sprint Review to provide an opportunity for the Scrum Team to inspect how they did the work in the Sprint and how they could improve with respect to “…people, relationships, process and tools.”[3] Also, the definition of “Done” may also be adapted and modified as needed. Improving the process can be done at anytime and the Sprint Retrospective provides an opportunity to gather and enable an adaptation to the Scrum Team “inspecting” itself.

Sprint Retrospective

Practical Tips

Take A Step Back Improvements can be done at any time, and sometimes it is more efficient to resolve and improve things in the moment, as issues or dysfunctions become apparent. Hence, the Scrum Team should not have to wait for the next Sprint Retrospective to air their concerns or implement improvements.

However, that said, teams can sometimes get caught up in doing the work and the Sprint Retrospectives provide an opportunity for the whole Scrum Team to get together, step back from the work and take stock of how they are working and if there are any improvements.

Safety Safety is a key ingredient to a good retrospective, as the Scrum Team will need to feel safe when presenting sensitive issues and be comfortable to discuss them freely. So be careful when inviting attendees that are not part of the Scrum Team, and ask the question about whether they will compromise the “safe” environment or enhance it. This particularly applies to leadership teams who can unknowingly counter the safety dynamic just by being in the same room.
Informal An informal get together with comfortable seating and some food tends to work well with most teams and allows them to have an open and honest discussion about how they are doing the work and provide more transparency.
Implement Ideas Improvement ideas are easy to generate with the team, however, implementing them and resolving the underlying issue, dysfunction or sub-optimal process is where the real value of the forum lies.

If the team’s ideas and resolutions are not implemented then after a short while the retrospectives become repetitive and the team will not see any value in attending them any further, and subsequently lose their ability to adapt their approaches and improve their process.

Theme Providing some goal, purpose or positioning for the Sprint Retrospective to focus on can help to concentrate the efforts and thinking of the Scrum Team to derive some good quality improvements.
General vs. Targeted General and targeted retrospectives can work well together, in that, a generic retrospective can consider the all of the process, people and tools etc. and provide general improvements.

In contrast, a targeted retrospective may zoom in on a specific area of interest and derive deeper improvements for that area. Hence, alternating between general retrospectives to provide areas of interest and targeted retrospectives to zoom in on specific areas can provide good coverage and in depth treatment.

More Than Superficial Understanding Teams may often provide only superficial answers to open questions such as “What went well?” and “What are the challenges?”, and so encouraging the team to explain *why* these items were good or challenging may help them to uncover deeper insights into their process and derive more appropriate improvements.
Layering Using layered retrospectives can help to compliment each other such as using a Sprint Retrospective at the end of a Sprint to take stock of the Sprint optimisation, coupled with a release retrospective at the end of the release, that can also consider the wider perspective of the release optimisation over several Sprints.
Coaching Retrospectives can also be used as a coaching tool to help individuals and small groups uncover the positive aspects of what they are doing, the challenges that they perceive, and then their derived improvements and action plans that they can implement.

Structure and Approach

"Agile Retrospectives: Making Good Teams Great" by Esther Derby and Diana Larsen [4] provides some insights into how to structure a Sprint Retrospective and the below sections provide a basic approach and some technique suggestions.

Part I: Getting Data

Timeline

So what happened since the last retro? Drawing up a quick timeline on a whiteboard and encouraging the team to contribute the events of what happened over the past weeks will help the team to remember those significant events that helped the project or hindered it. Doing a brief exercise like this helps to warm up the brain cells to begin to think objectively about what worked for the project and what challenges were experienced.

Metrics

Obtaining metrics from the Sprint such as the Sprint Burndown, or the number of issues with test deployment for example can help provide more informed understanding with richer conversations about how to resolve the issues.

Part II: The Retrospective

Things That Worked

So what worked for the team since the last retro? Asking the team this question can help a team to reframe any negative thoughts by asking them to think about positive events and things that went well. (This is the start of the journey to a creative session, so don't under estimate the power of remembering what worked well and how far the team have travelled.) Writing these positive items down on a whiteboard will help a team to see each other's responses, which may in turn, trigger new associated thoughts as well to contribute to the list.

The Challenges

After a while of listing the positive stuff it may be appropriate to start to list the challenges. The use of appropriate language here to provide an objective perspective can make all of the difference and neutralise any negative or emotional associations. Sometimes it may be appropriate to drill a bit deeper into the challenges as quite often the team may describe broad challenges rather than uncover the underlying causes. So a little encouragement to elaborate a little further on the challenges can go a long way.

Improvements

When the list of challenges begins to dry up start to look for improvements and solutions to remedy the challenges. If there are a lot of challenges in a long list, it may be more appropriate for the team to vote on which challenges they want to explore further and provide improvements for. Check out Dot Voting. At this stage the team should be let loose with their creative energy to provide inspired and innovative solutions to the challenges.

Part III: Closure

Actions

Improvements are great, but how is the team going to turn a list of good suggestions into reality? This is probably the most important part of the retrospective journey, in that, for the retro to have high value and real meaning, the improvements need to be actioned either as objectives for the team such as new Product Backlog items for example, or tasks on existing items. Either way, a proposed solution needs to be implemented not just talked about, otherwise the same improvements will appear on successive retros and when the team feel that nothing is happening with them, the value of the retro forum diminishes and with it any interest by the Team. Recognition A nice way to close out a retro is for the team to recognise someone either inside or outside of the Scrum Team for their outstanding efforts and positive contribution to the Sprint.

Retro on a Retro

A retro is a continuous improvement forum, so why not continually improve the continuous improvement forum? In plain English, why not perform a retro on the retro? It does not have to be as extensive as the full retro format but usually a little time at the end of the retro to talk about what was good in the retro and what improvements the team would like to make for the next retro can go a long way to ensuring that the retrospective remains highly valued by the team and are effective. Finally close out the session with a brief summary of what was covered in the retro.

See Also

References

  1. Scrum Guide
  2. Agile Retrospectives: Making Good Teams Great, Esther Derby, Diana Larsen, (2006)