Foreword

It seems like it's all the rage to abandon the Scrum mother ship. Some (any number of LinkedIn pundits) create click bait pronounce it dead and propose successors. Some want to start over with a new spec, as we find in A Simple Guide to Scrum or as telegraphed by Scrum Team Magazine. From one perspective, one is tempted to also throw one's hat into the ring so as not to be left out. But from another perpsective, we've seen this movie before, and each scene is increasingly removed from the precious insights that were there at its beginnings. We're about to lose a generation of insight to populism, to a striving to be AI-relevant, and to consultants' natural predilection for novelty. Saying something that no one else is saying drums up business, but it comes at the cost of turning Scrum into common mud. Ignorance is about to win the battle of marketing versus knowledge.

Scrum started as a relatively simple way for developer to create, design and deploy innovative products in a field of high uncertainty. It worked because it built on well-known enablers of innovation: collocation, teams with small, diverse memberships, and no fear of retribution from "mistakes." By 2000, it had evolved into a project management approach with an up-front requirements phase, a handoff to developers, the creation of a design artefact, followed by development, and a quality assurance activity. The Sprint was a project; Scrum was effectively several projects run end-to-end. Releases were decoupled from Sprints The Retrospective came as an afterthought in about 2003, albeit a good one. As these obvious parallels to waterfall came under attack, some of the boundaries and approaches were softened. Backlog refinement, added as a folklorish "tip" rather than a stipulation, dampened the handoff nature of the front-end. We were told not to think of the Sprint Review as system test or as a handoff to end users as Scrum started to admit continual delivery in 2017. But these were epicycles, and the overall initial shape continues to drive much behavior in the wild.

This page presents one train of thought that motivated this web site. In short, Scrum has grown from a certainly powerful, small set of ideas into a cookie-cutter method. While mature developers know that it is a learning framework rather than a set of practices to follow, such maturity is rare. Even some practices at this point in Scrum's evolution, such as having a backlog, are no more remarkable than a cook having a shopping list; cooks are probably not taught to make shopping lists when learning to becomes chefs. As such, these trappings are not germane to what distinguishes Scrum in the pantheon of development approaches and as such don't seem to belong in a Guide.

There seems to be broad unease with the current state of the standing Scrum Guide. Scrum Team Magazine is calling for a new Scrum guide. There is a Simple Scrum Guide that is basically a super-condensed version of the current official Scrum Guide, but which omits the most fundamental Scrum notion of one-by-one construction.

The effort at this web site is an attempt to peel back the additions over the years, and to help ourselves reflect on what Scrum really is. It's clear from the public dialogue on the social networks that we've forgotten.

These pages aren't trying to sell you anything. They may be trying to ask you to consider if it might not be true that less is more — before we go into another cycle of adding yet another layer.

Etymology of "Scrum"

The term Scrum comes from the early-19th century scrummage, which was a variation on scrimmage: a term conveying disorder and high energy. It landed as the name of a formation in Rugby which is that sport's analogue to a jump ball in basketball. It is characterized by "an ordered formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward against a similar group from the opposing side [1]."

From "just a word" to a practice

The term was introduced into project management by the researchers Takeuchi-san and Nonaka-sensei in a paper they published about a spectrum of development management styles they observed in a range of companies in several fields. [2] They noticed that in innovative projects, like the Canon Sure-Shot, that "The process resembles a rugby game where phases bleed into one another rather than waiting for one gate to close before the next opens." Nonaka-sensei sought an image that conveyed the kind of overlapping between people that they had observed between phases of effective development in fields with a high number of unknowns, and settled on the rugby Scrum as the metaphor. [3]

Software development, as a complex endeavor, seemed a natural fit for what Takeuchi and Nonaka had found. Peter Degrace and Leslie Hulet Stahl described an adaptation of the approach to software development in their 1990 book, devoting an entire chapter to it. [4J  Jim Coplien noticed this same enabling behavior in his broad development process studies in the early 1990s. [5] Selic et al. featured overlapping development phases in their ROOM methodology, published around 1994 [6]

Ken Schwaber  would present Scrum at a workshop at OOPSA '95 in Austin, Texas, and would publish the paper in 1997.¹  [7] By 2001 he had started organizing the Scrum Alliance and Scrum became formalized as part of a certification process. However, no Scrum body of knowledge yet existed, so work started on a Scrum Guide around 2008. It was published by the Scrum Alliance in 2009 as the certification standard.

Takeuchi and Nonaka's original Scrum paper heralded overlapping development phases as the distinguishing factor in the success of developing complex products in a large field of unknowns. It was about "going the limit" and breaking the rules. A single team stayed together through all phases, eliminating handoffs. Teams are not only cross-functional, but "each team member feels responsible for—and is able to work on—any aspect of the project." [2] There are no stipulations of events, artefacts or processes, but the focus is instead on team membership, end-user engagement by engineers, group-based rewards, forgiving "mistakes," and increased supplier autonomy.

Schwaber's original Scrum articulation in 1997 was also quite lean: just a planning phase to feed a backlog; a series of "Sprints" where work followed Takeuchi and Nonaka's description, with a review at the end; and a closure phase. The Scrum Master and Product Owner, Sprint Retrospective, Sprint Backlog, and Daily Scrum would all come later. The trappings of the three roles, five events and three artefacts would come only in the formalization, around 2001, leading up to Scrum Alliance certification. The formalization would be more concretely formalized in about 2005 with the advent of exam-based certification, and almost all of the contemporary organs were present in the 2009 Scrum Guide.

Back to the Future

There is good reason to challenge the layers that Schwaber's paper added in 1997 and that the commercialization of Scrum added between 2001 and 2005. Together with these, there have been notable omissions and clouding of the initial ideas.

First, teams were having great successes without the guidance of the extra components: the teams studied by Takeuchi and Nonaka; the well-known Borland QPW effort studied by Coplien and cited by Schwaber in his 1997 as being exemplary of what he was presenting² — before his ideas were published.

Second, the Scrum Guide tends to over-specify the obvious. Let's say that there were an alternative Scrum Guide that said, "The team should have no backlog to order planned work." Most people — both inside and outside the Scrum fold — would find this wrong if not ridiculous. It is second nature for people to manage upcoming work in lists, particularly at the scale of items and time of complex product development. To prescribe and name the list is to constrain away the possibly fruitful variants and alternatives that are the stock and trade of agile thinking. It would be one thing if such trappings were backed by research, but there is no evidence that any body of knowledge drove the inclusion of the Product Backlog in the standard.

The same is true for the Daily Scrum. Nursing teams and construction teams and, yes, software teams, had formalized such events for their own workplaces long before any standard included it.

Furthermore, most members of teams under the guidance of The Scrum Guide failed to understand basic concepts like the Daily Scrum, the Product Backlog, and "swarming" —  the single-piece flow within a team. [8] If they failed to understand them it's pretty clear that they were "doing Scrum" without them, so any claims about contemporary prowess of Scrum should be greatly tempered and instead referred to as owing to some kind of "Scrum-butt."

Third, the existing Scrum Guide refers to swarming only in a very indirect way that avoids its essence. It says only that there may be no subteams within a Scrum team. This may be of little consequence were it no for the fact that swarming is the core, key benefit described in the Takeuchi and Nonaka paper. Many hold up that paper as being the origin of Scrum, but it is likely that only a few of those same people know that the paper is fundamentally about swarming. The popular opinion is that it is about sprinting or about speed.

So on one hand, standardization efforts have flown in the face of Occam's Razor to the point where the standard Scrum Guide cannot be reduced to fewer than fifteen concepts without information lost. The A Simple Guide to Scrum tries to minimize page count but all fifteen concepts are still there; it's just that they are presented with lower fidelity at best. On the core concept of swarming has been completely edited away from the Simple guide, and can be found in the scrumguides.org guide only if you know it is there.

A new beginning...

Sadly, probably not. The force of bodies that have a vested interest in the status quo benefit from the bloat of the standards, and on the simplisticness of their content. The good drives out the perfect.

Why, then, does this site exist? First, to put a signpost in history that recalls the past and demarcates the point of erosion to the new future. Second, it can be a lighthouse to guide those who choose to rise above the crowd with true kaizen mind, look around, and seriously evaluate — with their soul — how to improve. What is presented here isn't good because it is original or old, but perhaps because it is an uncompromising key to complex system development that has helped fuel the world's #1 car company to success. It is a reminder of what we once believed and cherished, and a testimony to the human spirit's ability to conceive great things. A few may follow, and that is enough for the principled and unambitious.

— Jim Coplien

¹ Schwaber's work by the way, cited the work of [5] and included [4] in its reference list, without any in-text callout of the reference or explanation.

² It is perhaps interesting that the QPW project designate as an example of Scrumby Schwaber was having Daily Meetings, which were not yet part of the governance Schwaber described in his paper.

[1] New Oxford American Dictionary, s.v. "scrum"

[2] Takeuchi, Hirotaka, and Ikujiro Nonaka, "The New New Product Development Game." Harvard Business Review, January 1986

[3] Personal conversation between Ikujiro Nonaka and Jim Coplien, Tokyo, Japan, 16 January 2013

[4]  Degrace, Peter and Leslie Hulet Stahl. Wicked problems righteous solutions: A Catologue of Modern Engineering Paradigms. Pretince-Hall, 1990.

[5] Brendan G. Cain and James O. Coplien. A Role-Based Empirical Process Modeling Environment. In Proceedings of Second International Conference on the Software Process (ICSP-2), pages 125-133, February 1993. Los Alamitos, California, IEEE Computer Press.

[6] Selic, Bran, Garth Gullekson, and Paul T. Ward. Real-Time Object Oriented Modeling. Wiley, 1994.

[7] Schwaber, Ken. SCRUM Development Process. 1997. DOI:10.1007/978-1-4471-0947-1_11.

[8] Coplien, James. "So you think you know Scrum?" Regional Scrum Gathering, Beograd, Serbia, 7 Nov 2025.