Scrum is an idea.
The word ‘Scrum’ comes from the game of Rugby: a whole team working together; their singular mission is to move the ball down the field.
The idea grows out of a few important truths about team development and product quality:
- Self-organizing teams produce the best architectures and designs.
- Especially with fast feedback loops between the people developing the product and the people who use the product.
- And frequent delivery of small batches of high-quality code is the best go-to-market strategy in a fast-evolving market and is the best risk-mitigation strategy in a complex problem environment.
I think of Scrum like a set of agreements that a team can adopt: we agree to focus to the best of our ability; to be open about our challenges and act with courage to work through them; committed to the goals of the team; respectful of each other and our situation; and we agree to work together — like that Rubgy team — toward long-term goals in increments! That means, rather than plan and build and launch a product over the period of, say, a year, we plan and build and release usable increments of that product in cycles of a month or less.
A Scrum Team’s calendar includes repeated cycles of planning, release, retrospective.
A Scrum Team’s stakeholders can clearly understand what needs doing, what is being done, and what is already done and in the hands of end users.
A Scrum Team’s job titles include all the necessary skills to create the product: that might be design, marketing, coding, testing, copyrighting, data science, all of it. But in particular, there’s one person trusted to decide the order in which features will be released and others who are trusted to achieve a high quality work environment and high-value, user-centric features.
Scrum isn’t easy. Actually, it’s rarely achieved. Many companies claim to be “doing Scrum” but most struggle because it’s so different than the conventional, bureaucratic ways of working.
When I teach people about Scrum I want them to understand more than just the parts of the Scrum framework, but understand why the framework is designed the way it is so they are best equipped to apply (or adapt) the idea in their own work and with their own teams.
Closing
What’s your take on this? Is your experience similar to mine?
If you’re interested in learning more from me, visit my site and contact me to explore the opportunities for your organization.
Join me for a Scrum.org course: scrum.works/classes
And consider adding my recent book to your library: davidsabine.ca/phoenix