Using Scrum to create high-performance teams

If you could increase productivity of your teams by 200% to 1,000%, would you be interested in achieving that?

In the field of software development, "Scrum" is not an acronym, but rather a reference to the game of rugby where a group of men have a polite conversation about the ownership of an oblong ball. What are those practices? And why are they so productive?

There is a set of roles which include the ScrumMaster who maintains the processes and works to create a space for the team, to help the team improve its practices, to protect the team from outside interference, and to maintain contact with clients and their representatives, the Product Owner who represents the stakeholders, and the self-organizing, self-managing Team which includes the developers.

During each 15-30 day period, called a sprint, the team creates a piece of usable software, whose features come from a prioritized set of high level requirements of the work that needs to be be done.

"Done" has a special meaning in Scrum. "Work in progress" is not done. A "prototype" is not done. A set of PowerPoint slides describing what has been accomplished is not done. "Done" means that a segment of code has been completed, tested, documented, can be demonstrated to the Product Owner and is ready to be shipped. One object of Scrum is to reduce "work in progress" to a minimum, since it is the equivalent of a "inventory" in lean manufacturing. "Work in progress" is seen as a problem, not a solution. The work is divided into segments, and the "sprint" aims at getting each segment "done" as fast as possible.

It is the task of the scrum master to make sure that when an individual or the team says that a piece of work is done, it is in fact really "done".

Scrum is carried with self-organizing teams. It encourages co-location of all team members to the extent possible, and verbal communication across all team members and disciplines that are involved in the project.

The team works off a prioritized list of requirements, which is constantly reviewed by the Product Owner. The list can be as long as one likes. What is important is to focus on the top priority work and to get that "done" as quickly as possible.

The team itself decides which segments are to be tackled in which order. The team itself decides how the work should be done. There is tremendous leeway in how they do the work, but also tremendous rigor on getting the work really done and on time.

In one sense, Scrum is very easy to learn and requires little effort to start using. In another sense, Scrum is very difficult to implement successfully. Scwaber estimates that only 35% of firms attempting it succeed. That's because it requires total transparency on a daily basis as to how much of the work is actually getting done by each member of the team. It seems that most firms can't take the bad news that such transparency often generates.

A fascinating question is: could the practices of Scrum be applied more broadly to high-performance teams?