How Scrum 3.0 Became

The Most Agile Version

of Scrum

In 2001 a group of developers got together in Snowbird, Utah to talk about what they believed. The result was the Agile Manifesto:

Manifesto for Agile Software Development

�We are uncovering better ways of developing software by doing it and helping other do it.

�Through this work we have come to value

Individuals and Interactions over Processes and tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation

Responding to Change over Following a Plan

Three Great Things

For the Agile Software Community

1.It talked about values, rather than practices�allowed the conversations about agility to include both practices and people,

� allowed for discussions of interesting questions like

‘does RUP enforce agility, or merely allow it?’

‘Is it possible to have an agile waterfall process?’ and ……

2.It gave Preferences, rather than dogmatic guidance�allowed for a wide range of projects that could call themselves Agile,

depending on how they balanced the preferences.

�These practices could be a disparate as the Rational Unified Process (RUP), Dynamic Systems Development Method (DSDM), Kanban, eXtremeProgramming (XP), Scrum, and many more.

3.It firmly established the word ‘Agile’ as the generic term for this wide-ranging family of tools, teams, and Organizations.

Retrospective on 10 years of Agile Software

Development

They celebrated the success of the Agile approach to product development and reviewed the key impediments to building on that success.

They came to unanimous agreement on four key success factors for the next 10 years.

�Demand technical excellence

�Promote individual change and lead organizational change

�Organize knowledge and improve education

�Maximize value creation across the entire process

�Although agile software development had been around a long time, the Agile Manifesto is arguably the most significant milestone in the area of software agility.

Scrum VariantsScrum 1.0 - Scrum 2.0 - Scrum 3.0

�When Scrum was first developed in the 1990s, its elegance and simplicity were reveled.

�Software Product Development 1 thrived within this clearframework of single-source requirements.

�In many scenarios, this version of Scrum still works like a well-oiled machine.

�What if your reality doesn’t fit Scrum’s original concept?

�The newest white paper was writen Scrum 3.0.

� The paper gives real-world insight into the newest Scrum variant andleverage knowledge so that Scrum works better in reality.

Scrum 1.0

�The first implementations of Scrum had a Product Owner

�The Product Owner 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.

� This type of Scrum is referred as

Scrum 1.0

� This type of Scrum has been

around since 1998.

� One of its popular variants is

described in the Scrum Primer,

found at scrumprimer.org

Scrum Primer, scrumprimer.org.

Scrum Scrum Scrum Scrum 2.02.02.02.0

�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

Scrum 2.0

�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.

This type of Scrum is referred as Scrum 2.0,

Its most popularvariant is described in the Scrum Guide,

Scrum 3.0�What happens when the Scrum Team is in India, while the

primary Stakeholders are in New York?

�You need Product Ownership in both locations,

� one person can’t do it alone.

�This results as an another version of Scrum

�There is often a need for two Product Owner-types

� one with the Stakeholders to prioritize the new functionality (strategic prioritization)

� 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

Many organizations try to do Scrum 2.0 ending up actually doing this variant

• In the world of Agile frameworks, words matter even more.

• It’s far too easy for teams to build an Agile Tower of Babel, where everyone speaks

their version of Scrum, Kanban, Agile, Lean, or a Vulcan-like combination of all four.

• Valuable time is lost to defining terms and debating semantics, rather than developing

products.

• With no one on the same page, confusion is the common language and missed

collaborative opportunities are the unfortunate byproducts.

• Scrum Dictionary removes the lexicon noise and delivers a clear, concise definition of

Agile terms, complete with examples and related terminology, in a format that’s as

user-friendly as they come.