A Brief History of Scrum
In 1993, a team of three developers at Easel Corporation, Jeff McKenna, Jeff Sutherland and John Scumniotales, decided to take a new approach to a critical software project. They were jazzed by ideas they’d encountered in a new book called Wicked Problems, Righteous Solutions, by Peter DeGrace and Leslie Hulet Stahl–who were themselves influenced by a famous 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game that described a product development team that would take “a holistic or ‘rugby’ approach-where a team tries to go the distance as a unit, passing the ball back and forth.” DeGrace and Hulet Stahl took the ideas that worked in Japanese product design and manufacturing and began looking for analogous cases in software development, describing several “all-at-once” systems that they proposed were superior to waterfall.
In a paper titled Agile Development: Lessons Learned from the First Scrum, Sutherland wrote, “The simplest all-at-once model is a single super-programmer creating and delivering an application from beginning to end. All aspects of the development process reside in one person’s head.” The obvious benefits being “good internal architectural consistency,” and the drawbacks being the lack of scalability and difficulty of knowledge transfer–who maintains the system once the super-programmer has left the building?
Sutherland and company set about designing a software development model that would let a close-knit team function as one, hoping to create a team with the powers of a three-headed super-programmer! They called it Scrum. Sutherland gives a detailed account of what followed, starting with the pitch meeting:
The CEO agreed that no plan ever delivered the required functionality on time. Many delays had been extensive and hurt the company financially… He had never seen a promised delivery date met, and worse, he rarely discovered slippage until it was too late to reforecast company revenue.
I told the CEO that in adopting Scrum, we set the objectives at the beginning of what Scrum refers to as a sprint. It is the team’s responsibility to determine how to best meet those objectives. During the sprint, no one can bother team members with requests. At the end of a sprint, I added, working code will be demonstrated, so you can see the progress made. You can decide to ship anytime or do another Sprint to get more functionality. Visible working code provides more confidence than extensive documentation with no operational system.
The CEO went for it, and six months later, the team delivered the product on time, with the confidence to offer customers a guarantee. They did it with daily stand-up meetings, regular sprint demos, and a smattering of practices now commonly known as Extreme Programming. Remarkably, the process Sutherland describes in great detail is virtually unchanged from what you are reading about in the rest of this book.
Meanwhile, Ken Schwaber was experiencing “breakthrough productivity” at his company, Advanced Development Methods, Inc. by using some of the same ideas from the Japanese manufacturing. Schwaber suspected that the secret to his success lay in his use of empirical processes (inspect and adapt), rather than defined processes (plan and execute), but he wanted a second opinion, so he asked scientists at DuPont’s Advanced Research Facility to give him a critical assessment of the industry standard for managing enterprise software projects with a (defined) waterfall process.
The DuPont scientists were aghast at what they deemed little more than pseudo-science: ‘We are most amazed that your industry treats these ill-formed processes as defined, and performs them without controls despite their irregular nature. If chemical processes that we don’t understand completely were handled in the same way, we would get very unpredictable results.’
Schwaber felt vindicated: a software project is too complex and chaotic to be managed via defined processes. The genius and agility of Sutherland’s super-programmer can’t be replicated through all the up front planning in the world.
Sutherland and Schwaber were past collaborators and were well aware of each other’s work, and collaborated on a 1995 paper for OOPSLA that formalized and made public the Scrum framework. The rest, as they say, is history.