Mastering Scrum
This book is ultimately about mastering Scrum practices and doing so at an enterprise scale. But I don't want to assume that you already know a lot about this approach to agile software development. If you believe you have a sound understanding of Scrum concepts, feel free to move on to the other chapters in this book. However, if you are relatively new to Scrum, I would recommend that you continue reading these two introductory chapters.
The content in this chapter and the next chapter align with the concepts presented in The Scrum Guide (project to product, and from following life cycle processes to producing increments of customer-centric value.
Scrum evolved to implement the values and principles of Agile within software development projects. However, Scrum is a generalized approach to Agile that supports any number of business improvement applications. Though the Scrum Guide mentions its software development heritage, given its broader scope, interestingly, the Scrum Guide does not explicitly discuss how to apply Scrum in a software or systems development context.
The next three subsections introduce the basics of Scrum as a sports-based metaphor, its application in a software development context, and how it became the de-facto standard. As a person who loves all types of sports, let's start with the sports metaphor.
Applying a sports metaphor
The term Scrum came from a paper titled The New New Product Development Game, written by Hirotaka Takeuchi and Ikujiro Nonaka. Their paper introduced Scrum as a rugby-based metaphor for coordinated team play in manufacturing-related business. The basic idea behind a rugby scrum is that a team of individuals work together with a collaborative goal to take possession of the ball, across multiple iterations of play, and move it forward to score more points than their competitors.
After assessing some of the world's most successful businesses, Taguchi and Nonaka concluded that the best companies had moved away from the traditional plan-driven and linear sequential life cycle development processes. Instead, the more successful manufacturing companies employed teamwork, much like the rugby scrum teams, by employing radically different concepts, such as the following:
Broadly defined corporate goals, as opposed to detailed product and project plans.
Self-organizing product-oriented teams, as opposed to functional roles and responsibilities.
Team independence, as opposed to top-down enforcement of policies and procedures.
Continuous improvements in pursuit of excellence, as opposed to operational permanence.
The employment of integrated and fully functioning product teams, as opposed to assignments of people across disparate functional departments.
Concurrent phases of work, as opposed to linear sequential life cycle development processes.
Multi-learning, as opposed to individuals having a single role and limited cross-functional skills.
Organization-wide knowledge transference, as opposed to siloed organizations.
Scrumming in a software development context
A decade later, in the mid-1990s, Ken Schwaber and Jeff Sutherland applied Taguchi and Nonaka's principles to software development, along with their concepts of empirical process control theory – also known as empiricism. Sutherland and Schwaber collaborated and presented a joint paper, titled Scrum Development Process, at the Business Object Design and Implementation Workshops held as part of the Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) event in Austin, Texas. (Sutherland, Victor, Schwaber, 1995)
I was interested to know how Jeff and Ken started working together, so I reached out to Jeff Sutherland to ask him, and this is what he told me:
"In 1993, my team at Easel Corp. formalized Scrum as we know it today. We did 2 years of monthly releases with a product that Computer World said was the best they had ever seen.
In 1995, we were acquired by VMARK. I had worked with Ken on waterfall projects at a banking software company. He was CEO of a waterfall Project Management methodology company. I invited him up to VMARK to look at Scrum. I wanted to get the intellectual property out into the public domain.
I said, 'Ken, you should be selling Scrum, not waterfall, as it works and waterfall doesn't.' He spent 2 weeks embedded with the first Scrum Team and agreed that it would be better to sell Scrum. We agreed on the ground rules. It would be open-source, and we would write a paper for presentation at my annual workshop at OOPSLA'95. Ken began selling Scrum in the industry while I was implementing Scrum in multiple companies as CTO.
Ken worked with me as a consultant in all my companies, so we evolved Scrum together and showed up at the Agile Manifesto meeting in 2001. The rest is history."
Becoming the de facto standard
By and large, Scrum is the de facto standard today in agile practices. For example, according to the CollabNet | VersionOne 13th Annual State of Agile Survey, 72% of their respondents reported they were practicing Scrum or a hybrid that includes Scrum. (CollabNet | VersionOne, 2019)
I believe long-term project managers – if they were openly honest – could quickly identify some of the deficiencies associated with developing software under the traditional plan-driven and linear sequential development model. The following are some examples:
Customers almost always think they have given you their requirements when, in reality, they have only given you a list of high-level deliverables in their charter or negotiated agreements.
Contract agreements too often focus on identifying expected work tasks and deliverables and ways that the contractor will prove their performance against the specified tasks and deliverables.
Customers and end-users almost always find better or new ways to use a product only after they have seen a prototype or a working release.
Product developers are always the best people to define and estimate project-related work.
Software coding takes a relatively minimal amount of time across the project's duration.
Conversely, testing and debugging often takes up the most time in a project.
The more requirements that are added to the project plan, the longer testing and debugging will take.
As we go through this chapter, we will find out how Scrum either addresses or leverages the preceding list of facts to help achieve a more positive outcome when contrasted with the traditional development model. In the next subsection, we are going to start on this journey by understanding that the implementation of Scrum requires executive-level sponsorship.