Self Managed Teams

When I was at University, we often were required to work on “group projects.” A group project was a type of assignment, but instead of you being completely autonomous and responsible for the final product, you were required to work with other class-mates. Many of us hated it, but the Universities implemented these type of assignments for a good reason – the real workforce increasingly requires a greater level of collaboration and team work.

One of the good things about these type of assignments was the autonomy and empowerment that came with it. The tutor / professor / lecturer would set a deadline, and a specification (in my case, a poster presentation). We would then have to work out the steps that were required (thus requiring us to think through the whole exercise), break the tasks down and assign them to various people (delegation), and then track our own progress. We found that we needed to have regular meetings to check in with impediments, questions, or just to get feedback on what we had produced so far. I specifically remember one group project where we managed to get everyone working in areas that they were good at – one of my main jobs was the presentation of our final product – taking the content we had all produced together and arranging it onto our poster using Adobe Illustrator. My team mates recognised (from previous individual assignments) that I was skilled in this area and so happily accepted my offer to do this part of the project.

So, when I then started to reflect on how I was running my teams in the studio, I realised that I was removing autonomy and empowerment from my teams by doing all of the management for them. Rather than letting them decide who should work on what, when, and how, I was dictating all of this “from above.” D’oh!

I can’t speak authoritatively for all game studios, and this is still very much a “live” experiment, but here is my “method”:

1. As the producer, I create a list of priorities of “high level tasks” (or “user stories”, in Scrum language). This way, everyone should have a pretty clear idea of what is priority at the moment (although its always good to ask the Producer).
2. A team will organise around a goal – e.g., getting crafting done. Sometimes these teams will be populated by me, sometimes they will be self-chosen. The team can even set a name for themselves if they want 😉 [i’ve suggested using themes and classes from our current project, to keep it fun – e.g., Urchins and Engineers]. The team will also likely be a ‘multi-disciplinary’ team – comprised of artists, writers, and developers.
3. The team agrees to the sprint goal – and agrees to be judged on that criteria at the end of the sprint.
4. We’ve asked that teams ‘tag in’ a lead (e.g., the art lead), or a game designer, or both, to ensure the task is progressing in the right direction – although we imagine that the involvement of these people will be high at the beginning of the sprint (while the specification is being completed and the direction is being locked in) and then will steadily taper off over the course of the sprint.
5. This team will then divide up the tasks, add these to our project management software (strikebase), assign people to these tasks, and set estimates and due dates on them.
6. The team then agrees on a time for a daily scrum meeting where they will gather around a computer and sit down and really talk through the progress and the tasks – ask questions, get really into the detail of things. As the Producer I will ‘hover’ around these meetings as they go on, to make sure that things are moving ok and working out if there are any impediments that they can unblock and also to stay abreast of progress. These meetings could take 30mins, but they are very important.
7. At 10am we will have a “stand up” like we have traditionally. The goal of this will be to accomplish these four points:

This should take 10 minutes at the most.

As you can see, the team becomes incredibly responsible for their own work, and also responsible to each other – not just me. If they are going to be late to work one day, they need to tell their team first, not me. (Although I would like to know too, but it’s less important for me to know since it won’t be holding my day up, but it will be holding up the rest of their team). If someone in the team feels like they are going to slow the team down because they have too much work, they will tell their team and the team will try and solve this issue – perhaps someone else has a lighter load at present and so can lend a hand to the struggling person.

The goal is to create a studio that really pulls together to get things done, across multiple disciplines, and encourages Autonomy, Mastery, and Purpose.

As I mentioned above, this is still a live experiment so it’s hard to say yet. However preliminary results are looking good. I saw teams really digging into the tasks, having good discussions at their ‘daily scrum meetings’ and the end result was good. I’ve seen a greater engagement with the tasks, the schedule, the milestones, and a much deeper utilization of Strikebase.

One of the challenges is just transitioning into this model – the new freedom is strange to some and so occasionally I have had to ask if the teams have actually met up and talked today – but I also imagine that this will decrease as we all get used to the new model.

Check back later on (maybe in 6 weeks time) and I will post an update about how it’s worked.

Until next time, keep producing.