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.

I was talking to a fellow Thoughtworker about the challenges of consulting, and I thought that one of his points was interesting. What he basically said is that you have to try to understand the motivations behind all the stakeholders in a project; not everyones primary goal is delivering software, there are many motivating factors that drive people. A good consultant will try to understand what their motivations are and then try to unify their goals with successful software delivery.

This made me think about a general organizational “smell” in software development. For lack of a better label, I’ll call it fragmentation of goals. A manager might be juggling multiple projects, of which yours is not the highest priority. QA’s may be measured based on how many bugs they find, or how many test cases the document. A developer might see a better chance at promotion by going to all the meetings he or she is invited to, moreso than the delivery of features. Entire teams within a project may even be motivated by goals that are not complimentary to the success of the project.

When I was in college, I liked to compare the team projects I was on to games. My goal was making sure that we were winning the game (in that situation, getting an “A”). Later in my education, I read Agile Software Development by Alistair Cockburn, and he made the analogy that software development is like a cooperative game that we are trying to win. I’ve always loved that analogy, and I think that it’s a useful tool in conceptualizing an effective team or project. Much like a team game, software projects must be a coordinated and unified effort amongst individuals to achieve a common goal.

There are three important factors that are core to a team being able to deliver software successfully, and each easily becomes fragmented (I’m generally using team and project synonimously).

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

I’ll discuss each inline below.

Knowing how to win the game

A team or project must know how to “win the game” - there has to be acceptance criteria on the results of the teams efforts. Not having this clearly established makes it impossible for people to unite towards winning (I am not implying having all the “requirements” - I am talking about a clear understanding of how to accomplish the business goal). Without a clear goal, a team can only work towards something that they hope is right, and everyone may not agree on what that is.

An important aspect of this strategy is to have a single dedicated product owner - someone who can provide a vision of the end goal, and be the final decision maker for what aspects of the product will achieve that goal. This will help not only knowing what to build, but have the ability to prioritize when to build something.

Being motivated to win the game

The second part is ensuring that the team is motivated to win the game. The team as a whole will suffer if the individuals are engaging in activities meant to promote their own goals over the goals of the team. There are many, many parts to this. My basic opinion is that measuring an individuals success should be based on their contribution to the team, and the teams success.

It is difficult to make sure that everyone has the incentives to be motivated. It is not enough to hire people and then put them to work on something. You must make sure that they are happy, and personally interested in succeeding. It’s especially important to make sure that the personal goals and desires of the individuals aligned with the success of the team.

This doesn’t just apply to individuals. Often large projects involves dividing the project into smaller teams. It’s not beneficial to set up teams with goals that allows them to succeed while the project fails. The concept that this works is often an attempt to suboptimize a system - the idea that if the individual components are succeeding then the whole will succeed. This approach is flawed and often leads to a team achieving it’s goals, even at the expense of the project.

Having the ability to win the game

The team must have the ability to be effective and able to win the game. Further, the team must be empowered to make changes to increase their ability to win the game. The easy example of a team not being able to win is that when the team is formed with people who’s skill-sets are not suited to success. For example, building a team of people that have never done web development, and asking them to build a sophisticated web application. Another easy example is creating unachievable goals for the team, such as having the scope be too great for the team to ever achieve.

More complicated scenarios involve putting a restriction on a team that they must use a certain language or technology, or to disallow some tools and technologies, without consideration as to whether it actually helps the team succeed. It could even be as simple as the developers not being able to get licenses for software that they need, or computers to support the development efforts.

This point is part of the reason that it is critical for teams to be responsive, continually improving, and honest about what will make them more effective and better able to succeed. It could be that 1 month into a project, the team already knows that it’s failing and it’s likely that nothing can be done to help. It could be that the team is producing features, but is losing a lot of time trying to communicate to disparate groups that they rely upon.

Designing the game

A final point here is that all of these factors are part of setting up the game in the first place. Often the decisions that are made early on in a projects life sets it up to succeed or to fail. In my experience, the structure of a software project tends to be an extension of the organizational behavior of the company. That structure may not be an ideal structure for a software project.

Regardless of how the project begins, it’s important to change how the game is played if it is necessary to win the game.