Well, not really blues, maybe a light aqua sort of shade…
“Amir” I hear you say, “you crazy beautiful bushy bearded programmer, I don’t think you’ve ever talked about managing the workload with Buck!” And you’re right, I haven’t written much about the project management side of things. So perhaps now is the time to draw the outlines of the hows, whys and wheres of managing a project the size of Buck.
Let me preface this post. Every team is different and so in my opinion every methodology must therefore be customized for those particulars. In essence; there is no magic “one size fits all” management process that would boost a team’s productive output. And I remember spending a lot of time when I had less experience looking for one. With that said, let’s start.
[quick note at this point; I know the title says “Tuesday” and today is Friday, but I started writing this post on Tuesday]
Before getting into our process and because our team is different from yours. Let’s meet the team.
Buck has three people working on it. A programmer [me!], the artist and the designer (who does animations, sounds, music and the business side of things on top of it all… we love you Gal). As you can see we’re a small team. A very small team. We work separately except one day a week when we meet and put in a full office-like workday. We wanted three basic things from our process. Simple, transparent and fast. We’ve tried several approaches which failed (and I might write about those later because knowing what failed is also important but I’m running out of time again).
So, what do we do?
Trello is a simple and free (yay for awesome free tools) online tool which allows its users to create vertical lists across a horizontal axis. Each list contains cards which can be moved between the lists or archived into an internal [hidden] list. As I said, simple. At the moment we’re using a single board for Buck and have broken it into two sections; one for the code/development and one for the art/design. I’m not familiar with the art/design section (I’m the programmer after all) so I’ll concentrate on my section.
Let’s take a small detour to the cards. We have two types. Feature cards and Bug cards. And, just as they sound, each does exactly what you’d expect. A feature card describes some game or editor feature that someone wants (me or the designer) and will usually take the form of a request; ie. “I want to do [X] because of [Y]”. Bug cards are broken into two. The title of each card will describe what the bug is while the description in each card will (ideally) describe the steps required to reproduce the bug (called in parlance, repo).
Onward to lists; five lists. Backlog, Sprint, Doing, Review and Issues.
The backlog list is the catch all of all features we want in the game at some point or another. It isn’t organized in any particular way and we add to it constantly… too constantly… it always seems to grow 😀 (though not all of cards will see the light of day and will remain forever unimplemented – until the next project).
The issues list isn’t anything special; any issue we or one of our testers discover ends up there. And like the backlog it has a tendency to grow somewhat. Unlike the backlog we do sort the bugs. Into minor, major and game-breaking. Guess which ones we take care of first?
Then we have the Sprint list. This list contains all the cards we’ve decided to implement in the current sprint session. A sprint session is a static (ie. not changeable) length of time we’ve set to get from point A to point B. Point B meaning Build. I can’t actually stress this enough but;
Sprint times are immutable. Do not make them longer or shorter while sprinting. Stick to your sprint time during the sprint and Do. Not. Change.
You can change sprint times. In fact iterating over the process is as important as anything else in the process. So, what did I mean? First, we do not end the sprint prematurely. And secondly WE DO NOT PUSH THE SPRINT END UNTIL WE HAVE A WORKING BUILD. Whenever we arrive at the end of a sprint and can’t make a build. Tough. We don’t make a build. We end the sprint. Failing to implement features means we’ve taken on too much and/or we’ve misjudged the workload on any particular card. This is our opportunity to learn. Otherwise the process will fail over and over again because we’ll never become better at estimations. Trust me; I’m speaking from experience here. Don’t do this.
So what can you do?
Like all good software developers: Iterate. Do a few sprints (unless some colossal failure happens). Review; do you want more features in a build? less features in a build? Add a week, take off a week. Rinse/Repeat. Small increments will yield stable results.
Our current sprints last about a week (fast iteration, only one programmer) and usually amount to one new feature implementation and bug fixes. They were somewhat longer when the project started because we needed more time to implement systems and set up the framework before we could implement game features. Experience and pain; get it and learn from it 🙂
Once the sprint list is set work can begin. I pull the card I’ll be working on from the sprint list to the doing list and when I think I’m done, I push it to the review list. After each build Gal will test and review each card in the review list while I’m working on the next sprint. Review cards that passed are archived; cards that failed are updated with information and put back into the backlog for the next available sprint. And that’s about it.
Nothing I said here is set in stone. Our team is small and very flexible. The planets do align sometimes to throw us a curve ball and we have to step outside the sprint. As a small team I suspect it’s easier for us and at times too easy. Keeping focus is also hard work. Anyway, I hope whoever reads these things of mine enjoys and until next time…
“I speak of madness, my heart and soul, I weep for people who ain’t got control”