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.
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.
- Make the rules simple and unambiguous.
- Dont frustrate the casual player.
- Establish a rhythm.
- Focus on whats happening off the board.
- Give them chances to come from behind.
- Provide outlets for latent talents.
While Phil talked about applying these same principles to business and management, I dont 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 VPs 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 elses 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.
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 everyones 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!
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 wasnt 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, Im 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 didnt 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.
Obviously, the fake money itself wasnt 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@example.com.