I notice how many people struggle when they try to improve their understanding of Scrum. I notice it in classes, on forums, at conferences, through mail. They look for detailed instructions. They ask universal questions that demand exact and precise answers.
How long should Sprint Planning be? And the other meetings? How much time does the Product Owner role take? Is the Scrum Master role a full-time occupation? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? How many business analysts are needed in the team? What if... ?
Scrum is a tool. Useless unless employed. Scrum gets meaning through people employing it. Benefits are high when people self-organize around a problem, and use empiricism to make gradual progress.
The Scrum Guide purposely has no universally applicable, detailed instructions. The Scrum Guide describes how the tool works, the rules and roles that apply, not the tactics to apply the rules. Scrum, by design, offers room and breathing space. Scrum is a framework, not a methodology. The framework lays out the boundaries within which people can deal with complex situations, making sure people regularly match the actual state of their work against changed realities.
All exact decisions within those boundaries depend on context. Context is made up of people, tools, technology, business domain, organizational environment, market situation, and many other aspects.
What is the availability of people? Their skills, experience? How well do teams gel? How long have they been working together? How much multi-tasking does a team or team members have to do? How well are teams facilitated by the environment? What technology is being used? Which version? What engineering practices does a team have in place? What tools and infrastructure are at the teams’ disposal? How long are the Sprints? How is the connection with product management? What is the competition doing?
These elements, and the real-life complexity they represent, determine how Scrum is best employed, which way of playing Scrum is most suitable. The Sprint Retrospective is an event at which to re-think this. What works today might not work tomorrow.
My personal stance, as a trainer, a friend, a trusted advisor, a whatever in Scrum, is to facilitate people in understanding Scrum, the purpose of the rules and the roles. I consider it the only viable foundation to make sure people devise their own solutions employing Scrum. No external instance, expert or otherwise, can or should do that for them. It may be tempting, and highly convenient. It might make such a person appear knowledgeable. But it promises certainty where there isn’t. That is not helpful, but damaging and unprofessional. It ignores context and complexity. It ignores people’s intelligence and creativity.
I am extremely wary of being seen as an 'expert' providing universal solutions. I am an eternal novice.
Every case of Scrum is unique. There is no copy-paste. There are no universal truths.