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 Scrum, 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.
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.
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
- Beedle, Mike, and Ken Schwaber. Agile Software Development with Scrum. Pearson, 2001. Accessed January 26, 2017.
- Sims, Chris, and Hillary Louise Johnson. “Scrum: a Primer.” Agile Atlas. Accessed January 26, 2017.
- “The Scrum Primer.” Scrum Primer. Accessed January 26, 2017.
- “The Scrum Guide™.” Scrum Guides. Accessed January 26, 2017.