Sponsored By

Transitioning to Agile Part 5 - Convincing your team and publisher

Adam Moore details some of the lessons he's learned transitioning from traditional waterfall project management to agile project management. This fifth article focuses on communicating the value of scrum and agile to your team and your publisher.

Adam Moore, Blogger

December 21, 2015

3 Min Read

If you’re interested in transitioning to agile for your next game project, I highly recommend it. I was initially skeptical towards using scrum in an educational environment because I bought into some myths about agile and scrum. I learned a lot about not only agile project management over the last couple months of studying and implementing it, but I’ve also learned that a lot of my previous assumptions about the right way to manage and design game projects was not only flawed but had been a primary cause of failure on some of my past projects.

I also highly recommend Clinton Keith’s book (down in the references) and his ScrumMaster training course that is designed specifically for game developers. Most certification courses and trainings for Scrum are focused on the much broader subject of software development and there are some unique difference between business applications and games.

For your first attempt at using agile for game development, I recommend implementing Scrum by the book on a single team. This team can showcase the benefits of agile development to the rest of the teams and the members of this team can train new scrum teams once they build up experience.

If you need to convince the rest of your teammates of the value of agile development, possibly the best advantage agile has over waterfall is that it uses fast iterations to reduce project risk and increase the value of games worked on. Agile helps you address risk by quickly identifying the user stories that address schedule risk and prioritizing them. The other way that agile helps reduce risk is by not postponing debt. Everything that the team commits to developing is debt. If the team commits to developing a game with 5 playable character classes, each class is a debt that the team must pay sooner or later in development. Every bug that the team puts off to fixing later and every feature that doesn’t get integrated until later accumulates debt. By integrating content and fixing bugs every sprint instead of at the end of the project, the team has a much better view of how the project is faring. Postponing debt until later hides the project’s problems until later.

Scrum won’t magically solve whatever development problems your team is running into. Scrum is a framework for software development. This means that it’s meant to be adaptable to your team’s needs. As long as you adhere to the principles and intentions behind scrum and agile, you can make as many changes as suit your team to improve the process.

Your studio may also run into some issues with contracts and working with publishers. Most publishers use contracts that want the design completed up front and specify what should be done at each milestone. To address this, you’ll want to set up an agile contract with flexible milestone definitions with your publisher. These flexible milestone definitions can be set as part of your release planning process.

References

Keith, C. (2010). Agile game development with Scrum. Upper Saddle River, NJ: Addison-Wesley.

 

 

Read more about:

Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like