IGDA Leadership Forum: Sega Australia, Zynga Discuss The Agile Way

At the IGDA Leadership Forum in San Francisco on Thursday, two developers from Sega Studios Australia and Zynga East spoke on adopting Agile practices in game development, and pointed out pitfalls and possibilities. The two speakers, Sega Studios Australia producer Kim Sellentin (who has worked on the Total War and Sonic series) and Zynga East's Ike Ellis (who worked at Big Huge Games prior to FrontierVille) both share an admiration for Scrum and Agile processes, but had plenty to discuss about getting the formula right. "The truth is, adopting Agile/Scrum is hard," Sellentin said. "I'm here quite simply because I believe in Agile and I wish more of us did. We adopted it because of failure... It's common for Agile adoption to start off the back of a failed project. It's easy to see that something needs to change," she continued. Sega Studios Australia started with a hand-picked, cross-discipline pilot team consisting of two programmers, an artist, a designer, and a QA member. This pilot team booted up a project and now moves to other teams to help convert them over to Scrum. Unfortunately, she says, they booted up Agile at the studio before attending Scrum certification courses -- which she says are essential. "We didn't know nearly enough about it to begin with." "Don't wing it," agreed Ellis. "I've done a couple of Scrum rollouts and the first one was an epic disaster." The Why In It "Just knowing what to do and the steps, won't tell you why" the steps matter to the project, he warned. He also cautioned attendees to "do it the plain old vanilla way" the first time before adopting modifications to the process. While it incorporates a great deal about process, said Sellentin, "Agile is actually a mindset and an approach to leadership." The project leaders learn how to listen to the team's needs, becoming "servant leaders", and that's important to the project. Scrum also opens up members of the team to autonomy, and, Sellentin said, 
"there is so much leadership on your teams and you just don't know it yet." "When you're starting off with Scrum you're going to run into a lot of misconceptions about what you're doing. One of these is that scrum brings unmanaged chaos. This is really off-base," said Ellis. Tools To Use "You'll know what people are doing at a good level of detail and, more importantly, the people doing the work will know what they're supposed to be doing." However, it does create more management overhead -- the producer has to be totally aware of all tasks and progress on all tasks, for which Ellis relies on an Excel spreadsheet. "I've tried a bunch of things for a backlog, but I always come back to Excel." With the help of version control and some macros, it is the best tool -- he totally dislikes all custom Scrum tools he's tried for one reason or another. He also believes in using real boards and cards at meetings, because "as you move that card, you need to think about it, and say out loud, 'this is what I did and this is what I am going to do'. At that time, he said, everybody else thinks about that task -- if only for a moment -- and may see a way to improve on it, or a flaw in the logic. "That one second of thought just saved that person four hours that day, or a week -- or who knows?" While Scrum is full of process, the "secret", he said, is that "it's all about talking out loud. All of the trappings, what they have in common, is that they foster conversation between people who know what they're talking about." Cross-Disciplinary Conversations When Ellis evaluates a new process, he said, "I put it through the conversation test." Automated tools "are missing those key moments that add unmeasurable value to this project, and this is all I care about... As long as I get these points where everybody is working together, and thinking, and talking, about why." Both speakers are believers in Scrum's propensity to put together cross-disciplinary teams. "It doesn't make sense to not have cross discipline teams if everybody is sitting in the same building," said Sallentin. Having people who work on tools, for example, work with the people who will use them, makes a big difference. Embedding QA in the team "was one of the best things we ever did," she said. "if your team is already highly successful you're probably doing a lot of Scrum things, like empowering small groups to make autonomous decisions... probably already adapting your schedules and your scope. When you add Scrum to this mix.. It exposes some of the holes in your process," said Ellis. Of course, stakeholders -- particularly publishers on milestones -- have problems aligning with Scrum practices. The terms are unusual, and so are the ways of defining success. "There, the only hope is to have a lot of communication at the beginning and really have a clear understanding between you and the publisher about what is going to happen and when," said Ellis. "Even being a publisher-owned developer, we still have problems with reporting mechanism... Just exposing them to the processes you're using right from the start and getting them on board is really key to sorting out that relationship," Sellentin said. The key to managing the whole process, said Ellis, is making sure the Scrum Product Owner is "someone on the team who knows what we're doing and why."
 "Get your goals straight, get your features straight, and understand what features support what goals... Having that logical framework to back up your decisions. There are going to be questions from all sides about your priorities and you have to be able to back them up very effectively."