how_do_we_run_our_first_sprint_retrospective
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
how_do_we_run_our_first_sprint_retrospective [2015/11/20 08:21] – [Challenges of a Retrospective] hpsamios | how_do_we_run_our_first_sprint_retrospective [2020/12/16 11:03] – Terminology consistency hans | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== How Do We Run Our First Sprint Retrospective? | + | ====== How Do We Run Our First Iteration (Sprint) Retrospective? |
====== Premise ====== | ====== Premise ====== | ||
- | At the end of a sprint, the Scrum Team holds a Sprint Retrospective to review | + | At the end of a sprint, the Team holds a Iteration (Sprint) Retrospective to review |
====== Background ====== | ====== Background ====== | ||
- | The Scrum Team can consider potential improvement topics, such as the following areas: | + | When reviewing Retrospective materials you will often see that the Retrospective is about: |
- | * Quality: How to reduce defects which escape from the Sprints | + | * What went well that we should continue |
- | * Predictability: | + | * What did not go well that we should perhaps improve? |
- | * Throughput: How to increase the value of work delivered each Sprint | + | * What ideas do we have to improve? |
- | In addition, the Retrospective should function as a health check for the team (how are we doing together as a team) and in most cases should be an energizing (if sometimes exhausting) event. | + | 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, |
- | Everyone on the Scrum Team should participate in the Retrospective. Others may be invited, but this is essentially a Scrum Team-focused activity. The Scrum Team can determine who they want to invite on a Sprint-by-Sprint | + | The first thing we need to ask ourselves is "what areas do we need to look at to focus on our improvements?" |
+ | |||
+ | * Quality: How to reduce defects which escape from the Sprints / Iteration? | ||
+ | * Predictability: | ||
+ | * Throughput: How to increase the value of work delivered each Sprint / Iteration? | ||
+ | * Team health: How are we working as a team? | ||
+ | |||
+ | 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 | ||
The Scrum Master' | The Scrum Master' | ||
- | The result of a Sprint | + | The result of a Retrospective is a prioritized list of potential improvements with a few selected |
- | During the next Sprint' | + | During the next Sprint |
- | 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 Sprint | + | 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 |
- | * We want to encourage a general | + | * We want to encourage a general Team level of risk taking but we want to have intentional risk. An experiment is a way of phrasing and running something risky without making it seem like an “all or nothing” approach. |
* In the wider organization, | * In the wider organization, | ||
- | The results of the Sprint | + | The results of the Retrospective, |
====== Structure ====== | ====== Structure ====== | ||
- | **Duration**: | + | **Duration**: |
- | **Who**: The Scrum Team and others invited by the team. | + | **Who**: The Team and others invited by the team. |
**Summary Agenda**: | **Summary Agenda**: | ||
- | * Review results of last Sprint | + | * Review results of last Retrospective |
+ | * Review last Iteration | ||
+ | * Review metrics (such as planned vs actual work, throughput / velocity, cycle time on work) | ||
* What worked? What isn't working? | * What worked? What isn't working? | ||
* What adjustments should we make to improve performance? | * What adjustments should we make to improve performance? | ||
- | | + | * Health check for the team |
- | * Health check for the team | + | |
* Is there anything we want to raise to management that would help? | * Is there anything we want to raise to management that would help? | ||
- | **Result**: A couple of improvement experiments to try in the next sprint, publish to a public place (team site). | + | **Result**: A couple of improvement experiments to try in the next Sprint / Iteration, publish to a public place (team site). |
====== Meeting Outline ====== | ====== Meeting Outline ====== | ||
Line 51: | Line 62: | ||
Esther Derby and Diana Larson in “[[http:// | Esther Derby and Diana Larson in “[[http:// | ||
- | - Deliverable: | + | - Deliverable: |
- Methods and Teamwork: Like the deliverable we need a “plan, do, check, act” cycle for the improvements associated with the people and process we use. | - Methods and Teamwork: Like the deliverable we need a “plan, do, check, act” cycle for the improvements associated with the people and process we use. | ||
- | This is important as for many teams the retrospective | + | This is important as for many teams the Retrospective |
- Set the stage: Get everyone to say something and check into the process. | - Set the stage: Get everyone to say something and check into the process. | ||
- | - Gather data: Brainstorm what happened during the Sprint. People have a tendency to remember easily what happened in the last few days of the Sprint, but often have a hazier view of the early part of the sprint. Worse people will often see the same event but have totally different views of the event. The idea is that, before we decide what experiments we are going to run, we should make sure we have a common understanding of what happened. It is important to treat this part of the retrospective | + | - Gather data: Brainstorm what happened during the Iteration. People have a tendency to remember easily what happened in the last few days of the Iteration, but often have a hazier view of the early part of the sprint. Worse people will often see the same event but have totally different views of the event. The idea is that, before we decide what experiments we are going to run, we should make sure we have a common understanding of what happened. It is important to treat this part of the Retrospective |
- | - Generate insights: Look at the data we have, understand what it means and then brainstorm ideas to address these. | + | - Generate insights: Look at the data we have, understand what it means and then brainstorm ideas to address these. |
- | - Decide what to do: Prioritize the ideas and decide as a team which ones we need to take on in the next Sprint. Put together a experiment to figure out whether the idea has merit. Use [[https:// | + | - Decide what to do: Prioritize the ideas and decide as a Team which ones we need to take on in the next Iteration. Put together a experiment to figure out whether the idea has merit. Use [[https:// |
- | - Close: And now its time to celebrate the conclusion of another successful | + | - Close: And now its time to celebrate the conclusion of another successful |
====== Sample Retrospective ====== | ====== Sample Retrospective ====== | ||
- | The following is a simple | + | The following is a simple |
* Preparation: | * Preparation: | ||
- | * Have team metrics (actual velocity, committed vs actual velocity, % unplanned work) displayed in the room | + | * Have team metrics (actual |
- | * Have “retrospective prime directive” displayed in the room | + | * Have “Retrospective Prime Directive” displayed in the room - see below |
- | * Have “timeline” drawn up in the room (see “running retrospective” for image) | + | * Have “timeline” drawn up in the room - see below “Running Retrospective” for image |
* Have “liked, didn’t like, kudos, idea” grid drawn up in the room | * Have “liked, didn’t like, kudos, idea” grid drawn up in the room | ||
* Food in the room, perhaps something to celebrate with as well | * Food in the room, perhaps something to celebrate with as well | ||
* Introduction: | * Introduction: | ||
- | * Set the stage: Ask the team (everyone to respond) “In one word, describe what you thought of the last sprint”. | + | * Set the stage: Ask the team (everyone to respond) “In one word, describe what you thought of the last iteration”. |
- | * Gather data: Point out the “timeline” diagram on the wall and describe how it is used – when event occurs on X-axis, how “good” or “bad” you thought the thing was based on distance above and below the line. Then have the team pair up and interview each other about “events that happened during the Sprint.” While one person talks about events they remembered, the other acts as a scribe writing down what they hear (one item per sticky note) only asking questions to clarify ideas (no judgment). Then have pairs switch roles. Finally have each person go up to the time line and talk about the things they remember, placing the sticky notes on the timeline and, when something is up there already that is similar, group those items together. | + | * Gather data: Point out the “timeline” diagram on the wall and describe how it is used – when event occurs on X-axis, how “good” or “bad” you thought the thing was based on distance above and below the line. Then have the team pair up and interview each other about “events that happened during the Iteration.” While one person talks about events they remembered, the other acts as a scribe writing down what they hear (one item per sticky note) only asking questions to clarify ideas (no judgment). Then have pairs switch roles. Finally have each person go up to the time line and talk about the things they remember, placing the sticky notes on the timeline and, when something is up there already that is similar, group those items together. |
* Generate insights: Point out “liked, didn’t like, kudos, ideas” diagram. Explain usage – “liked” is for those things we liked that we want to continue doing or even improve, “didn’t like” is for those things we didn’t think were good as well as a couple of ideas on how we could address, “kudos” is to provide kudos to someone on the team that needs appreciation as a result of something they did to help the team, and “ideas” is for other ideas we have that are things we might want to try to improve. As joint team activity, have people either move items from the “timeline” to the “liked” board or create new ideas (more stickies) and “kudos” items. For the “improvement” areas generate a couple of ideas on experiments we could run as part of the move. | * Generate insights: Point out “liked, didn’t like, kudos, ideas” diagram. Explain usage – “liked” is for those things we liked that we want to continue doing or even improve, “didn’t like” is for those things we didn’t think were good as well as a couple of ideas on how we could address, “kudos” is to provide kudos to someone on the team that needs appreciation as a result of something they did to help the team, and “ideas” is for other ideas we have that are things we might want to try to improve. As joint team activity, have people either move items from the “timeline” to the “liked” board or create new ideas (more stickies) and “kudos” items. For the “improvement” areas generate a couple of ideas on experiments we could run as part of the move. | ||
* Decide what to do: Dot-dot vote to prioritize the ideas. Pick the top 2 or 3. Then split into a couple of groups have each group generate SMART goals which define the experiment the team wants to run. Review results with whole team and finally decide which ones the team is going to take on in the next sprint. | * Decide what to do: Dot-dot vote to prioritize the ideas. Pick the top 2 or 3. Then split into a couple of groups have each group generate SMART goals which define the experiment the team wants to run. Review results with whole team and finally decide which ones the team is going to take on in the next sprint. | ||
* Close: time to celebrate. | * Close: time to celebrate. | ||
- | |||
- | Note: the “Retromat” tool (http:// | ||
====== Potential Retrospective Topics ====== | ====== Potential Retrospective Topics ====== | ||
Line 87: | Line 97: | ||
* Improve quality by asking: | * Improve quality by asking: | ||
* "How do we get closer to ' | * "How do we get closer to ' | ||
- | * "How do we get to zero bugs in this sprint?" | + | * "How do we get to zero bugs in this Iteration?" |
- | * "How do we reduce the technical debt of the product?" | + | * "How do we reduce the technical debt of the product |
* "Have we considered things like administration, | * "Have we considered things like administration, | ||
+ | * "Have we reduced the amount of time it takes to move completed work to production?" | ||
+ | * "How can we get closer to the customer?" | ||
* Improve predictability by asking: | * Improve predictability by asking: | ||
- | * "How do we get committed velocity within 10% of actual velocity?" | + | * "How do we get committed velocity |
* Improve throughput (throughput is time to get an idea or concept into shippable code) by asking: | * Improve throughput (throughput is time to get an idea or concept into shippable code) by asking: | ||
- | * "How could we have taken on one additional Backlog item this Sprint?" | + | * "How could we have taken on one additional Backlog item this Iteration?" |
- | * “How can we focus more on delivering product backlog items?” | + | * "How can we focus more on delivering product backlog items?" |
- | * “What delays could we remove from how we work so we could go ‘faster’” | + | * "What delays could we remove from how we work so we could go ‘faster’?" |
- | * “How could we increase the work we do in parallel to reduce ‘serial’ handoffs” | + | * "How could we increase the work we do in parallel to reduce ‘serial’ handoffs"? |
- | * “How could we reduce the average cycle time of an individual story going through a Sprint” | + | * "How could we reduce the average cycle time of an individual story going through a Iteration" |
- | * “How could we ‘swarm’ more on the work we do in a Sprint and so increase focus and decrease the amount of work we have in progress” | + | * "How could we ‘swarm’ more on the work we do in a Sprint and so increase focus and decrease the amount of work we have in progress" |
+ | * "How we can reduce the amount of work-in-progress (WIP) we have so that we reduce the risk associated with completing the Sprint and increase our ability to deliver" | ||
+ | * Improve team health by reviewing how Team interacted with each other. Some tools often will help this discussion. For example: | ||
+ | * Use the [[https:// | ||
+ | * Use the Five Dysfunctions of a Team survey to discussion team dynamics | ||
+ | * Use a [[http:// | ||
- | All else being equal, focus on improving | + | All else being equal, focus on improving |
The order – quality, predictability, | The order – quality, predictability, | ||
Line 114: | Line 131: | ||
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 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. | ||
- | ===== Meeting | + | ===== Distributed Teams ===== |
- | The purpose of the retrospective is to get better though incremental improvements in the way the team works together and works with others. It also serves the purpose of helping the team to bond as they work through difficult issues. There-fore by far the best approach is to have a regular scheduled retrospective. | + | 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 |
- | + | ||
- | 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 | + | |
As said, a Retrospective meeting is the easiest way to get this all done, ensures that the team takes time to focus on improvement, | As said, a Retrospective meeting is the easiest way to get this all done, ensures that the team takes time to focus on improvement, | ||
+ | |||
+ | For distributed Teams, there is always an issue of " | ||
===== " | ===== " | ||
Line 128: | Line 145: | ||
Some ideas for the format of the Running Retrospective: | Some ideas for the format of the Running Retrospective: | ||
- | * Have a series of columns labeled " | + | * Have a series of columns labeled " |
* More simply the columns might be " | * More simply the columns might be " | ||
* Another approach is to use a “timeline” where the sprint days are on the X-axis and the Y-axis represents how positive or negative I feel about the item: | * Another approach is to use a “timeline” where the sprint days are on the X-axis and the Y-axis represents how positive or negative I feel about the item: | ||
Line 136: | Line 153: | ||
===== Using Metrics ===== | ===== Using Metrics ===== | ||
- | Scrum is intended to be an empirical approach to improvement, | + | Agile is intended to be an empirical approach to improvement, |
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). | 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). | ||
Line 145: | Line 162: | ||
I am indebted to [[http:// | I am indebted to [[http:// | ||
+ | |||
====== Challenges of a Retrospective ====== | ====== Challenges of a Retrospective ====== | ||
* Having a Retrospective: | * Having a Retrospective: | ||
* All the issues are not the team’s fault: For these teams, recommend that the team’s maintain two lists: 1) things that the team needs to address 2) things that the organization needs to address. Set the expectation that both lists will be populated. | * All the issues are not the team’s fault: For these teams, recommend that the team’s maintain two lists: 1) things that the team needs to address 2) things that the organization needs to address. Set the expectation that both lists will be populated. | ||
- | * Organizational issues are being dealt with: Management has responsibility to the system the team is operating in. In the early days of the team, there are typically many things identified that can and should be addressed by the team and you often see rapid improvement. Some things can only be addressed by management, and the worse thing that can happen is that the team repeatedly raises organizational issues, but nothing is done about it. Management needs to be open and transparent about working organizational issues and become very responsive to these kinds of requests. | + | * Organizational issues are not being dealt with: Management has responsibility to the system the team is operating in. In the early days of the team, there are typically many things identified that can and should be addressed by the team and you often see rapid improvement. Some things can only be addressed by management, and the worse thing that can happen is that the team repeatedly raises organizational issues, but nothing is done about it. Management needs to be open and transparent about working organizational issues and become very responsive to these kinds of requests. |
* The team does not talk about people issues: Some people think that high performing teams are smooth running teams. The opposite is true. A significant hallmark of high performing teams is “constructive dissent” where there is passionate disagreements about the things that are important to the goals of the team. To make this kind of happen, team members really need to be able to trust their team mates. Trust only develops when you have dealt (as a team) with all the inter-personal issues you have. Trust does not develop where everyone is behaving politely and where people have not worked through the difficult personal issues. | * The team does not talk about people issues: Some people think that high performing teams are smooth running teams. The opposite is true. A significant hallmark of high performing teams is “constructive dissent” where there is passionate disagreements about the things that are important to the goals of the team. To make this kind of happen, team members really need to be able to trust their team mates. Trust only develops when you have dealt (as a team) with all the inter-personal issues you have. Trust does not develop where everyone is behaving politely and where people have not worked through the difficult personal issues. | ||
* The team does not see improvement from one sprint to the next: Make sure the first part of the retrospective is focused on “what happened as a result of the last set of experiments we have run – did things get better and, if not, what have we learned.” See also the "Tears of Joy" idea above. | * The team does not see improvement from one sprint to the next: Make sure the first part of the retrospective is focused on “what happened as a result of the last set of experiments we have run – did things get better and, if not, what have we learned.” See also the "Tears of Joy" idea above. | ||
* The retrospective is dominated by the same people all the time: There are a lot of approached aimed at getting everyone to participate. The Scrum Master (as facilitator) should worked to make sure everyone’s input is heard. | * The retrospective is dominated by the same people all the time: There are a lot of approached aimed at getting everyone to participate. The Scrum Master (as facilitator) should worked to make sure everyone’s input is heard. | ||
- | * The meeting is boring: Especially after the 10< | + | * The meeting is boring: Especially after the 10th retrospective – same activities, often the same results … Switch things up by: |
* Having a special guest Scrum Master come in to facilitate the retrospective | * Having a special guest Scrum Master come in to facilitate the retrospective | ||
* Set up a rotating retrospective amongst team members | * Set up a rotating retrospective amongst team members | ||
* Use resources like tastycupcakes.org to get new and interesting ideas. | * Use resources like tastycupcakes.org to get new and interesting ideas. | ||
* And so on. | * And so on. | ||
+ | |||
+ | ====== Want to Know More? ====== | ||
+ | |||
+ | * [[what_can_we_do_to_improve_our_retrospectives|What Can We Do To Improve Our Retrospectives? | ||
+ | * [[http:// | ||
+ | * [[collaboration_at_scale_-_keeping_retrospectives_fresh_by_ben_linders|Keeping Retrospectives Fresh]] - report of a webinar. Idea is to vary goal, exercises and environment to keep retrospective engaging. | ||
+ | * [[http:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
{{tag> | {{tag> |
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_do_we_run_our_first_sprint_retrospective.txt · Last modified: 2021/10/06 13:14 by hans