Martin Pichlmair (@martinpi) is wearing a lot of different hats at indie game developer Broken Rules. He's mostly responsible for business development, production and game writing. But he's also working on the in-house Ginkgo Engine, game design and the toolchain. Broken Rules is currently working on the aerial action game Chasing Aurora.
Posts by Martin Pichlmair
  1. Game Prototyping 101 ( Counting comments... )
  2. Game Thinking ( Counting comments... )
  3. Layers of Depth, Layers of Fun ( Counting comments... )
  4. Risk and Reward Deluxe ( Counting comments... )
  5. How We Scrum ( Counting comments... )
  6. Learning From Indie Studio Successes ( Counting comments... )
  7. Looking into the Future ( Counting comments... )
  8. Building your GUI with Gwen ( Counting comments... )
  9. The Quest for the Ginkgo GUI (2): Going for Gwen ( Counting comments... )
  10. The Quest for the Ginkgo GUI ( Counting comments... )
  11. Living With Game Reviews ( Counting comments... )
  12. Digital Distribution Woes ( Counting comments... )
  13. Thoughts On University Education ( Counting comments... )
  14. Indie Project Budgets ( Counting comments... )
  15. The Ginkgo and the Unanswered Questions ( Counting comments... )
  16. Rules We Don't Break ( Counting comments... )
  17. Ginkgo's Game Loop ( Counting comments... )
  18. Growing a Ginkgo (2): Components ( Counting comments... )
  19. Growing Ginkgo Pt. 1: The Reading List ( Counting comments... )
Advocacy / Business / Game Design / Technology/ Code /

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?