Sprint Retrospective Anti-Patterns Webinar
•Descargar como PPTX, PDF•
2 recomendaciones•3,706 vistas
This document outlines an upcoming webinar on November 27, 2018 about Sprint Retrospective Anti-Patterns. It will discuss 12 different anti-patterns that can negatively impact sprint retrospectives, including skipping the retrospective entirely, postponing or shortening the meeting, focusing on blaming others rather than improvement, and not following through on action items. The webinar leader, Stefan Wolpers, is an agile coach who will provide tips to help scrum teams run more effective retrospectives.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Sprint Retrospective Anti-Patterns Webinar
Similar a Sprint Retrospective Anti-Patterns Webinar (20)
Más de Stefan Wolpers
Más de Stefan Wolpers (20)
Último
Último (20)
Sprint Retrospective Anti-Patterns Webinar
- 1. Hands-on AgileWebinar #10 Sprint Anti-Patterns November 27th, 2018, at 6:15 pm CEST (12:15 pm EDT or 9:15 am PDT)
- 2. Introduction: The Sprint Retrospective stefan@age-of-product.com
- 3. Sprint Retrospective Anti-Patterns: The Scrum Master stefan@age-of-product.com
- 4. #1: Skipping Scrum Events — No Retrospective stefan@age-of-product.com
- 5. #2: The Postponed Retrospective stefan@age-of-product.com
- 6. #3: The Shortened Retrospective stefan@age-of-product.com
- 8. #5: The Blame Game Retrospective stefan@age-of-product.com
- 9. #6: Manager Alert stefan@age-of-product.com
- 10. #7: Line Manager Alert stefan@age-of-product.com
- 11. #8: Product Owner Non Grata stefan@age-of-product.com
- 14. #10: Someone Snitches stefan@age-of-product.com
- 15. #11: Pro Forma Action Items stefan@age-of-product.com
- 16. #12: Inadequate Facilities for Retrospectives stefan@age-of-product.com
- 17. Summary: Scrum Retrospective Anti-Patterns stefan@age-of-product.com
- 18. Hands-on AgileWebinar #11 Daily Scrum Anti-Patterns January 29th, 2019, at 6:15 pm CEST (12:15 pm EDT or 9:15 am PDT)
- 19. The Age of Product Youtube Channel
- 20. Contact Information StefanWolpers Email: stefan@age-of-product.com Blog: Age-of-Product.com Newsletter: https://age-of-product.com/subscribe (Join 20,300-plus peers) Slack: https://hands-onagile.slack.com/ (Join 4,300 peers) Twitter 1: @StefanW Twitter 2: @AgeOfProduct
- 21. About Stefan Wolpers Agile Coach, Scrum Master, and Product Owner since 2006: stefan@age-of-product.com
Notas del editor
- Hello everybody! Welcome to the last Hands-on Agile webinar of 2018. I am your host, Stefan Wolpers. Today, we will talk about one of the essential opportunities for inspection and adaptation — the sprint retrospective.
- Let’s start with a look at the manual: According to the Scrum Guide: Opportunity for the Scrum Team to inspect itself and create a plan for improvements for the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. Purpose: “closure.” The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process. (The SM is not merely facilitating the event.) The purpose of the Sprint Retrospective is to: Inspect how the last Sprint went with regards to people, relationships, process, and tools; Identify and order the major items that went well and potential improvements; and, Create a plan for implementing improvements to the way the Scrum Team does its work. The Scrum Master encourages the Scrum Team to improve, within the Scrum framework. Scrum Team: how to increase product quality by improving work processes or adapting the definition of "Done”? (If appropriate and not in conflict with product or organizational standards.) So, no rogue “Scrum”: improvements follow the Scrum Guide and are in compliance with organizational standards. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation: Discipline equals freedom; reduce the cognitive load by having a rule.
- Let’s start with the Sprint Retrospective anti-patterns of the Scrum Master.
- All Scrum events are essential for a team’s success — you cannot just skip an event. There are two form of Skipping retros: 1. #NoRetro at all: There is no retrospective as the team believes there is nothing to improve. There is no such thing as an agile Nirwana where everything is just perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve. 2. Dispensable buffer: The team cancels retrospectives if more time is needed to accomplish the sprint goal. The retrospective as a sprint emergency reserve is a common sign of cargo cult agile. I believe, it is even a worse anti-pattern than not having a retrospective because there is presumably nothing to improve. However, randomly canceling the retrospective to achieve a sprint goal is a clear sign that the team does not understand basic agile principles, such as continuous improvement. If the scrum team repeatedly does not meet a sprint goal, it should inspect what is going on here. Guess which scrum ceremony is designed for that purpose?
- The Scrum Master postpones the retrospective into the next sprint. Beyond the ‘inspection & adaptation’ aspect, the retrospective shall also serve as a moment of closure that resets everybody’s mind so that the team can focus on the new sprint. That is the reason why we have the retrospective before the planning of the next sprint: Postponing it into the next sprint will probably interrupt the flow of the team. (=> additional cognitive load, context switch.) Also delays also tackling possible improvements.
- The rushed retrospective: The team is in a hurry and allocates much less than the minimum 60 to 90 minutes for a retrospective. (By the way, the time-box is 3 hours for a month-long sprint.) Shortening the retrospective is a slippery slope and may probably end up with a ritualized ceremony of little value. Most team members will likely regard it as a waste sooner or later.
- Groundhog day: The retrospective never changes in composition, venue, or length. in this case that the team will likely revisit the same issues over and over again – it’s groundhog day without the happy ending, though, an empty ritual What you can do: Repository of exercises for all five stages — never run the same retro twice. Need ideas? Use Retromat, Tasty cupcakes — or be creative with Liberating structures, Training from the Back of the Room. Talk to your fellow SMs (HoA Slack) Change the venue Theme the retrospective — why not have a Halloween retrospective?
- The retrospective is an endless cycle of blame and finger pointing. The team wins together, the team loses together. So, the blame game documents both the failure of the Scrum Master as the facilitator of the retrospective as well as the team’s lack of maturity and communication skills. What can you do about it? Revist the Scrum Values: Commitment, courage, focus, openness, and respect. Without them, transparency, inspection and adaptation cannot work their magic. If Scrum Values are a challenge create, for example, a skill-radar for the Scrum Values and track the development over time.
- Stakeholder alert: The scrum master permits stakeholders to participate in the team retrospective — no need to say that psychological safety to address the elephant in the room will not be created this way. I do see the necessity that stakeholders want to communicate with the team. And the are alternatives: Run a separate overall retrospective with stakeholders There are also other scrum ceremonies that address the communication needs of stakeholders: the sprint review, probably the product backlog refinement, the daily scrums. Finally, there are plenty of opportunities of having a conversation at water coolers, over coffee, or during lunchtime.
- Line managers participate in retrospectives: This is the worst anti-pattern I can think off. It turns the retrospective into an truly unsafe place. And who would expect that an unsafe place triggers an open discussion among the team members? Any line manager who insists on such a proceeding signals his or her lack of understanding of basic agile practices. Note: Tricky situation no. 1: If you are small product delivery team at a start-up and a team member also serves in a management function — or is a founder — retrospectives might be challenging. In this case, consider hiring an external scrum master to facilitate meaningful retrospectives. Tricky situation no. 2: the line manager of one team member serves also on the team. My suggestion: avoid this situation at all costs. The promotion of a team member means that the individual probably needs a new team, too. There is no purposeful retrospective if one team member decides over bonuses or promotions of other team members.
- Product owner non grata: The product owner is not welcome at the retrospective. That is a simple one: the Scrum Guide refers to the scrum team having a retrospective, including the product owner.
- The final part of the webinar addresses Scrum Retrospective anti-patterns of the Scrum Team.
- Prisoners: Some team members only participate because they are forced to join. Don’t pressure anyone to take part in a retrospective—the law of two feet applies for retrospectives, too. Instead, make participating in the retrospective worth their time. The drive to continuously improve as a team needs to be fueled by intrinsic motivation, neither by fear nor by order. Tip: Retromat’s “Why are you here?” exercise is a good opener for a retrospective from time to time.) If some team members consider the retrospective to be of little or no value it is most often the retrospective format that sucks. Is it the same procedure every time, ritualized, and boring? (Just think of the Confluence retrospective template.) Have a meta-retrospective on the retrospective itself. Change the venue. Have a beer- or wine-driven retrospective. There are so many things a scrum master can do to make retrospectives great again and reduce the absence rate.
- Someone sings: Someone from the participants provides confidential information from the retrospective to an outsider. For retrospectives, the Vegas rule applies: what is said in the room, stays in the room. There is no exception from this rule. The reason for this is simple: Snitches kill psychological safety, and there will never be trust — which renders the exercise almost obsolete.
- The team picks UNSMART actions: Bill Wake created the SMART acronym for reasonable action items: S – Specific, M – Measurable, A – Achievable, R – Relevant, T – Time-boxed. If the team picks UNSMART action items, though, it sets itself up for failure. Example: “We want to change the bonus scheme of the company.” Good luck achieving that goal during the next sprint! #NoOwner: No one was chosen to be responsible for the delivery of an action item. If the “team” is supposed to fix issue X, probably everyone will rely on his or her teammates to handle it. Make someone responsible instead. #NoFollowUp? The team does not check the status of the action items from the previous retrospectives. The sibling of autonomy is accountability. If you are not following up on what you wanted to improve before why care about picking action items in the first place? By the way, at least one high-level the action items is supposed to be a part of the next Sprint.
- There is no adequate place available to run the retrospective: The least appropriate place to have a retrospective is a meeting room with a rectangular table surrounded by chairs. And yet it is the most common venue to have a retrospective. Becoming agile requires space. If this space is not available, you should become creative and go somewhere else. If the weather is fine, grab your stickies and go outside. Or rent a suitable space somewhere else. If that is not working, for example, due to budget issues, remove at least the table so you can sit/stand in a circle. Just be creative.
- Replay on Youtube channel.
- Some background on myself: I have spent 12-plus years in agile Mostly as a product owner in fast growing, vc-funded startups in Berlin (including a later Google subsidiary) At the moment, I am working as an agile coach/scrum master for a large European electricity and gas provider