Tuesday, September 30, 2008

Cross-functional teams (“Feature teams”) in game development is not straightforward

Our teams are average about 5-6 persons in size. Some are somewhat larger and some are smaller. But in general they are all a mix of people with varying competencies. For example for one of our games which is a somewhat “3D intense”, the teams consist of web developers (PHP), 3D developers (C++), 3D artists and 2D artists. The idea with Scrum is that the team collectively commit to the sprint backlog and help each other out to focus on finishing (Done-Done) stuff in sprint backlog priority order.

The problem here is that the 3D artists cannot really contribute to the PHP or C++ coding, and the Web developers aren’t really capable of helping with the 3D programming. So the feeling of collective commitment is weakened, and the cooperation-effect is lost; what remain to help out with are things like testing, perhaps code-reviewing and just generally “wiping the floor” (removing impediments) for whoever is working on the top-most priority stuff (e.g. being “Servants” to the “Kings”). It works sometimes, but it is not optimal. It would be interesting to know how others do it.

The alternative would be to split the teams up according to these “hard borders” of competence, so that e.g. the artists would be in a team on their own, and leaving all the programmers in one team. I don’t have empirical evidence to back this up, but I have a feeling it is a choice between two less-than-optimal alternatives, and putting them all into one team is less bad than to split them up…

3 comments:

  1. We (internal team of a megapublisher) have divided our team more into department roles. I'm not really happy with that either. The most ineffective team we had was a collection of 4-5 tool programmers each working on different tools using different technologies. That was no team at all and it quickly dissolved. We also still have heroes, people who are the only ones working in a specific area that aren't easily replaceable.

    It is hard to imagine more "vertical" teams but i believe it's possible. But one thing is for certain: we got to have a dedicated tester in each team.

    We also haven't yet added the Scrum Master role and are just planning to add it to the next project - as part time staff. I will push for training because i think no one really knows what importance this role plays.

    Btw, we are working with Scrum for two years now and still, i've done the Nokia Test and my result was a meager 2 or 3 at best (out of 10)!

    We have a long way to go!

    ReplyDelete
  2. Thanks for sharing your experience.
    I recognize what you write about, and the scattered focus of a group of developers has been commonly seen in our org too. Nowdays though we try to be disciplined about "swarming", i.e. focusing all efforts of a team on one or a few stories only instead of everyone picking their own thing and working individually.

    Glad you're pushing for training: in my experience it is key. I can really tell the difference between "before" and "after" we started training all the staff in Scrum. Nowdays everyone (more or less) are able to help out keeping us on track with regard to Scrum; as opposed to previously when we were only one or a few persons with a thorough understanding of Scrum.

    Keep it up!

    BTW; havent done the Nokia test myself either, but I will. I'll post the results here :-)

    ReplyDelete