Coaching and Training
- Also some Useful Tools
Note that we have some Incomplete Pages That Require Work on this site:-)
Note that we have some Incomplete Pages That Require Work on this site:-)
At the end of a sprint, the Team holds a Sprint (or Iteration) Retrospective to review their work process and the way the Team worked together (the “inspect and adapt” cycle for the process and people). This information can help the Team determine how to improve performance in the next Sprint / Iteration. Typically, the Retrospective is held after the Review / Demo.
When reviewing Retrospective materials you will often see that the Retrospective is about:
But then they offer little advice about how to make this happen. The result is that Teams will often set up a meeting, put these headings on the board and then discuss. While this can produce results, most Teams that do it this way will find the results superficial, that they feel that it is boring, and they feel that no progress is being made.
The first thing we need to ask ourselves is “what areas do we need to look at to focus on our improvements?”. In general, Teams can consider potential improvement topics, such as the following areas:
In addition in most cases should be an energizing (if sometimes exhausting) event.
Everyone on the Team should participate in the Retrospective. Others may be invited, but this is essentially a Team-focused activity. The Team can determine who they want to invite on a Iteration-by-Iteration basis.
The Scrum Master's role during the Retrospective is to facilitate the Team's discussion about improving their delivery process. It may be helpful, and a beneficial change of pace, to have someone else facilitate the meeting so the Scrum Master can participate as a “normal” Team member during the Retrospective. For example, another Team's Scrum Master could serve as facilitator.
The result of a Retrospective is a prioritized list of potential improvements with a few selected items to be worked on during the next Sprint / Iteration. Often these improvements are defined as backlog items, to ensure that they are worked on in the Sprint / Iteration. Like any backlog item these are estimated, prioritized and, when they become part of the Sprint / Iteration, are detailed just like any other backlog item.
During the next Sprint / Iteration's Retrospective, prior improvement items should be reviewed for progress made in achieving the expected result or to understand what happened, whether the improvement was (or still shows potential to be) successful, or whether something else needs to be tried.
As much as possible try to treat these improvements as “experiments.” In other words, we want to set up an experiment with an expected result, we understand how we are going to track the experiment (metrics) as we run it, and we then run the experiment in the next Iteration to see if the expected result occurs. There are a couple of reasons for doing it this way:
The results of the Retrospective, the experiments, are published so others (teams, management, etc) can see them. The idea is that others could review this information and learn from this team, adapting ideas to their own environment. Note that the activities and information used to generate the experiment is private to the Team. The Team needs to feel they have a safe environment to hash out issues. If this information has to be public then the team will not be able to talk about sensitive issues. So the result is public, but the process is private to the Team. In other words “we are not interested in the sausage making, but we are interested in the sausages.”
Duration: Maximum 1.5 hours for a 2 week Sprint / Iteration (10 working days) - 1/2 that for 1 week Sprint / Iteration.
Who: The Team and others invited by the team.
Result: A couple of improvement experiments to try in the next Sprint / Iteration, publish to a public place (team site).
Esther Derby and Diana Larson in “Agile Retrospectives” talks about the two loops of the inspect and adapt cycle associated with Scrum:
This is important as for many teams the Retrospective starts and ends with the question “what do we think we need to do better” without having a complete understanding of a problem or, more importantly why we have the problem. To combat this short term approach, they suggest that the following structure should be put in place when running a Retrospective:
The following is a simple Retrospective “script” aimed at working through your first Retrospective:
The following are suggested questions / topics that could be used to prompt Scrum Team members to discuss possible improvements:
All else being equal, focus on improving the Team's ability to make and meet commitments each Iteration, e.g., eliminate waste (don't create bugs) and decrease delays.
The order – quality, predictability, throughput – of these questions is significant. Experience shows that improve quality and predictability will typically improve throughput as well whereas the reverse is not true.
One thing we need to do is try and establish a “safe” place during the retrospective to express ideas, criticisms, problems, opinions and so on. One way to help this is to start the retrospective by reviewing the “retrospective prime directive”. This states:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
In other words, lets assume “good intent” and not that someone made it their mission in life to do something bad to me. We need this because as we go through the retrospective process we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgment used to embarrass.
In some cases, for example where there are big time zone issues, it may not be possible to get the whole team together for a lengthy meeting. If you do not run a Retrospective meeting, then you still need to determine a way to do incremental improvements, Iteration by Iteration. The team should be able to talk about improvement goals for the Iteration, how they are progressing those goals, and whether the experiment represented by the goal has been achieved at the end of the Iteration. They should be able to talk about past experiments they have run, and have a mechanism to decide about future experiments based on learning from the past, or new ideas that team members have. The improvement goals / experiments should be documented on the Team page so that others can learn as well.
As said, a Retrospective meeting is the easiest way to get this all done, ensures that the team takes time to focus on improvement, and helps with team dynamics by having the team work complex issues. You will want to have a very good reason for not doing a Retrospective meeting before deciding on some other approach. And, if you don't do this through a meeting, you will need to ensure that you take the time to focus on continuous improvement and that the equivalent results are part of your team documentation.
For distributed Teams, there is always an issue of “communication” and so you may want to consider this subject as a standard subject for every Retrospective the Team has or, in some cases, establish a single subject Retrospective to address a specific issue. Many people make the mistake of treating “communication” as a tool issue. In reality it is often an issue of working agreements a Team has (see How Can We Work More Effectively with Remote People? for more information).
One idea that might help Teams ensure material is available to discuss at the formal Retrospective session or help in those situations where the meeting is not possible is to post a “Running” Retrospective sheet in the Team area (or central tool page if the Team is distributed).
Some ideas for the format of the Running Retrospective:
Agile is intended to be an empirical approach to improvement, using data to help drive the process. Example metrics we start with are trends associated with the team’s “actual velocity”, “committed vs actual velocity” and “unplanned (interrupted) time”. These should be used to help understand whether things are improving.
Less formally, as teams come up with experiments they want to run, they should also determine what metrics they are going to track to understand whether progress is being made against the intended expectation. Once the metric has served it purpose, stop generating the metric. Don’t create “vanity” metrics (“see we are still doing this great”) or useless metrics (pages of data which are generated but from which no conclusion / decision is made).
One of the problems of Retrospectives is feeling like there is actual improvements being made. An idea to address this is to run a “Tears of Joy” exercise before the retrospective, perhaps as a check-in exercise. This is a simple exercise. You start be saying “before we get started, I'd like to remind ourselves about the progress we have made, where we came from and where we are today. With this in mind please think back over the last couple of Sprints (or whatever time period makes sense). At some time someone did something, or said something that brought 'a tear of joy' to your eyes. What was that event?” Give the folks a couple of minutes and then go around the room. You will be amazed at what you hear and, more importantly, you'll be able to leverage the positive discussion into the rest of the meeting.
I am indebted to Bob Galen for this idea. Note I find this is useful exercise to do in a variety of situations especially when you know there are significant problems to be addressed. By starting off on a positive note, with a reminder that we have successfully worked issues in the past, the current problems seem to become more solvable.