There is nothing more dangerous in the game of Rugby Union than the collapsed scrum. Think of it. Eight hunking great forwards (many sporting flattened noses and cauliflower ears that advertise their experience of scrums) on one team collide, head on, with an equal number of monstrously-sized opponents from the other team in an attempt to get control of the ball. If the initial engagement is not carefully synchronized by the referee then the scrum can collapse, potentially causing serious injury to one or more of the participants.
Collapsed Scrum is bad news in Agile product development too. Thankfully it is rarely Scrum team members who get injured. But the product is certainly at risk, and perhaps even the agile adoption initiative. Its immediate consequence is the failure to deliver the results expected.
Nature of the Problem
What causes collapsed Scrum? As in the game of Rugby it is often the initial set up which triggers the problem. Either through misinterpretation of the rules, or an unwillingness to follow them, the Scrum team is created without the appropriate roles, responsibilities or events needed to properly implement the fast feedback cycles and inspect-and-adapt behaviors that drive success.
Here are some of the classic symptoms of a likely-to-fall-down Scrum initiative:
Laws of the Game
In Rugby Union, the International Rugby Board is responsible for the laws of the game. Fear of the collapsed scrum has probably caused more changes in the laws than any other consideration. A minimal set of rules for the Scrum framework would work wonders. It might be the single thing that could have the biggest impact in getting Agile projects set up properly for success. The literature of Scrum stretches back nearly twenty years. Some of the most well-known books contain out-of-date information that does not reflect the learning gained from its explosive implementation in the last five years or so especially. At the same time, cross-pollination from other Agile frameworks and methods- a good thing in itself- may have diluted the essential message.
Well, the good news is that such a minimal set of rules now exists. It is called The Scrum GuideTM , and is subtitled “the rules of the game”. In fact it has been around since February 2010 when it was first authored by Jeff Sutherland and Ken Schwaber (1) – the two guys most often referred to as the founders of the Scrum framework for software. The Guide is actually now in its third edition (first published in July 2013), and in fact has been distributed to attendees on Learning Tree’s Agile Project Management with Scrum course since its initial publication, and on all their agile courses for some time now. But on September 24th this year Scrum Alliance, scrum.org and scrum inc jointly announced adoption of The Scrum GuideTM and the creation of a new community website . The Guide, and the website which is its official source, is now recognized by the whole Agile movement as the canonical definition of the Scrum framework. As Jeff Sutherland put it, this “will provide clarity to the hundreds of thousands of Scrum practitioners across the planet” (2).
I have often summarized the scrum framework as 3-4-5 (3). It is a framework for self-managing teams involved in the development of complex products. There are:
The Scrum GuideTM describes each of these and the relationships between them. The rules are mandatory for anyone claiming to be using the framework. They are the minimal ones that are essential for it to work properly. They are few because The Guide leaves the maximum room for teams to decide how they will execute their work and deliver business value to their customer. The Scrum framework is not a process. The “process” is the totality of the decisions taken by the self-managing team. It does not guarantee agility.
How agile a team will be rests on the outcomes of the decisions the team makes. There are observable patterns that increase the likelihood of success (we will discuss Scrum patterns in future posts), but Scrum can never guarantee success. Its only guarantee is that it will surface every single impediment in an organization’s product development process – leaving the organization with the choice of whether or not to remove that impediment.
The Scrum GuideTM cannot guarantee success either. But application of the rules should mean, that whatever any other reason there might be for a failure, it won’t be because of “collapsed scrum”.
(1) See my posts on The Evolution of The Scrum Guide for an explanation of the differences between the three versions. http://www.emerald-hill.co.uk/emerald-hill-blog/entry/the-evolution-of-the-scrum-guide-part-one
(2) View Learning Tree’s curriculum of 17 Agile with Scrum & Software Development courses.
(3) Press Release. “Scrum Organizations Announce Official Collaborative Adoption of Scrum Guide” Scrum Alliance, scrum inc., scrum.org. September 24, 2014
(4) “What is Scrum?: A 4-Minute Overview”. http://www.emerald-hill.co.uk/resources-for-agile-development