The Scrum Handbook brings to life the best form of Scrum we have found. Scrum is a beautiful concept. When it was first developed in the 1990s, we reveled in its elegance and simplicity. Software Product Development thrived within this clear framework of single-source requirements. And, in many scenarios, this version of Scrum still works like a well-oiled machine. Until it doesn’t.
What if your reality doesn’t fit Scrum’s original concept? Then what? That’s why we wrote our newest book set, The Scrum Handbooks. – to give real-world insight into the newest Scrum variant and leverage your knowledge so that Scrum works better in your reality.
The following is an excerpt from The Scrum Handbooks:
There is often the need for the Team to not only build software, but maintain the software once it has been deployed. This requires the Team to be interrupted frequently in order to resolve time-sensitive issues relate to bugs, building, testing or deployment that come up in Operations. The Team needs to know: “Which is more important, the new functionality we’re already working on, or the new work that just came up?” — and this is a decision the Product Owner needs to make right now – the Product Owner needs to be agile all the time. The “Business Side” Product Owner is often incapable of making these decisions in a timely manner, and Scrum’s response to this problem was to move the Product Owner onto the Team in order to be available full-time to the Team in order to prioritize these interrupts real-time.
We refer to this type of Scrum as older Scrum 2.0 (see The 9 Scrum Zones for a reference also found in the appendix of The Scrum Handbooks), and its most popular variant is described in The (Annotated) Scrum Guidebook, a copy can be found at scrumguide.org.
But, what happens when the Scrum Team is in India, while the primary Stakeholders are in New York? You need Product Ownership in both locations, and one person can’t do it alone. So, for this and other reasons, there is another version of Scrum that realizes that there is often a need for two Product Owner-types, one with the Stakeholders to prioritize the new functionality (strategic prioritization), and one with the Scrum Team to prioritize the work (tactical prioritization). This kind of Product Ownership is distributed and agile all the time. This is a common variant of Scrum in the real-world, and is what many Organizations who try to do Scrum 2.0 end up actually doing.
We refer to this type of Scrum as The Scrum Handbooks (STS + MTS) and it can be very successful when implemented properly.
What do The Scrum Handbooks Roles, Artifacts,
and Process look like?
How do you implement the most Agile, clean, and flexible version of Scrum to be found?
Visit ScrumGuide.org (SGO) now and find out.
As Always, Stay Agile.