Scrum is just a recipe
It’s a very good recipe, but it’s nothing more than that.
There’s a lot of solid theory, research, and evidence behind Scrum and every ritual, practice, value, and goal in Scrum has been deliberately crafted, tested, and revised over the decades.
Yet like any recipe the outcome can’t be guaranteed, especially if you decide not to follow the recipe and have no idea how to cook.
Scrum is really quite simple. Some might say elegant in its simplicity. I often refer to Scrum as training wheels. Once you learn to cycle you can take the training wheels off, but until you do I strongly recommend you keep them on.
The Scrum Guide introduces the Daily Scrum as a 15-minute event for the team to inspect progress towards the Sprint Goal and adapt the Sprint Backlog as neccessary, and must produce an action plan for the next day of work. The benefits of the Daily Scrum include improved communication, identification of impediments, promotion of quick decision-making, and elimination of the need for other meetings.
The Scrum Guide prescribes this daily event because we know many teams struggle with communication, quick decision-making, too many meetings, unblocking stuck work, and losing focus.
High-performing teams who are great at communication, quick decision-making, routing around impediments, focusing on higher-level objectives with their work, and adapting their work plan in service of those higher-level objectives no longer need the Daily Scrum. They might even be ready to move beyond Scrum and take those training wheels off. Good for them!
But for teams who are not yet at that point it’s prudent to stick to those 15-minute daily events or risk drifting from their sprint goal, letting impediments linger unresolved, and doubling-up on work or letting work slip through the gaps due to poor communication and coordination.
Same with the Sprint Retrospective. If we believe that feedback loops, learning, continuous improvement and growth are important then we should welcome Scrum’s prescription of regularly taking time out to focus on continuous improvement. Teams who are already great at speaking up, identifying opportunities and challenges, and implementing change might not need Sprint Retrospectives.
Even the most controversial aspect of Scrum, the Sprint itself, is a mechanism for ensuring quality, reducing risk, protecting productivity, enabling adaptation, responsiveness not reactiveness, and navigating through complex problem spaces. Teams get caught up with questions about estimation and sizing, breaking epics into product backlog items, rolling work into the next Sprint. All of which are problems worth solving at some point but its important to remember that the Sprint is just there as scaffolding, to help us build up habits and ways of thinking about work and collaborating with stakeholders that ensures we don’t waste time and money endlessly writing yet more code instead of focusing on outcomes and impact.
Instead of just sitting around a table and talking Scrum expects a more proactive approach of hypotheses, experimentation and learning. We want to poke the system and see what wobbles. We want to take a few steps and then shine the torch around us to figure out where to go next. Because many problems are deceptively complex. Things look simple and straightforward when they’re not.
If your physiotherapist tells you to do a particular exercise, three sets of ten reps per day, four days per week then you stick to that program if you want to see rehabilitation, mobility, and strength otherwise you’re wasting your money.
Same with Scrum. It has no intrinsic value where just by saying the word you’re invoking some magical spell. It’s only through the intentional and disciplined application of it that over time your team will build strength and mobility after which you’re welcome to take off the training wheels and adapt the recipe to your tastes.
