Kris Kemper

I was playing a video game the other night and I thought of another characteristic about how to build a successful software development project. I know, relating video games to multi-million dollar software projects may be laughable to some, but bear with me.

I had blogged previously about how to win the game where I discuss the concept of game theory as it applies to software development. I outlined what I considered the highest level considerations, but I wanted to go into some more depth into how you become good at a game.

There is a particular quality to games to determine if you are winning them or not; When the game allows rapid cycles and fast feedback, you can figure out whether or not you can get better at the game. In the case that you aren’t getting better, you probably should not be playing the game, or you should change the game so the player can get better at it.

The last point is important, and one of more difficult considerations. Perhaps that team will never win the game. The only way to discover that is to play the game in cycles. These cycles provide the information needed. In the previous blog post, I outlined that there were 3 important aspects of a game.

1. Knowing how to win the game
2. Being motivated to win the game
3. Having the ability to win the game

This is all fine in theory, but how do you really know whether a team has unified these three considerations?

Back to my analogy to video games. I was playing a racing game, and at first, it seemed like there was little I could do to beat the computer players. The racing tracks were too hard, the computer players were too good. There was too much chance involved. Then, as I continued to play, I became a little better. Energized by the awareness of this, I played more, and got even better. After a while, I beat the game.

How did I know that I would get better? It certainly seemed like I was failing at first. The answer is that there were rapid cycles of practice and feedback. I got information about how I was doing.

How does beating a video game apply to the 3 principles that listed above?

The first is easy; I had to complete levels of the game that incrementally led to my winning the game. I clearly knew what it took to win the game. Each level that I won was not only a discrete step towards winning, but it was a test of my ability to progress to the end goal. I see a parallel here to having stories represent cohesive unit of valuable functionality or features.

The second is also somewhat easy; I wanted to win. I enjoyed playing the game. It was stimulating and rewarding enough for me to continue trying to win. However, I think it’s important to note that a large part of the reason that I maintained motivation was that I knew I was getting better, and I knew that the end goal was achievable. If I can’t win a game, I lose interest. If I were forced to play a game that I felt was losing, I would also lose motivation, even if you were paying me to play the game. This is reminiscent of a project death march.

The third point is perhaps the most relevant to this blog post. There would be no way to know if I was capable of winning the game without short, achievable, and valuable cycles that informed me of my progress. Not all games can be won. If you were to have me play a computerized chess game meant to compete with a chess grand master, I may never win, even if I play for years.

A difficult part of a project is determining if the people of the project have the ability to win the game. There are many reasons why the game is setup such that it can’t be won. It’s not just whether the people involved aren’t capable (wrong skill sets, insufficient experience, etc), it’s often because the structure of the project impedes success and/or the scope is too large.

I have a lot more to say on this topic. I think that the game theory analogy is very applicable to software development, and organizational behavior in general. I think that there is a fundamental project management question; How does one form a group of people to achieve any endeavor? The general answer to this question is applicable to software development as well.