what_can_we_do_to_improve_our_retrospectives
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| what_can_we_do_to_improve_our_retrospectives [2020/12/02 06:33] – Fixed quotes hans | what_can_we_do_to_improve_our_retrospectives [2025/02/21 07:25] (current) – Added want to know more hans | ||
|---|---|---|---|
| Line 16: | Line 16: | ||
| In my experience there are some simple do’s and don’ts that Scrum Masters can use to improve Retrospectives: | In my experience there are some simple do’s and don’ts that Scrum Masters can use to improve Retrospectives: | ||
| - | * Do understand and use a proper retrospective structure ala agile retrospectives - see below | ||
| * Do take time to do a retrospective. General rule of thumb is that if you have a 2 week iteration, you might need a 2 hour retrospective. For a retrospective for a whole quarter you might need up to half a day (depends on depth of discussion). Do not short change the retrospective. Remind people that: | * Do take time to do a retrospective. General rule of thumb is that if you have a 2 week iteration, you might need a 2 hour retrospective. For a retrospective for a whole quarter you might need up to half a day (depends on depth of discussion). Do not short change the retrospective. Remind people that: | ||
| > | > | ||
| + | * Do understand and use a proper retrospective structure ala agile retrospectives - see below | ||
| + | * Do take the time to do an ice-breaker for the team, especially in these times when we are working remotely. Ice-breakers help us learn about our team mates. Pick a subject (it doesn’t have to be a lean agile subject), have people contribute to that subject, and have each person review what they provided, encouraging discussion. | ||
| * Do review results of previous retrospective to close the feedback loop. This reminds people that we are making progress (often we forget how bad things used to be) while establishing the seriousness of the retrospective meeting. Do not sugar coat this - if nothing happened as a result of the previous retrospective (e.g. we identified an improvement area, but didn’t follow up the item with action) then report that. | * Do review results of previous retrospective to close the feedback loop. This reminds people that we are making progress (often we forget how bad things used to be) while establishing the seriousness of the retrospective meeting. Do not sugar coat this - if nothing happened as a result of the previous retrospective (e.g. we identified an improvement area, but didn’t follow up the item with action) then report that. | ||
| * Do spend time on what happened over the period we are reflecting on to reduce impact of [[https:// | * Do spend time on what happened over the period we are reflecting on to reduce impact of [[https:// | ||
| Line 62: | Line 63: | ||
| * Do structure retrospective differently when working with distributed people so that you maximize use of overlapping time to do the things that are best done (synchronized) as a team (vs asynchronous). So for a standard structure retrospective: | * Do structure retrospective differently when working with distributed people so that you maximize use of overlapping time to do the things that are best done (synchronized) as a team (vs asynchronous). So for a standard structure retrospective: | ||
| - | |||
| * Set the stage: Can initially be asynchronously done in email or a text backchannel. Once the team actually meets synchronously, | * Set the stage: Can initially be asynchronously done in email or a text backchannel. Once the team actually meets synchronously, | ||
| * Gather data: Can start solo and asynchronously. Each team member gathers their data asynchronously in advance and when the team meets, they can review the data together to gain shared understanding and agreement on the data. Sometimes people create a collection point where team members can collect data. | * Gather data: Can start solo and asynchronously. Each team member gathers their data asynchronously in advance and when the team meets, they can review the data together to gain shared understanding and agreement on the data. Sometimes people create a collection point where team members can collect data. | ||
| Line 73: | Line 73: | ||
| * Do engaged with Teams. Set the expectation that Retrospectives are being done and, more importantly, | * Do engaged with Teams. Set the expectation that Retrospectives are being done and, more importantly, | ||
| - | * Do encourage peer discussions. Sometimes seeing another Team solve a problem that seems t be related to one they are working on will offer a breakthrough for the Team. Sometimes just seeing another Team improve will encourage other Teams to try things as well. Success breeds success. | + | * Do encourage peer discussions. Sometimes seeing another Team solve a problem that seems to be related to one they are working on will offer a breakthrough for the Team. Sometimes just seeing another Team improve will encourage other Teams to try things as well. Success breeds success. |
| + | |||
| + | ====== Want to Know More? ====== | ||
| + | |||
| + | * [[how_do_we_get_away_from_business_as_usual_thinking_on_teams|How Do We Get Away from “Business as Usual” Thinking On Teams?]] for ideas on improvement. | ||
| + | * [[what_can_we_do_to_improve_our_retrospectives|What Can We Do To Improve Our Retrospectives? | ||
| + | * [[how_do_we_run_our_first_sprint_retrospective|How do we run our first retrospective ceremony]]) | ||
| + | * [[what_does_a_scrum_master_do_all_day|What Does a Scrum Master Do All Day?]] | ||
| + | * [[https:// | ||
| {{tag> | {{tag> | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/what_can_we_do_to_improve_our_retrospectives.1606919608.txt.gz · Last modified: 2020/12/02 06:33 by hans