For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.

Disclaimer: Since this is a description for lay people, many of the Scrum details have been glossed over and oversimplified at times. As such, some of the words used here are actually incorrect, but correct enough for a lay understanding. If you want a full understanding of Scrum, then the only way to get that is to read the Scrum Guide and/or get certified in Scrum.


From the outside, the main goal of Scrum is to delight customers through early and continuous delivery of high value software. From the inside, at the software team level, Scrum is a software development process that empowers teams to self organize their work, while at the same time providing a framework for the team to self improve. Customers to Scrum Teams can be end users, internal users, marketing personnel, or any other person not on the Scrum team itself, who has a stake in the software that is being developed. Scrum is a process that works in short cycles, or mini-projects, of 2-4 weeks, with software deliveries that occur every 2-8 weeks. Each of these short cycles has multiple, built-in, Scrum feedback loops to maximize team and software product improvement.

The Name

The name Scrum was picked as a metaphor to symbolize the team effort in the sport of Rugby. This team effort is one where the entire team works closely together, all of the time, to move the ball down the field and score. The team is one where individual positions and specialties matter much less, and the overall team accomplishment matters much more.

Self Organization

In line with the Rugby "team effort" analogy, no one member of the Scrum team has authority over any other member. The game of Rugby moves far too fast to allow authority type roles calling out commands or plays -- so the team has to work together cooperatively in real time. This is referred to as self organization. While no team member has specific authority over another, there are three explicit roles that define specific responsibilities (these three roles are described in part two of this article -- see link below). One might think that self organizing teams might be prone to laziness, lack of direction, or gridlock, but Scrum Teams are still held accountable, as a team, by those (outside of the Scrum Team) who pay their salaries and/or fund their budgets. Self organization empowers the team to produce the best software using the most optimum processes and tools.

Framework for Optimization

Scrum is considered a framework more than a process, meaning that Scrum provides a strong framework of practices, but also leaves a lot of room for team customization and optimization within the framework. The optimization of the team and its software product mostly occurs at pre-defined feedback loops that occur every cycle. The Scrum framework is probably best defined by a document called The Scrum Guide, written by the creators of Scrum. While only roughly twenty pages, the document is extremely dense with principles, rules, and practices. As an aside, many people have successfully "lifted" Scrum concepts for use in places other than software development. While some of the concepts transfer readily, other concepts are hard to adapt to projects other than software development.

Empirical Process

Many previous software development processes(aka "Waterfall" based approaches) were modeled after large scale construction or manufacturing processes(such as ship building and assembly lines), which are defined processes. Defined processes are appropriate when the inputs and outputs are generally known and repeatable. Scrum is based on empirical processes like making custom made items (such as theatre costumes, scrapbooks, chemical manufacturing, or a custom built house), when the inputs and outputs are more complex, and not as perfectly defined or repeatable. Empirical processes are much more appropriate for these complex situations, including software development.

The Real Value of Scrum

Because Scrum is based on relatively short cycles that occur dozens of times a year, the Scrum Team has dozens of re-tooling points at which to improve, based on the built-in Scrum feedback loops. These feedback loops are what allow Scrum to be 3-10X more successful than Waterfall based approaches. Further, many Scrum teams experience much improved morale as team members have full authority over how they work, as well as full authority over how they explore new software approaches and technologies.

To go one level deeper into Scrum, see Scrum for Lay People Part 2 - Key Aspects of Scrum