Kris Kemper

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.