Some years ago it became fashionable for managers to make light of their staff’s questions by asking, “What part of NO don’t you understand?” This catch phrase lasted until savvy people developed a pat answer. When asked “What part of NO don’t you understand?” smart people soon started to reply “the WHY part.”

Understanding the “why” part of anything is usually the key to mastering that thing. This is especially true of the Scrum Framework.

Developed by Ken Schwaber and Jeff Sutherland, the Scrum Framework has revolutionized the solving of complex problems for those who have mastered it. When applied in the field of software development, Scrum results in astounding improvements in product quality, developer productivity, and time-to-market speed.

As described by Schwaber and Sutherland in The Scrum Guide , ¹ Scrum is lightweight, simple to understand, difficult to master. Scrum presents a framework of simple roles, artifacts, and events that can be applied in any situation in which there is more that is not known about a problem than there is that is known. Scrum organizes activities into processes in which results are discovered rather than predicted. The net effect is to allow everyone involved to focus on the correct tasks at the correct times to produce superior outcomes quickly and efficiently.

The Scrum Framework itself is magnificently simple and elegant. As housed in The Scrum Guide , the entire Scrum body of knowledge is only 19 pages long. There are three roles (Product Owner, Developer, and Scrum Master), three artifacts (Product Backlog, Sprint Backlog and Sprint Increment), and five events (Sprint, Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective). The entirety of the Scrum Framework can be reviewed in a matter of minutes.

Learning to apply the Scrum Framework, however, can take much longer.

Someone with a traditional project management background will find parts of Scrum to be familiar and parts of it to be a little strange. The idea of daily “stand-up” meetings is easily grasped as a form of status reporting. Organizing work into sprints with periodic “demo” events is easily “recognized” as a milestone tracking mechanism. These two parts of the Scrum Framework are usually the first ones to be implemented by a non-Scrum shop that wants to become “scrummy.”

Other parts of the Scrum Framework present more of a challenge to the credulity of a traditional project management professional. Requiring that teams of developers manage themselves can seem like a utopian counterculture fantasy. Embarking on a major software development project without a concrete plan seems like folly. Having a “Scrum master” instead of a project manager makes little sense, especially when this “master” turns out to be a servant leader who is the master of no one.

The Scrum Framework was created by hard-headed realists who understood how software is created in the real world. Every part of it depends on every other part. As the authors of The Scrum Guide state within it, it is possible to “pick and choose” among the elements of Scrum, but the result will not be Scrum unless the framework is embraced and adopted in its entirety.

There is a hard-headed, practical reason for including every component of the Scrum Framework. Even the ones that seem strange and/or radical have a reason for being part of it. Leaving bits and pieces out of the mix will have adverse consequences.

There are plenty of books on the general subject of “How Scrum Works.” Many sources are available to describe the three roles, three artifacts, and five events.

This book explains “Why Scrum Works.” It explains why there are three roles, why there are three artifacts, and why there are five events. It sheds light on the reasons behind the Scrum Framework’s characteristics, especially the strange and controversial ones, so that adopters can avoid the temptation to pick and choose.

Each characteristic of the Scrum Framework serves a purpose. This book explains what those purposes are.

Only by understanding the purposes behind each part of the Scrum Framework can rational choices be made about customizing it. If one part of the Framework is dropped, something else should be put in place to serve the underlying purpose behind it.

The Scrum Framework is magnificently simple, yet its scope is profound. My hope is that the work of Ken Schwaber and Jeff Sutherland will come into clearer focus when practitioners understand not only “how” but “why” Scrum works.