The development process behind Scrapped - Part 1 - Scrum
This post is the first of a series about the development process behind Scrapped. The goal is to record the team progress as we move through development and see how we evolved over time.
A quick summary of our project: we are a team of 14 students working in our capstone project at The Guildhall at SMU. Our team is composed of 1 game designer, 1 producer, 6 levels designers, 4 artists and 2 programmers. For two months, we also have the help of another producer from an older cohort. We have a total of 6 months to finish the project, from concept to the final build.
To start, I’m talking about Scrum, the base of our agile development process. Since creating games is an almost purely iterative process, agile development proved as the right way to go. Here prototypes say much more than documents and the game changes as the team learn about it (more on the topic here and here). New features come in, other features go out, levels are constantly iterated and a lot of things are thrown away for a very good reason: make the game fun. (Ok, sometimes we make changes based on time availability as well…).
The intention is not to describe the methodology; the goal is to show how we use it in Scrapped and highlight the changes we made to fit our needs. If you want more information on the methodology itself, I recommend reading the following books: Agile Project Management with Scrum, Ken Schwaber and Agile Game Development with Scrum, Clinton Keith.
Department and Feature Scrum
Every day we start our core hours with a traditional scrum where people tell what they have worked on, what they will work on and if they have any blockers. In Scrapped, we are trying two different approaches for these scrum meetings. We started organizing them by departments, where our three major areas (art, programming and level design) did the scrum with tasks and people only from their department. However, by the end of our first sprint, this organization proved not optimal for our project. The departments were not fully aware of what was happening in the other areas and the team had to spend considerable extra time coordinating the tasks after the scrum ended.
Now, in our second sprint, we changed to feature teams scrum. The goal here is to organize the scrum by features and allocate people from all departments in them. This type of scrum helped to coordinate tasks such as level design and art. However, because of how we separated our features, people needed to move from one scrum to the other depending on tasks priorities at that moment. This created some confusion during scrums and was also not optimal for our project.
During our next retrospective, we are discussing the problems we had during this sprint and suggesting changes to for the next spring. I will write a following-up post talking about how we adapted our scrum and if the changes helped us.
Overall Team Scrum
After finishing our daily department/feature scrum, we start a fast overall team scrum. This meeting, that usually takes around 2 to 4 minutes, helps to coordinate the whole team. Here each team member only says what they are working on that day and if they have any blockers that might come from another department. This helps each department/feature team to reprioritize tasks based on blockers reported. Also, we ask team members to report important changes made to the project that might impact other people work.
As the department/feature scrums happen all at the same time, I can only absorb chunks of each scrum. This is why the overall scrum greatly helps me as a producer; with it, I can tell what people are currently working on and rapidly coordinate solutions for blockers or priorities. Finally, these less than five minutes meetings can give the team precious information to start the day and help them to see the big picture of the project.