The Scrum framework offers clear rules, guidelines, and constraints. Teams can use them as boundaries to self-manage & self-organize their work, minimize risk, and deliver value to their stakeholders.
When teams are relatively new to Scrum, strictly using the rules & constraints makes sense.
For example:
✅ A Daily Scrum takes 15 minutes
✅ Each Sprint has a Sprint Goal
✅ All our work is made visible on the Product- and Sprint Backlog
✅ Each Sprint results in a potentially releasable increment
✅ Each Sprint, we use the Retrospective to identify actionable improvements
- Etc.
Some rules will be easy to follow, and others might be challenging. You could consider this the ‘Shu-phase.’ Just follow the rules.
Finding the right moment to allow teams to bend the rules is intriguing when working with teams. Although ‘allowing’ might be poorly described, who am I to deny the team anything?
Scrum offers all the rules & constraints for a reason. What if the team wants to stop using Sprint Goals? They tried it, but it didn’t work; it’s considered too difficult. Or the Sprint Retrospective is perceived as a waste of time. Or do they not see the point of working at Sprints? Why not focus on a continuous flow of value?
I love it when teams raise these questions. It shows that they care about their work, the process, and how they collaborate.
Besides a short “Scrum Police phase 👮♂️,” I’ve always encouraged teams to start running small experiments. Let’s write a hypothesis, create an experiment, try it, and see what happens. Maybe the team can identify a way of working that suits them even better!
“Let’s write a hypothesis and create an experiment, and let’s just give it a try and see what happens.”
A consequence might be that they don’t end up with Scrum anymore. Strictly speaking, you don't do Scrum when you don’t use a Product- and Sprint Goal. When you have multiple Product Owners for one product, it’s not Scrum. When you don’t use Sprints, it’s not Scrum.
If it works for the team, cool! Scrum should never be the goal in itself. 🎯
“Scrum should never be the goal in itself.”
I consider the desire to bend the rules of Scrum a personal invitation to investigate the team's state in more detail.
🧐 What is *actually* going on?
🧐 What problem are we trying to solve?
🧐 What problem are we ignoring?
🧐 What conversation should we have but currently don’t have?
🧐 Are we aware of the potential consequences?
Questions & observations I would like to explore with the team. But in the end, if they want to try new things, I’ll be their biggest supporter!
What’s your experience with cutting, bending, or changing the rules of Scrum? Are there rules or guidelines that are immutable or unmodifiable?