Tuesday, August 26, 2008

Agile values - Individuals and interactions over processes and tools - Part 2

Question: How does a large software project get to be one year late? Answer: “One day at a time!” - Fred Brooks

Our processes and tools to manage ever growing projects have built up over decades. Large teams have driven the creation of hierarchies of management. Project schedules and design documents that attempt to predict every requirement and task necessary to make a fun game now require expensive databases to manage. All of these are considered necessary to tackle the complexity that rise from having upwards of a hundred people working on a project for years.

Game development requires developers of widely different disciplines. Take for example a cutting edge AI character that needs to walk around an environment and challenge the player in the game. The creation of this character requires the participation of animators, designers, character modelers, texture artists, programmers audio composers among others.

It’s important that these disciplines collaborate as much as possible to be the most effective. If the animator is experiencing a problem with the animation technology, then it is important for them to work with a programmer as quickly as possible to address the problem so they can continue working. Often the processes and organization will prevent that. In our example with the animation bug, the programmer may be working on a series of tasks that were assigned by a lead. This may prevent that programmer from helping out the animator without permission from their lead. This leads to a chain of conversation as shown in the following figure:

The animator has to pass the request up through the chain of command which then has to make it back down to a programmer who can solve the problem. In this example, the change involves five people and four requests! This flow is prone to failure and delay.

So what has been described?
  • Over 100 people of various disciplines on one team.
  • Thousands of unpredictable problems that can introduce wasted time and effort
  • Detailed plans and tools to manage them that can’t predict these problems and are potentially inflexible at changing.
  • Hierarchies of management that can lead to further waste.
Agile can address these issues from the bottom up. This is a major benefit from self-managing teams. They self-manage the smallest level of details, not necessarily the highest levels. They aren’t self leading teams. They unburden leadership of the role of managing minor details. They allow leadership to focus on the big picture.

When teams learn that they can take a small amount of ownership to solve the smallest problems, they start taking on larger problems. They begin to ask for more ownership in other areas:
  • In creating better teams that can solve more problems by reducing external dependencies.
  • In demanding more of themselves to achieve commitments they own.
  • By identifying risks early and addressing them before they become problems at all.
  • By growing leaders among their own ranks.
Agile values are preferences and not binary decisions. We can still have process and tools to support the team, but we value individuals and interactions more to solve most of the problems that occur on a daily basis.


Shane Neville said...

That diagram is the one of the single best visualizations of the strengths of agile multi-discipline teams that I have ever seen. Simple, but it hits it right on the nose.


Anonymous said...


Good diagram with neat explanations.
when people in a team communicate properly, the problems can be solved easily.

Nice post and Keep it up.
Pschic power