One sense of “doing Scrum well” is following the process, following the rules. Do you have the 3 Scrum roles clearly defined? Do you do the 4 Scrum events, and do you do them in the way defined in the Scrum Guide? Etc.
Another sense of “doing Scrum well” is using Scrum as a tool to achieve outcomes that matter in a particular context. If you’ve been following us for a while, you know this is how we think about Scrum. It’s a tool. A very useful tool when applied mindfully to an appropriate context.
Don’t take this to mean we’re just advocating for throwing away pieces of Scrum that you don’t like or don’t understand. Ironically, this approach to Scrum requires paying more attention to the details of Scrum in order to be able to pay less attention to Scrum. It’s possible to go through the mechanics of a process without really understanding it. But to adapt it to a particular context well requires a deep understanding of why things are the way they are.
Let’s take the Sprint Retrospective as an example. Following the process sounds like a ScrumMaster saying, “Every two weeks we need to get together as a Scrum team and brainstorm what worked, what didn’t, and what new things we want to try.”
Understanding the Sprint Retrospective deeply enough to use it while sort of breaking the rules might sound like, “I notice the biggest impediment for our product team seems to be how we interact with the support team when customer issues come up mid-sprint. Let’s use this retrospective for a focused conversation with both our teams together to work out how we can interact more effectively.”
This week’s Humanizing Work Show episode takes on a question from a community member: “How much should we standardize across our organization? Is it important that our sprint lengths match, that we estimate the same way, that we use the same tools, that we report the same metrics, etc.?” The more deeply people in the organization understand tools like Scrum, the more room there can be for local variation—the same principles and goals applied in different ways for different contexts.
So, take the time to understand the purpose and mechanics of each part of something like Scrum. Then, experiment to find the best ways to achieve that purpose in a particular context. Maybe it looks just like the original design. Maybe you end up with a wildly different process that achieves the same goal even better.
Another Thought
In our ScrumMaster Community of Practice Zoom call this week, we tackled the question “How do you define success for a ScrumMaster?” One key success factor for ScrumMasters was related to the topic above, that the ScrumMaster uses Scrum in service of the team, not as the “Scrum Police.” A community member pointed out that that stance will often involve taking some kind of risk for the ScrumMaster, especially when tackling difficult organizational impediments.
We shared something that Scrum co-creator Ken Schwaber used to say: “A good scrum master will do anything to help their team, short of getting fired or arrested, since if they are fired or arrested, they are no longer a useful ScrumMaster for their team.” Sometimes you’ve got to shake things up a bit, and that can feel risky. But when done in service of the team, taking a risk to make change happen will increase the level of trust and connection with your team and set an example of being courageous to make good things happen.
Learn More
Last updated