Unless you’re new around here, you’ll have heard that over the summer I was working on Pollen with Digital Colony. The team of five was composed of three programmers (myself, Ian and Kieran) who had worked together before, along with two artists (Jess, and Abi who also took on the role of team leader). Our previous project, Some Assembly Required, experienced mentors had introduced us to Scrum and given us advice throughout the development process. Moving on to work on Pollen we had a fair idea of what had worked for us and areas we could improve.

It’s Kinda Like Scrum …ish

Before we began developing Some Assembly Required, our first group project, we all did some reading on agile development and in particular on Scrum. As I’m sure most people can guess – actually following a development methodology in practice is nothing like learning about it in theory. Although we continuously refined the way we worked and organised the project, having a framework on which to base our development made a huge difference.

Using A Wiki

Partway through our first project we started using a wiki to track development, and we haven’t looked back since. Of course there are benefits to storing a spreadsheet or text document in source control, using a physical board or using specific management software, but wikis have several important features for us:

1. We can access it from anywhere with an internet connection.
2. It’s easy to share with anyone looking over the project, unlike a file stored in source control.
3. There’s little overhead in terms of setting it up and creating sortable tables.
4. Wikis support mixed media and internal links – you can easily connect pages about the areas you are working on.
5. Unlike fully fledged project planning software, all formatting is self imposed – you can easily change what information you store and how you use it.
6. We can keep all the information for bug tracking, priority lists and game design in one location.

Priority Is King

Although each programmer on the team had ideas about how they would like to specialise, let’s face it we’re all pretty inexperienced. We all have strengths and weaknesses, but in terms of areas of the codebase, no-one had a huge advantage in terms of experience. In most respects we were interchangeable.

Because of this, we were able to assign work based purely on priority. By that I mean we could split the work we had committed to into tasks, each with an individual time estimate, then sort them by importance. Each time we completed an objective, we could simply pick up the next most important – regardless of what area it related to.

This helped ensure no-ones work was blocked – for example we wouldn’t be stuck waiting for a piece of physics code in order to continue. It also meant we could all work on the game framework initially, build up gameplay throughout the project and the focus on polish and graphics towards the end.

A more mixed blessing was the way that we all had to get experience with every area of the codebase. As far as I see, this was fantastic in terms of experience. We all had to get used to writing code that we knew other programmers would read and alter, and with modifying and expanding the work of others. It ensured no-one “owned” an area of the codebase or became precious about their work being changed, and made sure we got used to writing maintainable code.

At the same time though, specialising would have allowed each of us to focus on one area and possibly get a fuller understanding of it. Also, as students, it would have given us separate pieces of code to declare as our own and a simpler answer to the question “So, what part did you work on?” than “All of it!”.

Keep Aligned With The Entire Team

Working on Some Assembly Required, one of the biggest problems on the project was the extent to which various team members were separate. Before work began on Pollen, we talked about using Scrum for the entire team. As soon as work began though, it became apparent that it wasn’t going to work out.

Having two artists, one 2D and one 3D, made it difficult to simply sort work by priority. Each task had to be carried out by one particular person, often in a particular order or going back and forward between artists (such as when texturing). Instead, we simply agreed which stories were going to be a priority in a given week, and decided which art assets and programming tasks would come of this.

At the beginning of the project, our 3D artists Jess made some placeholder assets: a sphere, a box and a billboard, as well as assets to test animation and texturing approaches. This made it easy to simply apply textures stating what an object was until it could be replaced with a final asset – we were never waiting on an object being produced or exported.

Part of the way through the project, we started assigning time each week towards ensuring any new assets produced were working in the game correctly.

Stay Flexible

One of the best aspects of working on a small team with complete control, and also of short iterations, is the extent to which you can adapt the development process. We tried things that didn’t work, for example for a while we tried to keep graphs of our progress. At the end of the day we just didn’t find them useful …so we just stopped. Nothing lost. At the same time though we also tried, for example, creating tasks that averaged at most 3 hours rather than 5 or 6, and that made development easier for everyone. There was plenty of room to experiment.

The same goes for design. No member of the team, on either project I’ve been part of, was an experienced game designer so needless to say we learned a whole lot as time went on. Although both projects were only ten weeks long, we still had time to make large changes to our original designs – for example trying and scrapping touch screen support, or adding puzzles based on throwing rocks once we had a feel for the mechanic.

Nothing Is Perfect

Of course, even though the last project went fairly smoothly from a development perspective, there is still a lot about our methods we could improve and a number of things we’d do differently if we were to begin another game. I hope to cover more about what didn’t work for us, and what we intend to rethink in a specific Pollen postmortem, but until then I’d love to hear from you. What problems or benefits can you see about the way we work? How does it compare to yourself or your team?

So many particles.

The game itself sees Warran T. Void, a lost and damaged little robot, wake up alone in a factory. By collecting new parts from vending machines he can rebuild himself with new abilities, allowing him to overcome obstacles and progress through the game. Our prototype level introduces you to a pair of suspicious character who instruct you to climb a giant construction robot and collect pickups for them, and playing as the naive Warran you enthusiastically oblige.

Would you trust these gentlemen?

These are all taken within the last week as we built our level and did some final testing. It’s been really awesome to see our game go from a series of platforms on a plane into a full, playable prototype level as it was only recently that we were able to bring all our art assets and platforming sections together into one application. As you can see, we went a little overboard with bloom, particle effects and shiny things however our actual focus throughout development has been on gameplay mechanics and the physics behind this.

The game was implemented over a period of two and a half months, that’s ten week-long development iterations, following on from general story and game-play designs we worked on late last year. A lot has changed from our original ideas – in particular splitting the BBC’s “interactive narrative” brief into two parts consisting of this game and a separate research project – but we’ve kept the core mechanics and level in tact.

Did we mention our level is also a robot?

The team itself consists of ten third-year students: five programmers including myself, two artists, two producers and a sound engineer. We also had the assistance of programmers from the BBC, and a mentor from Real Time Worlds. This made a huge difference to the project in terms of organisation and development and keeping on track, as well as handling technical problems with our codebase, and (at least as far as I’m concerned) has given us far more experience to carry over to our future projects than we would have gained on our own.

So, fingers crossed for our demo tomorrow and our showcase later in the term (which I believe is open to the public, more details will follow if that’s the case) and hopefully we’ll have a final video prepared for you soon.

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?