Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

The Development Game


October 2002/The Development Game


Although undoubtedly worth the effort, transitioning an existing software project from a heavy development process towards a more Agile methodology is a painstaking and difficult process at best. The least painful way of making the transition is to make the change immediate and complete. However, most teams cannot, for one reason or other, make the transition over night. Here is one idea that helped our team make the transition less painful.

Our transition took place during development of a large system with a team of 14 developers. Unfortunately, but not unexpectedly, as the project progressed it became clear that we were going to miss our deadline by an ever-increasing margin. The pressure began to rise, tension increased, and the developers began focusing more on just getting the coding done and less on the requirements of the process. Code reviews were not being done, project tracking became a nightmare, etc. With our legacy mindset, and based on the heavy process we were using, we began to add more checklists and schedule code review meetings in an attempt to bring things under control. This, in turn, simply added to the stress and made things worse.

Agile Processes

In the early stages of this project, I became familiar with the Salt Lake Agile Group and began attending their monthly roundtable meetings. As I became more acquainted with Agile development, it became apparent that our project would greatly benefit from its principles. Unfortunately, the path leading us from here to there seemed long and arduous, and it appeared that changing the process too dramatically would throw the schedule off even more.

During one of the roundtable meetings, one of the regulars brought in the March issue of the Harvard Business Review and showed us an article called “Everything I Know about Business I Learned from Monopoly” by Phil Orbanes. In the article, Phil talked about six primary principles that make a great game and how those same principles 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 them chances to come from behind.
  6. Provide outlets for latent talents.

While Phil talked about applying these same principles to business and management, I don’t think he meant them to be applied as literally as I chose to interpret them!

The Development Game

After pondering our process dilemma and trying to figure out how to make the project a success, I came up with a simple game that rewarded good practices and penalizes bad consequences (but in a fun way), based on the principled in the article. The game placed the responsibility of the process on the shoulders of the developer while also minimizing the amount of time they needed to spend on the process.

The premise of the game was simple. We printed up some fake money with our VP’s picture on it and used it to pay members of the team for necessary practices in the project. The fake money was used at the end of the project to purchase items in an auction. One member of the management team was chosen to be the “banker.” The developers got 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 (which was quite difficult to get the team to use) and replacing it with a simple eight-item checklist, which was turned in at the end of each cycle. This checklist and a simple code-review worksheet were used to help determine how much each “player” got paid. The management team also had the option to reward items not included on the list. For example, when we started having people arrive late to our daily standup meeting, one of the managers chose to pay everyone five dollars for being on time. The message was received, and the problem became minimal. Players also had the ability to pay each other if they chose.

Table 1 shows how the developers were paid.

Day-to-Day Fun

We tried to make the game as fun as possible by making a big deal out of the money. When a cycle was complete and money paid out, it became everyone’s business to make a big deal: “Wow! You got $190 that cycle?” It was an especially big deal when someone broke the nightly build. The “banker” came through and collected the money loudly and obnoxiously. It was great fun, and now no one wanted to break the build!

Results

The results from implementing the game were 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, some bad attitudes and bickering were beginning to surface. Left unchecked, I feared that these attitudes would escalate until the project and/or the team suffered. The game helped raise attitudes 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 gave it some excitement, too.

The other big surprise effect was that the developers began working more closely together, sharing code and ideas -- even to the point of some of the team members pairing up at the same computer for days. While we eventually want to implement an entirely Agile process, including the idea of the pair-programming principles from XP (eXtreme Programming), this was completely unexpected.

As a side note, we actually saw our schedule deficit begin to shrink. While this may or may not be attributed entirely to the game, I’m sure that it has helped. We were still showing a projected end date beyond the deadline, but we were gradually pulling it back in and were optimistic about releasing on time.

The End Game

One important principle that the game article discussed is giving the players the chance to come from behind in the end game. 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. We didn’t want to take away from the purpose of the game, so we kept the extra activities at a lower pay level. Developers could still earn more by writing tests, etc. (We had one team of two write 26 unit tests in two weeks!)

Each day, right after our standup meeting, we played trivia, with the questions centered on the development team or the business. Questions like “Where did John Smith go to school?”, “What is our stock price?”, or “How many MP3 files does Jane Doe have on her computer?” were some of the more popular ones.

We also had a contest to write a utility that could be used by the team. Participants were given two weeks (of their own time of course) to submit an original utility. The utility was judged on usefulness, ease of use, etc.

The Auction

Obviously, the fake money itself wasn’t the motivating factor. Early in the game, we talked upper management into supplying items, both large and small, to be auctioned using the game money. The items included MP3 players, DVD players, camping equipment, hotel stays, etc. The expense for all the auction items did not exceed $1,400.

By the time auction day rolled around, the excitement was pretty high. People knew who wanted to bid on what items and were negotiating with others to help them. We brought in one of our fast talking salesman to be the auctioneer. The bidding was ruthless and the background trading to gain an upper hand was astonishing. It was great to see some of our quiet developers come out of their shell and really become bold and aggressive.

A great time was had by all and some of the other departments in the building are going to try something similar. The game was a great way to turn around the negativity of transitioning to a new methodology. Maybe we can find an excuse to do it again soon!

Darin Cummins works for ProQuest, software developers for Powersports Dealerships, in Salt Lake City, UT. He has been programming since the early 1980s. Darin can be reached at [email protected].


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.