UnSMART Improvements at Retrospectives [Video]
Making Your Scrum Work #18: Join me and delve into the consequences of picking unsmart improvements as a Scrum Team during your Retrospective.
Join the DZone community and get the full member experience.Join For Free
TL;DR: Unsmart Improvements
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short "manual," this effect should not surprise anyone. One area that typically flies under the radar is improvements. While the Scrum Guide encourages addressing the most impactful ones as soon as possible, it is up to the Scrum team to figure out how to improve. One manifestation of this core team task we often encounter is picking unsmart improvements, though.
Join me and delve into the consequences of picking unsmart improvements as a Scrum Team in less than 90 seconds.
Scrum Events and Skipping Retrospectives According to the Scrum Guide
There are many references to events in general and Retrospectives in particular in the Scrum Guide 2020:
- Page 6: The Scrum Master is accountable for the Scrum Team’s effectiveness.
- Page 6: [Scrum Masters] do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
- Page 10: The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
- Page 10: The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
- Page 10: The Scrum Team identifies the most helpful changes to improve its effectiveness..
- Page 10: The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Scrum Guide 2020 no longer advocates the previous approach: Choose at least one high-level improvement item for the next Sprint; now, it is a suggestion. However, the Scrum Guide does not guide how to accomplish the task at hand.
Manifestations of an Unsuited Improvement Approach
In my experience, three typical anti-patterns prevent a Scrum team from improving its way of working despite pouring money, brain, and time into becoming better at their game:
- The Scrum 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 directly responsible individual takes care of an improvement item. (If the "team" is supposed to fix issue X, probably everyone will rely on their teammates to handle it. Find a caretaker instead.)
- #NoFollowUp: The Scrum team does not check the status of the action items from the previous Sprint 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? Do not let the momentum of a successful Retrospect fizzle out that way.)
Unsmart Improvements: Conclusion
Every Scrum event is an opportunity for inspection and adaptation. The Sprint Retrospective provides that opportunity to the Scrum Team itself. While the Scrum Guide is no longer prescriptive regarding improvements, it points to the importance of continuously improving as a Scrum team. Hence, avoid standing in your way by picking unsmart improvements.
Have you met a Scrum team choosing unsmart improvements? What happened? Please share your learnings with us in the comments.
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.