Hans Samios' Personal Lean-Agile Knowledge Base

... absolutely #noabsolutes ...

User Tools

Site Tools

Trace:
how_do_we_run_our_first_sprint_retrospective

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
how_do_we_run_our_first_sprint_retrospective [2018/05/24 11:12] – [Meeting Outline] hpsamioshow_do_we_run_our_first_sprint_retrospective [2021/10/06 13:14] (current) – [Want to Know More?] hans
Line 1: Line 1:
-====== How Do We Run Our First Sprint (or Iteration) Retrospective? ======+====== How Do We Run Our First Iteration (Sprint) Retrospective? ======
  
 ====== Premise ====== ====== Premise ======
  
-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.+At the end of a sprint, the Team holds a Iteration (Sprint) 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.
  
 ====== Background ====== ====== Background ======
  
-The 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 to do? 
 +  * What did not go well that we should perhaps improve? 
 +  * What ideas do we have to improve? 
 + 
 +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: 
 + 
 +  * Quality: How to reduce defects which escape from the Sprints / Iteration?
   * Predictability: How to bring committed velocity close to actual velocity?   * Predictability: How to bring committed velocity close to actual velocity?
-  * Throughput: How to increase the value of work delivered each Sprint?+  * Throughput: How to increase the value of work delivered each Sprint / Iteration?
   * Team health: How are we working as a team?   * Team health: How are we working as a team?
  
 In addition in most cases should be an energizing (if sometimes exhausting) event. 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.+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 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 to be worked on during the next Iteration. Often these improvements are defined as backlog items, to ensure that they are worked on in the Iteration. Like any backlog item these are estimated, prioritized and, when they become part of the Iteration, are detailed just like any other backlog item.+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 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.+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: 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:
Line 33: Line 41:
 ====== Structure ====== ====== Structure ======
  
-**Duration**: Maximum 1.5 hours for a 2 week sprint (10 working days).+**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. **Who**: The Team and others invited by the team.
Line 48: Line 56:
   * 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 Iterations, 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 68: Line 76:
 ====== Sample Retrospective ====== ====== Sample Retrospective ======
  
-The following is a simple retrospective “script” aimed at working through your first retrospective:+The following is a simple Retrospective “script” aimed at working through your first Retrospective:
  
   * Preparation:   * Preparation:
     * Have team metrics (actual throughput / velocity, committed vs actual throughput / velocity, cycle time, and others such as % unplanned work) displayed in the room     * Have team metrics (actual throughput / velocity, committed vs actual throughput / velocity, cycle time, and others such as % unplanned work) displayed in the room
-    * Have “retrospective prime directive” displayed in the room - see below +    * Have “Retrospective Prime Directive” displayed in the room - see below 
-    * Have “timeline” drawn up in the room - see below “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
Line 129: Line 137:
 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. 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 [[blog:how_can_we_work_more_effectively_with_remote_people|How Can We Work More Effectively with Remote People?]] for more information).+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|How Can We Work More Effectively with Remote People?]] for more information).
  
 ===== "Running" Retrospective ===== ===== "Running" Retrospective =====
Line 159: Line 167:
   * Having a Retrospective: After a while team’s begin to feel they have all the improvements under control and so think they don’t need a retrospective. After all, they are perfect. To be clear – there is always room to get better, and so always a need for something like a retrospective.   * Having a Retrospective: After a while team’s begin to feel they have all the improvements under control and so think they don’t need a retrospective. After all, they are perfect. To be clear – there is always room to get better, and so always a need for something like 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.
Line 171: Line 179:
 ====== Want to Know More? ====== ====== Want to Know More? ======
  
 +  * [[what_can_we_do_to_improve_our_retrospectives|What Can We Do To Improve Our Retrospectives?]]
   * [[http://www.amazon.com/Agile-Retrospectives-Making-Pragmatic-Programmers-ebook/dp/B00B03SRJW/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=|Agile Retrospectives]] - the Bible!   * [[http://www.amazon.com/Agile-Retrospectives-Making-Pragmatic-Programmers-ebook/dp/B00B03SRJW/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=|Agile Retrospectives]] - the Bible!
-  * [[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 +  * [[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://retrospectivewiki.org/index.php?title=Agile_Retrospective_Resource_Wiki|Retrospective Wiki]] - resource for sharing retrospective plans, tips & tricks, tools and ideas to help us get the most out of our retrospectives+  * [[http://retrospectivewiki.org/index.php?title=Agile_Retrospective_Resource_Wiki|Retrospective Wiki]] - resource for sharing retrospective plans, tips & tricks, tools and ideas to help us get the most out of our retrospectives.
   * [[https://www.benlinders.com/exercises/|A retrospective toolbox from Ben Linders]] - Exercises to keep things interesting   * [[https://www.benlinders.com/exercises/|A retrospective toolbox from Ben Linders]] - Exercises to keep things interesting
   * [[https://plans-for-retrospectives.com/|"Dial-a-retrospective" or "Ret-ro-mat"]] - Uses the structure defined by Agile Retrospectives, and a suite of games / exercises to dial up a new retrospective.   * [[https://plans-for-retrospectives.com/|"Dial-a-retrospective" or "Ret-ro-mat"]] - Uses the structure defined by Agile Retrospectives, and a suite of games / exercises to dial up a new retrospective.
   * [[http://tastycupcakes.org|Tasty Cupcakes Tools for Innovation and Learning]] - Not just retrospectives, but exercises and games for all kinds of situations.   * [[http://tastycupcakes.org|Tasty Cupcakes Tools for Innovation and Learning]] - Not just retrospectives, but exercises and games for all kinds of situations.
-  * [[http://www.funretrospectives.com/|Fun Retrospectives]]+  * [[http://www.funretrospectives.com/|Fun Retrospectives]]. Site with, no surprise, fun retrospectives. 
 +  * [[http://www.liberatingstructures.com/|Liberating Structures]]. Great site for collaborative, inclusive facilitation techniques. Again, great for retrospectives but also useful in other situations. 
 +  * [[https://www.thevirtualagilecoach.co.uk/|Fun Retrospectives by the Virtual Agile Coach]]. Pretty much ready to be dropped into Mural or Miro.
  
 {{tag>Consultant Tools Team Retrospective Ceremony FirstSprint FAQ}} {{tag>Consultant Tools Team Retrospective Ceremony FirstSprint FAQ}}
- 
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_do_we_run_our_first_sprint_retrospective.1527185571.txt.gz · Last modified: 2020/06/02 14:25 (external edit)