Sunday, November 30, 2008

Team co-location and team rooms

Agile principles emphasize face-to-face communication wherever possible. The benefits of this are demonstrated best at the team level. When teams sit apart from one another, the overhead of communication and the problems that arise from a lack of easy communication are seen daily. Studies have shown that when teams reduce their physical distance between themselves, their performance increases in many ways(*).

Eventually teams realize this and rearrange their seating arrangements to improve communication.

Teams that co-locate are often limited in their options for team rooms. Often the office is arranged in small cubicles that cannot easily be removed due to power and data wiring limitations. Fortunately team rooms or “bullpens” are less expensive to create than cubicle farms or separate office spaces, so if you are lucky enough to influence the initial office space build out, you can create an ideal space for a team. Otherwise you’ll need to slowly adapt your current space. Some studios set aside a modest budget to slowly convert their spaces.

The Space

What makes an ideal team space? There is no ideal space for all teams. Sometimes teams can’t even agree among themselves what makes the best space. If you have a cross-discipline team, perhaps the programmers might want some windows while the artists don’t want the light from the outside. It’s up to the team to work out what is best. Here are some things to consider when deciding about your team room:
  • Is there enough wall space for your task board, information radiators and white boards? You can never have enough space for white-boards!
  • Is there enough “slack” in the space so that people can occasionally pair up at a computer? For example, can a programmer sit with an artist to discuss a problem?
  • Is there space for meetings, such as the daily stand-up or a play-through? Is there a dev station available to conduct a team play-through on?
  • Is the room “off the beaten path”? A lot of traffic from outside the team in the area can be disruptive.
  • Are there local private areas? More about these below.
Once you build your space, what kind of furniture is best. My opinion is that mobile, modular and adjustable furniture like those built by Anthro are best. Teams change and improve over time. The ability to rearrange the space a bit every Sprint can be a big benefit.

There are typical concerns that are raised about team areas. These are:

“Programmers (artists, designers, etc) need to work in quiet isolation in order to focus and be effective. We can’t do this in a noisy team room with constant interruptions”.

This is a common concern about working in close quarters with other developers. For certain, there are more interruptions in a team room. Most of them are the point of the team room. When individual developers are trying to achieve individual goals, then interruptions often impede them from that goal. However agile emphasizes the delivery of value integrated into the game, not the value of finishing “parts” that should join seamlessly because a document says they will.

When a team is focused on achieving a common goal that requires everyone’s participation, fast access to other team members who can help progress is not only necessary but essential. It doesn’t make sense to have an animation programmer on the other side of the building implementing a system that may or may not be of any use to the animators someday. They should be solving the problem together.

Team rooms for people working on separate goals don't makes sense.

As far as noise level, if it starts getting in the way of progress, the team must solve it. Every team that I have seen transition to a team room doesn’t want to go back to isolation. If they felt isolation would benefit their performance, they would have permission to do that too.

This doesn’t mean that the people never need privacy. Having a few small offices around the team area where people can go to work on a tricky problem or have a private conversation is important.

“If I am not sitting in a group of people of the same discipline, then I won’t learn as much and be able to help them out as much.”

This argument is a more difficult barrier for teams who wish to co-locate. It has some validity. One example of this was in a studio where half a dozen AI programmers spread out across three teams. Following this, three incompatible AI solutions emerged that duplicated effort. However the best solution wasn’t to let them sit together in a single team. The reason was that they didn’t create the best AI system for the team. In fact they produced an AI system that was state of the art. It was rapidly developed and did amazing things in their test environment. Unfortunately this system didn’t meet the needs of the game. When matched up with motion captured animation in a representative level (rather than the test environment with ideal test shapes) the AI was incapable of even simple navigation.

What is the reason for this? Did the animators and level artists create the wrong assets for the AI or did the AI programmers create behaviors that were incorrect for the animation and level layout? It was really both. They should have developed everything together. They would have learned along the way to alter the behaviors and assets to accommodate reality. They would have collaboratively built knowledge of the best solution.

This drives cross-discipline teams and raises the value of instant face-to-face communication. What about the original problem of collaboration between members of the same discipline? How do we avoid the AI programmers going off in separate directions? One solution is orthogonal teams. Nothing prevents the AI programmers from gathering once a week or once a Sprint to discuss their work. It just doesn’t need to be as frequent as communication within a cross-discipline team.

* The effects of R&D team co-location on communication patterns among R&D, marketing, and manufacturing, Christophe Van Den Bulte, Rudy K. Moenaert, 1998

Tuesday, November 11, 2008

Beyond Scrum: Lean and Kanban for Game Developers

Gamasutra has posted an article of mine called "Beyond Scrum: Lean and Kanban for Game Developers". The article culminates what has been described here about using lean practices since 2006 and applied to games in production and details how Scrum teams can adopt Lean practices.

If you want to read more about Lean and reducing production costs by more than half:

Lean Production, first steps, September 2006
Google Talk with Mary Poppendieck, December 2006
Prototypes, April 2007
Book review: Implementing Lean Software Development, September 2007
Cooper product design applied to game development, parts one and two, August 2008
Phases in an agile game project, September 2008

Tuesday, November 04, 2008

Scrum and project miracles

There is a lot hype about the benefits of Scrum. Much of this hype is born out of the desperation developers have had from the failures using traditional methodologies. One example of this was on a project I joined in its early planning phase. We were challenged to develop a sequel to a game that another developer created. The original developer had spent four years developing the original game. We were given eighteen months to finish the sequel which had be of higher quality. The impression was that if we had the source code of the original game, we could be three times more efficient.

Detailed plans and schedules were created that defined how we would successfully ship a superior sequel on time. Unfortunately we failed to achieve the goal even after months of mind-numbing overtime and the project was canceled.

Could we have succeeded with Scrum? I'm sure we wouldn’t have shipped the game on time, budget and at the quality target. However I believe the project would not have failed as badly. Rather than trying to follow a preset plan and hoping to catch up as we slipped, we could have known earlier that the goals were impossible. Had we known early that the goals were unlikely, we could make better decisions on how to proceed.

The best way to spend less money on a game is to spend less time. We are always in a rush to be first to market. Even if costs are the same, we often choose the project with higher staff levels that can be shipped six months earlier.

This is why we are never given enough time to do our job well. This is why we are forced to enter production before we have found what is fun enough to produce. This is why we ship prototypes.

Scrum isn’t an answer to this. It’s a different way to deal with uncertainty by addressing it head on. Take for example, a game in development using Scrum that is projected to enter production by October 2009. After a few iterations, (see figure) we see that the actual progress of the team (the thick red line) is 70% of what was projected in the blue line as measured by user story points. By projecting this actual velocity (the green line) we see that with the current scope planned, we will enter production five months late.

The Product Owner (PO) will be aware of this actual velocity and has a number of choices to make. If the game really must enter production by October 2009, then they will likely cut scope. The PO could try to increase the velocity of the team by adding people, but this rarely works.

Conversely, if the PO wants all of the scope defined in the game, then they must communicate to the stakeholders that the production date needs to slip.

One caveat to mention here is that things aren’t often so cut and dry on our projections. We don’t often estimate user story points beyond six months in advance in detail and velocity isn’t constant. Beyond six months the crystal ball is a bit foggy. Some projects will estimate larger epics. Others will build larger backlogs. Neither of these solutions will give us more certainty. If the ship date is fixed more than six months off then we need to make sure the backlog is always prioritized so that if the PO needs to cut scope, they are cutting the lowest value scope.

The principles still apply. We need to measure the actual velocity and not depend solely on our predictions.