Can we or should we change Scrum, or is it a sacrilege to tweak the ‘immutable’ framework to accommodate our teams’ and organizations’ needs?
Not so fast; don’t just dismiss augmenting Scrum as leaving the path, contributing to the numerous Scrumbut mutations, giving Scrum a bad name. However, in our rapidly evolving business landscape, sticking rigidly to traditional Scrum by the book could be a straightjacket stifling innovation, user focus, and adaptability.
From ensuring cultural compatibility to facing technical debt challenges and emerging technologies, discover ten compelling reasons why augmenting Scrum isn’t just okay—it’s necessary for modern teams.
Read on to discover when and how to adapt Scrum responsibly without diluting its essence.
TL; DR: Retrospective Facilitation — Going from Good to 🦄 Great
The magic technique to turn a boring Retrospective into an outstanding Retrospective is the rotation of the facilitator role equally among all team members. Check out the following ten benefits of this Retrospective facilitation practice, from boosting learning and skill development to ensuring continuity to encouraging ownership.
The Daily Scrum serves a single purpose: inspecting the progress toward the Sprint Goal by reflecting on yesterday’s learning. Then, if the need should arise, the Developers adapt their plan to accomplish the Sprint Goal. While the theory may be generally accepted, applying the idea to the practice is more challenging. One of the recurring issues is the continued popularity of the “three Daily Scrum questions” from the Scrum Guide 2017.
Let’s reflect on why answering these obsolete Daily Scrum questions negatively influences the Scrum team.
TL; DR: Your Unfit Product Goal and the Product Goal Canvas
We plan a lot in Scrum: There is a daily plan when the Developers think about progressing toward the Sprint Goal during the Daily Scrum. Of course, the Sprint Goal reflects an intermediate target the Scrum team considers valuable to solve their customers’ problems. Moreover, there is the Product Goal, a mid- or long-term objective of the Scrum team.
The problem is that when Scrum teams already struggle with embracing the concept of the Sprint Goal—first, you agree on the objective of the Sprint, then you pick the work you consider necessary to accomplish it—they most likely also struggle with proper Product Goals.
Let’s check three critical issues Scrum teams have with Product Goals and a practical tool that helps you avoid the mess.
There are plenty of failure possibilities with Scrum. Indeed, given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, the Scrum Guide clearly states the importance of self-management at the Scrum team level. Nevertheless, the prevailing cause of many messed-up attempts to use Scrum result from what I call agile micromanagement, a pseudo-commitment to agile principles only to be overridden whenever it seems beneficial from a stakeholder’s or manager’s perspective.
Join me and delve into the importance of self-managing Scrum teams in less than two minutes.
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. For example, what if there is no Sprint Goal — Sprint after Sprint? What if the Scrum team is always only working on a random assortment of work items that seem to be the most pressing at the moment of the Sprint Planning?
Join me and delve into the importance of the Sprint Goal for meaningful work as a Scrum team in less than two minutes.
