Great Scrum Teams continuously improve their way of working. Sooner or later the team asks itself: Is this “allowed” in Scrum? Or: Is it “compatible”?
This is a decision that the Scrum Master should facilitate. But especially for new Scrum Masters this question is often a tough one.
The Scrum Guide says:
Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.
And:
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.
In short: Adding something is okay, removing not. But out in the wild its often not that easy. The answer is often: ”It depends.” It can help the team to ask itself the following three questions.
1. Does It Reduce Our Ability to Inspect and Adapt?
The power of Scrum and Agile is the ability to respond to changing conditions quickly. This is getting more useful in contexts with high uncertainty in means of requirements or technology.
With this in mind: Does the proposed change reduce the ability to inspect and adapt? Here some examples.
Reduces ability to inspect and adapt:
- Getting rid of
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
- Backlog Grooming
Why? Each of these events is a point to stop, check the current situation and react accordingly.
Increases ability to inspect and adapt:
- Collaboration with the Product Owner on a daily basis
- Invite users to user acceptance tests
- Test Driven Development
- Continuous Integration
Why? Each of those shortens the feedback cycle, so we have the information to act upon earlier.
2. Does It Serve the Scrum Framework or Adds It to Distraction?
The Scrum framework itself is lightweight and easy to understand. It should support the team in conducting their work as a team. By adding something to the framework, ask yourself: Will it serve the framework as a whole? Or will it add distraction? If distraction is added, the team may loose focus on what is most important: Deliver working software frequently to generate feedback. Here, too, some examples.
Does not serve the Scrum Framework, increases distraction:
- Complicated collaboration software
- No collocation or working remote
- Excessive customer integration can become a disturbance to developers
- Extending the timebox of the Daily Scrum
- Hand-offs (even within the team, ”Mini Waterfall”)
Does serve the Scrum Framework, reduces (or does not add to) distraction:
- Visible Definition of ”Done” beneath the task board: Clear focus on what’s ready or not.
- Sticky notes on the door indicating time and place of the Scrum events: No asking around, no calendar software that needs to be kept up to date.
- Poster with action items from the last retrospective beneath the coffee machine: Reminder for your commitments while you’re not focussed on the Sprint’s work.
- Colocation: No collaboration software to tinker with.
- Dedicated team room: Reduces organisational overhead and provides a save place.
- Deployment checklist: A step by step guide to deployment prevents headache.
3. If We Do It, When Will We Inspect and Adapt?
However, all this is specific for the team’s context at hand. If the Scrum Team decides to add or remove something to their way or working and it doesn’t violate any given constraints of sef-organisation, it can do so. But it’s their responsibility to take over responsibility for the change, inspect the results at a given time and adapt accordingly. So the last question would be: If we do it, when will we inspect and adapt?
