This is a posting I originally wrote for #AltDevBlogADay.

We’re a small indie company of six. Four programmer/designer hybrids, though each of them proficient in other areas too, one artist/designer and one community manager/marketing/designer. Only half of us have ever worked in other game companies and only one of us has ever contributed to a AAA game (though uncredited). We have no strong ego running the business, but a very collaborative atmosphere. That’s why we need a clear methodology for working efficiently. We have a rigid structure for our creative process in order to live the freedom that it gives. The system we’re using is loosely based on scrum but finely tuned to our situation. I don’t believe in off-the-shelf design methods. So we tailored our own. Here’s how we scrum.

We usually work in one or two week sprints. It has been seen that we’e been doing three week sprints, too, but those were rare. We use Basecamp for the detail-work, i.e. todo lists and discussions. We use Skype for immediate communication. The scrum is a tool for on-site face-to-face collaboration and that’s why we do it on paper. We scrum on Monday, Tuesday and Thursday. Our core period is from 11am to 3pm. You’re supposed to be on-site during that hours. If you can’t make it to the office, you must be available on Skype during that time. The scrum is shortly after 11am, usually around 11:30am, once everyone is in the office or online. We try to timebox it to 15 minutes, but sometimes we fail.

We have no roles in our scrum because otherwise half of the team would have a role which somehow contradicts agility. We know that this will change once we’re a larger team, but for our current situation, the most important factor is honesty. And if you’re playing the “Product Owner” when you’re in fact the engine programmer, your honesty is severely compromised right from the start. We don’t play games, we make them.

Our scrum board has the following layout. There’s the “Future” box on the left. Unassigned and miscellaneous future tasks can be put into that box all the time. They are to be considered in the next sprint. Then there are three bars titled “Todo”, “In Progress” and “Check”. On the right, there are two boxes, “Done” and “Backlog”. An item is introduced in the “Future” box. During the planning of the next sprint, the tasks’ post-its are moved from “Future” to “Todo”. Also, one ore more people are assigned to the task, one of them officially responsible for the completion. Those are written on the post-it, too. If a task loops over the whole scrum board several times we talk about why that happens and either drop it or reframe it so that it can be completed. During the scrum meeting, each team member picks the task he’s going to work on for the next one or two days and moves the post-it from “Todo” to “In Progress”. He also moves all accomplished tasks from “In Progress” to either “Done” or “Check”. Tasks that are to be checked should be tested by a different team member before they are considered “Done”. If the task could not be completed and gets postponed to the next sprint, the team member puts it in the “Backlog” box. Additionally, there are “Mail Pending” post-its that signify an external dependency. Sometimes you can’t proceed because you’re waiting for a phone-call or email. Other dependencies are modeled using different post-it colors for the tasks. Red means either that the task is very important or that a yellow task depends on its completion. Green is one hierarchy level lower than yellow.

We’re currently quite happy with our custom-tailored scrum (or is it even scrum-ban; I’d say so). But there have been times when things didn’t work so smooth. We had one person responsible for the scrum meeting for some time who was not interested in that particular position at all. He did the job but the scrum really started to show its strength as a productivity tool once we’ve made our whole development dependent on it instead of having one guy reminding us that it is time for the scrum. Put bluntly, it’s necessary that the scrum feels necessary for everybody. We’ve also experimented with estimating the hours we have to put into a task and writing them down on the post-its in order to get a better feeling on the amount of tasks we can put into a sprint. That worked but always felt awkward to me personally. Currently we’re not pursuing this route anymore. In my opinion it is much more valuable to have flexibility than predictability. In other words: Postponed tasks and tasks that explode into hour-eating martyrdoms are problematic cases. Keeping an eye out for those is really important. We might experiment with a more abstract system of estimating the workload of a task in the future.

This is how we scrum. As usual, we’ve broken a lot of rules. I’m not writing this because I want you to copy our methods. I’m fairly certain you can ruin a project by doing that. All I want to tell you is that it is a good thing to tailor your production methods to your own needs. How do you scrum?