Scrum is a beautiful concept. When it was first developed in the 1990s, we reveled in its elegance and simplicity. Software Product Development1 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 white paper, Scrum 3.0. – 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 Scrum 3.0:
Scrum 1.0 Overview
The first implementations of Scrum2,3 had a Product Owner who was outside the Team — often on the “Business Side” of the Organization. This Product Owner prioritized requirements, at the beginning of a Sprint, at a fairly-high functional level, and then basically left the Team alone to develop – the Product Owner was only agile at the Sprint boundaries. This style works well for Software Product Development when the functional Requirements are emergent and not overly volatile. This type of Scrum is still around, still being useful.
We refer to this type of Scrum as Scrum 1.0, and has been around since 1998. One of its popular variants is described in the Scrum Primer, found at scrumprimer.org.4
Scrum 2.0 Overview
But, 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 Scrum 2.0, and its most popular variant is described in the Scrum Guide, found at scrumguides.org.5
Scrum 3.0 Overview
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.
What do Scrum 3.0 Roles, Artifacts,
and Process look like?
How do you implement the most Agile, clean, and flexible version of Scrum to be found?
Pre-order Scrum 3.0 now and be the first to find out.
As Always, Stay Agile.
Notes, and Sources
6 The Well-Formed Team™ white paper