While specifying that Scrum teams should be both self-organizing and self-managing but, other than suggesting that the teams should be co-located and that they meet at least once a day in the daily Scrum meeting, there’s really nothing in the definition of Scrum that discusses how Scrum teams should build code. As a result, many Scrum teams, staffed by developers new to Agile Development, tend to follow old behaviors, creating a dysfunction so common that it has a name widely recognized by veterans in the field: “Scrummerfall.”

Scrummerfall sprints are characterized by waterfall-style development proceeding during a Sprint. Developers mostly work on their own after the initial analysis is completed, writing their code, writing tests, and (sometimes) writing the documentation that describes the code. It situations like this, only some of the collaborative and performance advantages of Scrum are realized.

Because backlog items and tasks are completed by an individual developer, tests cannot be created in tandem with the code, documentation cannot be written to match the code’s functioning precisely. The developer relies on his memory to write enough unit tests to properly test his code. He relies on his memory of how the code works to write detailed design specifications. Unfortunately, as that developer is pulled in a variety of directions that are the result of the normal workday (meetings, emails, phone calls, conversations with others), his memory provides ample opportunities for gaps and errors to find their way into both the tests and the resulting documentation.

In addition, because backlog items and tasks are being completed by an individual developer, there are reductions in:

1. Innovation – one proven truth in analysis and design is that two minds are better than one (and, three minds, more so). A single developer brings only his skills and experience to his work. But a group brings many perspectives that individually and combined create a much better result. An examples of this concept abound in nature and in human politics. Bees and ants, for example, work in concert with one another to build, gather food, and protect their colonies. The United States Declaration of Independence was drafted not by one man (as many believe) but by a committee of three with different perspectives and skills: John Adams, Benjamin Franklin, and Thomas Jefferson.
2. Focus and Motivation – working alone, a developer tires quickly, loses focus, and makes mistakes. This is compounded when they have to switch from one context (e.g., writing code) to another (e.g., writing documentation) and back. Working in a group provides multiple streams of simultaneous task focus, improved energy and stamina, and even, to some extent, increased peer pressure to perform at your best. Sports teams demonstrate this interaction better than any other example — all sports have commonly defined strategies for various situations that involve all members of the team, not just individuals. Baseball teams have coordinated defenses that account for the coverage of important positions when a player is forced to move out of his typical location on the field (e.g., a pitcher covering first base when the first baseman is pulled out of position by a bunt). American football fans are very familiar with the concepts of the “nickel defense” and goal line offenses. Fans of auto racing are probably very familiar with the “pit crew drill,” where all of the maintenance needs of a race car during a race are satisfied in seconds by a highly trained team.
3. Training – working alone, a developer ensures that he alone is familiar with the code when he is finished. If his documentation is poor or the code is substantially complex, there is no one who can step in to assist with the code should there be a need. When working in small teams, everyone gains some degree of familiarity with how the code works and why it was written the way it was.
4. Variations in Skills – working alone, the product of a developer will be strong in those skills where the developer is strong and weak in others. In other words, he may write exceptional code, only to follow up his coding prowess with nearly useless documentation due to poor writing skills. In a small team, overall skills are raised to the sum of all of the members of the team, thus achieving a much more effective balance.

Working alone, a developer will usually attempt to complete an entire backlog item before testing it, while a small group can write code and test it simultaneously, ensuring quality and functionality even before the backlog item is finished.

And finally, one more disadvantage frequently noticed in a “Scrummerfall” Sprint is that, just as with waterfall projects, final testing and quality assurance of a backlog item is pushed to the end of the Sprint, forcing testers and QA personnel to do a suboptimal job or risk being the apparent cause of the Scrum team not meeting it’s Sprint goals.

Swarming

When a Scrum team swarms, they overcome the disadvantages of individual workers by dividing into one or two smaller “swarms” (depending on the size of the Scrum team), picking a backlog item from the Sprint Backlog, and “swarming” together to decide how to get the backlog item done. Planning is done on a just-in-time basis, with members of the swarm collaborating and communicating constantly in order to find the most effective way to complete the backlog item and move on to the next. Over the course of the two to four days it may take to complete the backlog item, members of the swarm may switch with other members of the Scrum team as needed.

Ownership of tasks in a swarm is a minor concern, as any given task might be addressed by a single member of the swarm or multiple members of the swarm. As long as someone in the swarm takes responsibility for updating the task on the Sprint Backlog every day, task ownership is not an issue.

Let’s take a look at how a typical swarm might work a backlog item:

In our example, we’re going to complete a backlog item that adds “strong password” capabilities to a system’s authentication component, forcing users to create passwords that are difficult for would-be hackers to break.

Our swarm will consist of three Scrum team members: two coders and an analyst. Unfortunately, we won’t have a tester because the other swarm our Scrum formed needs the tester more.

• Day 1: Our swarm takes possession of the “strong password” backlog item. Our first concern is the final analysis and design of the enhancement, so we sit together somewhere and work out the details. We create a list of test cases to augment the acceptance criteria agreed upon during Sprint Planning. During this discussion, we also create several drawings on a whiteboard that we capture with a digital camera for use in the design specifications later. Late in the day, our swarm gets started on actually building the backlog item. One of the coders gets to work on the password validation routines. The second modifies the “change password” UI to add needed support to the screens. The analyst updates the related test documentation and begins writing testing scripts.
• Day 2: We start our day by testing out some basic passwords to see if the validation routines are working properly. This helps the swarm to identify a few more test cases and, as mistakes are found in the validation and improvements suggested for the UI, both coders make the changes immediately, updating and creating new unit and acceptance tests as needed. Working together, the proper specifications are updated at the same time as the code, keeping everything in perfect synchronization. By the end of the second day, the swarm decides that the UI changes are finished and the data validation routine is done.
• Day 3: Based on some discussion from the previous day, this day begins with the swarm updating the online help screens that support user account creation and the “change password” functions. In doing so, they discover a few more variations on their validation routines and quickly go through the paces to create test cases, test scripts, update and test the code, and update their specifications. As the end of the third day approaches, the swarm validates the completed deliverables (code, tests, documentation and specifications) against the DONEness criteria and the agreed-upon acceptance criteria. Satisfied that all are met, the swarm reports the backlog item as complete and turns their attention to the next item on the backlog.

As you can see by this example, the swarm doesn’t break up into their offices to work by themselves on tasks (that would be like hockey players skating randomly around the ice). Work emerges and is done collaboratively and team members do what is needed to complete the backlog item — sometimes they do what they’re best at, sometimes not.

The absence of a tester has no impact on how the swarm works (though its arguable that the swarm might create better tests with a tester than without). When tests need to be written, the swarm decides together who’s going to do it. A coder might write tests one day and then switch to writing code the next. On the third day, they might be writing documentation or specifications.

An analyst on the team might write test cases, write test scripts, update specifications, and work on learning more about a backlog item for the following Sprint — all in the same day.

Do team members always do what they are best at? No, of course not. Most Scrum teams don’t have the “perfect” mix of skill sets that alllows everyone to work on exactly what needs to be done at the exact time it needs to be done. However, it does mean that

• team members collaborate much more closely on backlog items, improving product quality and artifact quality.
• backlog items get done sooner, reducing the risk of failure as the end of the Sprint draws near.
• more people are aware of why a feature was designed the way it was.
• innovation is improved, as more “minds” are brought to bear on solving the problem posed by the backlog item.

Swarming helps a Scrum team develop in an Agile manner. It should be considered a “required” practice on all teams. Try it!