Gamasutra - Introducing Scrum At Large Animal Games: A Look Back at the First Year of Agile Development

Introducing Scrum At Large Animal Games: A Look Back at the First Year of Agile Development

[NY-based developer Large Animal (Rocketbowl, Snapshot Adventures) switched to the Scrum method of agile development last year, 'sprinting' to complete individual game elements - here's just how it went.]

Large Animal Games has been in business in New York City since January 2001. For the first several years, Large Animal developed games using informal, homegrown software development methods. "We did a lot of experimentation," says Wade Tinney, co-founder of Large Animal.

To track project schedules, for example, teams at Large Animal tried using MS Excel, MS Project, FogBugz, and even tried different visualizations of the project schedule using Adobe Illustrator and Visio.

Despite success with some of their practices, teams at Large Animal were still looking for improvements. Some of the things they tried had worked in theory, but felt forced. It was hard to motivate all team members to stick to some of these processes.

More critically, Large Animal was finding it difficult to grow, since a set of key team members were needed in certain roles on every project. While these key team members added a lot of value, they were a bottleneck limiting the number of projects that Large Animal could have running simultaneously.

In early 2006, Large Animal discovered agile development (and Scrum more specifically) and began incorporating some of the techniques into its project teams. Encouraged by the discussions about agile development at GDC 2006, Large Animal started holding company-wide meetings every morning.

As Wade describes it, "At first we had each person in the company talk about what they were working on. Over time we changed the format of the morning meeting so that the order that people spoke was grouped by project. As we added more people, we started having one person from each team report to the group."

Aside from this daily company stand-up, teams were still operating as they had been. The transition to a more complete implementation of Scrum started with a low risk pilot project that had a flexible time line. This project team would have their stand-up meeting, with a Scrum board, during the company-wide morning meeting.

This gave everyone an opportunity to observe, ask questions and comment on the process, which helped spread knowledge of Scrum throughout the company and helped share learning between teams when additional agile projects were started.

Today, all active projects at Large Animal use Scrum. The rest of this article describes some of the key successes achieved at Large Animal and some of the challenges that remain.

The article assumes that readers have a basic understanding of agile development and of Scrum in particular. For those readers who need a refresher on the fundamentals, Rory McGuire's Gamasutra article, Paper Burns: Game Design with Agile Methodologies, is a good resource.

Even before adopting Scrum, project teams at Large Animal had always possessed some traits of agile development:

This core culture at Large Animal helped smooth the transition to more formal agile techniques. Embracing agile development has impacted many aspects of Large Animal, enabling them to grow and develop as a company and to strengthen their relationships with publishers and other partners.

Comments

Arseny Lebedev

29 May 2008 at 8:18 am PST

When I started here I had never heard of this method. The Scrum process is definitely rewarding and a good way to get everyone on the team involved. I also like it because it increases project transparency.

I think the only downside to the way we use the method is that sprint planning meetings tend to last the entire day. We have been experimenting with spreading planning meetings throughout the week, but it's difficult and a development point.

Piotr Zygadlo

29 May 2008 at 9:44 am PST

When reading about Scrum in game companies, I'm always interested if they had ever tried another approach. If they tried to learn other metodology. Because here I see just "we tried to use different tools, but we choose to use this metodology".

Very interesting article as exaple of agile in games. I have something to think about.

Tyler Thompson

30 May 2008 at 9:17 am PST

At Flagship Studios, we do our sprint preparation meetings throughout the last week of a sprint to prepare for the next sprint. We limit them to a one hour per meeting at the end of the day. We usually have about three or four of these meetings per sprint.
Since we get a lot of the stories thought through during these meetings, our sprint planning meetings last about an hour and a half.

Raoul Duke

2 Jun 2008 at 3:57 pm PST

@Time estimation.

The best thing I've seen is to estimate with a probability function instead of a single value. Ask people to give 50% and 80% confidence values. This will give room for "I'm not sure, if all goes well it could be 1 day, if things don't align it could be 2 weeks". You then take the confidence ranges and use those to put buffers into the schedule. It worked really well the one time I got to use it.

Seth Spaulding

3 Jun 2008 at 10:11 am PST

Has anyone found that there is a limit to the size of morning meetings beyond which the meetings become ineffective? If so, how do you break them up?

John Tynes

3 Jun 2008 at 3:19 pm PST

Piotr:

At Flying Lab, we used the Critical Chain methodology for a couple of years. It is primarily used in manufacturing and we found that it could not scale as our team grew to 70+ people with hundreds of tasks in a milestone. I replaced it with a very lightweight version of scrum that worked well for our project.

Jobe Lloyd

5 Jun 2008 at 9:43 am PST

I transitioned our team to Scrum from a pretty standard "waterfall" approach at Perpetual, the result was very successful. I think the reduction in excessive BUFD alone made the process a win for us, but there were so many other benefits.

Great article, very similar to our end state at Perpetual.

Cameron Royal

26 Jul 2008 at 10:31 pm PST

@Seth Spaulding

We had a scrum team with 12 people (11 pigs, 1 chicken) just recently, with a mix of artists and developers. We found it useful to split the morning standup scrum for the whole team into two consecutive scrums, with key individuals on both. This kept the scrums short which is important for maintaining focus but still allowed any blocking factors between staff to be resolved.

@Scrum From the Trenches

"Scrum & XP From the Trenches" is a brilliant read, and can be downloaded from the authors website for free.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

evden eve nakliyat

10 Aug 2008 at 3:42 am PST

Congratulations! We had the same ideas about childbirth as you did and ended up much the same way. C-section after 2 days of labor, anesthetic wearing off 1/2 way through the c-section. My wife, who's a hospital pharmacist, having to tell the anesthesiologist what drugs to give her while she's lying on the OR table. But the end result is the same, you forget it all once you hear that first cry.
http://www.nakliyatankara.com