At the beginning of this year, we finally started implementing our design for a group project game. Considering that we were meant to be working around 40 hours per week and have 4 seperate modules for this term, it seemed fair to allocate 10 hours per programmer of development work per week (considerably more than the 20 hour total development time our producer originally planned in order to “make his charts look pretty”, but that’s neither here nor there).

Looking at our burndowns, table and charts, we really are doing 10 hours of development. At least. Plus research. Plus fitting in time between classes or over lunch. Plus helping other people over their shoulder or on MSN.

…Plus meetings.

We normally have two meetings per week – a whole group meeting, which normally take around an hour although it can easily last longer, and a sprint retrospective followed almost immediately after by a sprint planning meeting, which often lasts three hours and sometimes as long as four.

That’s right,

1/3rd of our weekly project time is spent purely sitting in meetings.

Does that sound as horrific to you as it does to me?

My first thought was “What can we cut out to shorten this time?” and after some consideration, there are a few ways we might be able to limit our time to some extent, but there’s nothing that would really make a significant impact. We meet with the whole group once a week to discuss progress with the artists, and to give feedback to each other about the direction of the game. It might be possible that only one programmer could attend this but there are decisions they couldn’t make without deferring to the other developers – going back and forth would probably take just as much time. Compared to the length of our SCRUM related meetings, this is also a fairly small consideration anyway.

As inexperienced developers working on our first group project, we’re learning a lot from each sprint, and are constantly making changes (hopefully improvements!) to the way we work. Whilst developing a finished game is important to us, this is above all a learning process and cutting down on our sprint retrospectives would be cutting down on the time we have to reflect as a group – clearly not something we’d be willing to sacrifice lightly. Similarly, planning our next sprint take a fairly fixed amount of time. We need to select the stories we’re working on, split them into tasks and get estimates. We also take time at this meeting to discuss roadblocks we’re facing, technical changes and get help with solutions since we have far more exerperienced developers around to help us. This would take up time no matter when we did it – over MSN, over lunch, when we’re meant to be programming… it’s not something we could easily eliminate.

So maybe all the time we’re spending reflecting on our progress *is* necessary. Maybe the real issue is that formal group development just doesn’t scale down all that well. I mean, the amount of time we’re spending on this project seems a lot when we’re also working on other coursework and modules, but what’s 10-15 hours in the real world? Compared to working full time on a project, that’s next to nothing. Even dedicating 40 hours a week to a project though, it would be hard to imagine our meetings lasting a whole lot longer – the overhead appears to be almost constant.

So maybe the problem is with our implementation of SCRUM, maybe it’s a problem with SCRUM in general and maybe it applies to almost any development methodology – either way, for a small project the amount of time we spend in meetings per week is unnacceptable.

So for the sake of future students embarking on these projects, can anyone offer some suggestions? Recommend an alternative development method perhaps? Help programmers to spend as much of their time as possible on making progress, and not just talking about it?