Competition Within Cooperation

I am such a big fan of cooperation and collaboration that I sometimes forget other things are even more powerfulcompetition, to name one. The question is how to harness it so that the competition does not destroy the collaboration.

Darin Cummins^[1] found a way, as far as I can tell, and although he used it only twice, it points to a set of possibilities other teams might like to experiment with. He used the following "game" twice, which is a good sign, and decided that particular theme had run its course.

^[1] Of ADP Lightspeed, Inc. See "The Development Game" (Cummins 2002).

Darin cautions that the competition should not be about the code being written because the collusion, cheating, and destructive side of competition can ruin the code base or the team. Instead, he and the other managers created a competitive framework that reinforced development practices that they had selected. Interestingly, as the people on the team colluded to optimize their positions in the game, they actually carried out the practices and collaborated more than they otherwise would have. So "cheating" strengthened both the team and the practices.

Darin had read a Harvard Business Review article, "Everything I Know About Business I Learned from Monopoly" (Orbanes 2002). Orbanes lists six principles that make a great game and describes how they can be applied to business:

1. Make the rules simple and unambiguous.

2. Don't frustrate the casual player.

3. Establish a rhythm.

4. Focus on what's happening off the board.

5. Give people chances to come from behind.

6. Provide outlets for latent talents.

Darin applied those principles to improving his team's software development practices.

• He got his company executives to put real money into the pot.

• They bought gadgets that might interest the people on the team.

• They made fake money (with the VP's face on it!) to reward people for specific actions. See Figure 1.1-1 for a partial list of the rewards.

Figure 1.1-1. Some of the rewards for the Development Game (Cummins 2002).

Description	Reward
Creating unit tests/test plans	$20
Reviewing code for someone else	$30
Receiving an "Excellent" average rating in code review	$50
Receiving an "Acceptable" average rating in code review	$20
Receiving an "Unacceptable" average rating in code review	$20
Not having code reviewed	$50
Implementing suggestions from code review	$30
Warnings in build	$20
Errors causing build failure	$50
Errors in test after build	$30

As Darin writes:

"The developers get paid for having their code reviewed, reviewing someone else's code, completing tasks on schedule, reusing code, creating unit tests, etc. We also minimized the process as much as possible by getting rid of the huge checklist that was quite difficult to get the team to use and replacing it with a simple, 8-item checklist that is turned in at the end of each cycle. This checklist and a simple code review worksheet are used to help determine how much each 'player' gets paid . . .

"The management team also has the ability to award items not included on the list. For example, when we started having people come in late to our daily standup meeting, one of the managers chose to pay everyone $5 for being on time. The message was received and the problem became minimal. Players also have the ability to pay each other if they choose . . .

"One important principle that the game article discussed is giving the players the chance to come from behind in the endgame. This prevents a player from falling behind to the point where playing the game is hopeless and they lose interest. As we approached the end of the game, we devised some extra activities that could earn a developer more money."

What I found interesting was that the (inevitable) collusion improved the outcome for the team as a whole. People figured out that they would get points faster by trading code to review, and more code got reviewed!

At the end of the three-month game period, they held an auction in which the fake money was used to bid for the real items purchased. To make it more fun, they brought in a fast-talking salesman as auctioneer.

"The results from implementing the game have been far better than expected. The one result that we had hoped for in creating the game was to increase morale. While it wasn't intolerable, there were some bad attitudes and bickering beginning to surface. Left unchecked, I feared that these attitudes would escalate until the project and/or the team suffered. The game helped attitudes rise back to where they needed to be for us to be able to complete the project by giving an outlet and providing focus.

"The first unexpected thing we noticed was that the process now had a purpose. Everyone who has ever written code knows that software developers just want to be left alone to code. Logically, they know that the process is necessary, but emotionally the attitude is simply 'If you want it done, go away and leave me alone.' The game had the effect of not only giving them an emotional reason to accept the process, but to give it some excitement too."

The game worked for them, and they ran it a second time before deciding it would get old after too many uses.

After reading the article, I'm keeping my eyes open for other ways to use competition to improve (not damage) team quality and team output.