By Peg Bogema, Stout Systems. Distributed by email February 16, 2010.

Let's start here. The word SCRUM comes from Rugby—a crazy game that to the uninitiated looks like soccer with tackling. In a SCRUM, some of the players from both teams are locked in what looks kind of like a football huddle. The ball goes into play right in the middle and the players try to kick it to their teammates. If you think of a huddle, you probably have the right visual image. But it’s considerably less gentle, since the players are fighting for the ball.

In software development, SCRUM is an agile development method.

The Wikipedia definition: Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

So how does the SCRUM method work?

There are three main groups of players in this method: the Product Owner, the Scrum Master and the Scrum Team.

The Product Owner

The Product Owner is the buck-stops-here person who can define what should be in a release. This role could be fulfilled by any number of people in a company. But the key point here is that the Product Owner has the final authority to say what is in and what is out. And then he or she protects the team from any changes in the content for the release.

Why this works: Done correctly, the team is assured that it will be left alone to get work done for a given period of time. The team is not standing on constantly shifting sands. In a structured development environment, this is already in place. But in an unstructured development environment, this is a life saver. The primary enemy of the software developer is the oh-by-the-way-we-have-a-market-opportunity-and-you-must-stop-everything-and-focus-on-this-until-tomorrow-when-there-is-a-new-market-opportunity…

Why it fails: When the Product Owner doesn’t really have the authority to select release content and hold the line on changes, this never works. So the Product Owner has to be granted real authority by the other stake holders in the company to make this work.

The Scrum Master

Most people think of the Scrum Master as being the project manager. That’s off in several ways. Let’s talk first about the fact that the Scrum Team is self-organizing.

One aspect of self-organizing is that the team determines how work should be distributed amongst personnel. Another aspect of self-organizing is that the team determines the order in which tasks should be completed within an iteration. So two roles of a project manager—planning the work and assigning the work—are handled by the team itself.

What does this leave for the Scrum Master to do? The Scrum Master fulfills two primary missions.

Mission One is to maintain the Scrum method. The Scrum Master keeps everything running in accordance with the tenants of the method. For instance, every morning there is a short meeting attended by everyone. Everyone answers three questions: What did I get done yesterday? What am I going to get done today? What impediments to I have to achieving my goals? The Scrum Master ensures that everyone on the team answers these questions, that the meeting is conducted standing up, that the meeting time is held down to a few minutes.

Mission Two is to handle impediments that were prevent the team from achieving its goals. These can be impediments mentioned at the morning meaning or other things that come up during the day. These can be issues that the team isn’t even aware of. The Scrum Master is really about facilitating production.

Why this works: When the Scrum Master knows his or her job, everything that would normally be the subject of numerous meetings, discussions, debates and emails is simply addressed and moved out of the way. Productivity stays high. Morale stays high.

Why it fails: When the Scrum Master confuses the role with project management, the team is denied the right to self-organize. Without self-organization, the team has less of an ownership stake in the outcome. They simply take orders. If things fail, it’s because the Scrum Master organized things to fail.

The Scrum Team

The Scrum Team consists of the developers and other personnel who do the actual work of delivering a software product. Scrum Teams tend to be cross-functional, meaning that members of the team tend to be able to do each others’ jobs. There is a training/mentoring component to the Scrum method in that the team can assign simple tasks to someone who isn’t skilled to do them and then train/mentor the person to get them done. This boosts the competence of the team overall. It also excites the team members because they are constantly learning (and becoming more valuable).

The Scrum Team is self-organizing. It sorts out who will do what and in what order.

Each iteration includes a feedback loop where the team can self-assess and then incorporate lessons learned on successes and failures.

Why this works: A Scrum Team is responsible for itself. Most Scrum Team members cherish working in an environment where they have significant input into how they perform their jobs. It makes them feel…uh…grown-up. And because they feel responsible, they go the extra mile to meet deadlines and solve problems.

Why it fails: When the Scrum Team consists of people who don’t work well in a self-organizing environment, the method breaks down. Some people are used to a hierarchical structure where they issue orders or take them. Adapting to Scrum isn’t always easy for them.


Iterative development is a buzzword that encompasses a lot of concepts. Iterations are short development cycles—maybe two weeks or four weeks. This is significantly different from other structured methods that can have a long development cycle of six months or a year.

The use of short iterations keeps the team focused on continually adding functionality and features to the product. These can be released at any time the Product Owner feels there is enough substance to share with the user community.

Using a short iteration time, if the Product Owner or the Scrum Team goes down the wrong path, no more than one iteration’s worth of time is wasted. Correcting course happens very rapidly.

The stake holders can change priorities very rapidly. If a market opportunity presents itself, the stake holders need only wait until the end of an iteration—four weeks at most—before starting down a new path.


That’s Scrum in a nutshell. If you’re interested, Ken Schwaber’s book Agile Project Management with Scrum is a great read. Light, entertaining, full of anecdotes. The method would be a great fit for many, many development shops.