|
[Certified Scrum trainer and veteran developer Clinton Keith takes a look at the state of agile acceptance at game studios, using survey data to identify common stumbling blocks, and presents here comments from developers on the process at their companies.]
Over the past five years agile terms like "Scrum", "sprints" and "test-driven development" have pervaded every aspect of development. Is agile a fad being sold like snake-oil or the savior of the game development industry? Pundits have proclaimed it a "silver bullet", capable of solving all project problems. Others see it as an Orwellian micro-management of their creative freedom.
The truth is, Scrum's simple, iterative, and discipline agnostic practices make it an attractive framework for managers and teams trying to contain schedules and budgets ballooning out of control.
The hype has settled down a bit over these past five years. Many games developed using agile practices, mainly those in the Scrum framework, have shipped. There has been more than enough time to understand how much agile can really help a game team. It's time to look at what is emerging from agile game development teams.
This article starts with a short survey that asked people to spend a few minutes describing their experiences using agile. Read the stories and judge for yourself the challenges, successes and adaptations of agile from the industry.
The Survey
Research for this article started with a brief informal survey taken in January 2010 of over 50 developers that have used Scrum for game development. The purpose of this survey was to collect a number of rated responses for how Scrum has impacted their studio in the following areas:
- Game quality
- Planning effectiveness
- Quality of life
- Project management
- Design practices
- Art practices
- Programming practices
For each area, respondents chose one of the following ratings:
1 = Very negatively
2 = Somewhat negatively
3 = No impact
4 = Some benefit
5 = Major benefit
This was followed by a series of optional questions that would provide some background information to assist in understanding the results.
The Results
Overall the results of the survey indicate that there was typically "some benefit" in most of these areas. The bar chart below shows the percentages of responses for each category.
The greatest benefits reported appear in project management, programming practices, and game quality. Art practices, design practices and quality of life areas reportedly receive less benefit from Scrum.
Disclaimer
The pool of respondents -- less than 100 -- isn't large enough to properly represent the entire industry. I suspect that many respondents were at either extreme of experience and that the "silent majority" are around the middle of range of responses.
The most valuable part of the survey comes from the written responses. The survey asked about the adaptations that studios have made to their agile process -- and their challenges with it and what they have learned. The responses that were not anonymous are credited.
I've organized some of the responses into three categories: challenges, successes, and adaptations. It's left to the reader to judge the merit and value of each response.
|
Printer-Friendly Version
"When developers talk about making a successful game, they often mention the 'great team' that made it. Great teams can form in any culture or using any methodology. They are hard to define, but some of the following points apply. Great teams: ... These attributes sound good, but they aren't the result of any process. The people and the culture of a studio enable them."
I've mentioned this before, but one of my favorite books on the subject of organizing great groups of creative individuals and leading them to do the impossible is Organizing Genius (Bennis/Biederman). [http://www.amazon.com/Organizing-Genius-Warren-Bennis/dp/0201339897] It's not exactly a book about process to great groups; it's rather a series of case studies on great groups of the past and a focus on the common elements that enabled them to do the impossible. (production of Snow White, the Manhattan Project, etc.)
Again, thanks for the data and also thanks for the framing in relation to organizational behavior points towards the end. Cheers!
Thanks for a great article!
Thanks!
Brandon - That went over my head! ;)
Tomasz - Scrum is actually a discipline agnostic framework, not a "software methodology". Granted it's been mostly used by software development, which is why the game specific focus requires sharing this info.
Ricky - Not every response reflected success with Scrum! In fact, adaptations are necessary for what works and what does not.
Even though we managed to pull it off, and then some.
Next monday our first sprint starts, our backlogs are I think pretty tight, but the first one will mostly revolve around testing the water... and getting a First Playable running.
It's a bit tricky to figure out how much time each task will take, even when divided into smaller tasks. But like everything it should come with experience.
Great points, great read. Thanks.
1. Size of the project (team, budget, schedule) they used agile
2. Did they use all agile process, or a mix between agile and scheduled macro planning
3. Size of studio
I find it interesting that a lot of the negative comments seem to revolve around some variation of "we had trouble doing it right" so I wonder if given a few more years of using Agile these ratios would move more in favour of agile as people learn to use the methodology well.
I also agree about it being discipline agnostic...I wonder if artists are more resistant to change in process or some other reason explains why it didn't work so well rather than just "our artists use scrumbut".
Is relevant to this post
Christopher - Agreed. Fully.
Robert - Yup. The focus should change from "The Plan" to "Planning", not to "No Plan". I tried to say that in the "iterative and incremental death-march" section.
I do wonder how long these companies used scrum though. I was fortunate to be in a panel on gaming AGILE two years back in Pennsylvania. There were a few things that I still remember from then, (1) AGILE is one of those methods where it would take one to two years before the fruits of the labor are really shown. That most companies will try AGILE for a month, see that their production is dropping due to the change in style, give up, and go back to the old ways. But if they ride it out for that year or two then they would see really improved results. (2) There are A LOT of AGILE teams that THINK they are AGILE just because they read one book about SCRUM. That was from a person who was a certified scrum master, as the topic came up about one game designer's personal experience: His meetings would be 30 to 45 minutes long. The entire panel got on the fact that the meetings should be no more than 15 minutes and it didn't sound like the designer's scrum master actually knew what he was doing (it wasn't SCRUM). Personally, I always thought SCRUM was a different methodology than AGILE, but as the years go on it seems people are merging the two methodologies.
Great points. Some agile practices, like test-driven development can take years to manifest measurable benefits. Others, like Scrum, can show gains quickly. For example, the practice of reporting impediments daily produces benefits *if* they are addressed.
Agile is really just a set of four values and twelve principles outlined here:
http://www.agilemanifesto.org/
Likewise Scrum is just a framework. A methodology comes from the collection of all practices that a studio uses.
The bottom line is that the goal isn't to "be agile". It's to achieve a state where teams continually improve how they work together and create games. Personally, I don't mind if they do that by sacrificing chickens during the full moon or whatever. I just find that Scrum is a simple framework, whose principles help teams achieve this state more readily than any other I've seen. However, like chess, Scrum's practices are simple to learn, but it's hard to get good at.
Never do the same task, in the same way, 3 times in a row. After the two first times, you should have a better solution if you take a while to think about it.
I also found it interesting that the art responses seemed to be very middle of the road. I would have expected more negative responses there. I keep hearing how prototyping, pipelines and asset production don't lend themselves to Agile/Scrum for several reasons. In my opinion, if you try hard enough, you could think of just about any sized abstract goal in chunks of 2-3 week sprints or 3-4 month releases - including prototyping, visual targets, outsource deliveries, and even mass production pipelines. I like to think of it as never going more than a few weeks off the rails; using frequent course correction and proper customer/proxy involvement. Hardly a bad thing for any discipline.
Scrum is a nice thing consultants can sell you so they can make money. There are no silver bullets. Be wary of those who claim otherwise.
And true TDD is beyond moronic is so many different ways...
SCRUM is supposed to produce productivity gains by "freeing" the developers - but freeing in this case means stringing them as much as possible with a set of rigid rules. You *have* to spend 15mins per day standing and talking briefly about a couple matters that each of you consider relevant/urgent, you *have* to fraction sprints as much as possible to give everyone a micro-goal achievement feeling (a bit like Super Mario Bros checkpoints), etc. When exactly did "adaptability" got dissociated from "efficiency"?
Sure, it can provide some gains for teams with little initiative and pro-activity, but SCRUM won't add anything but discomfort to any small sized and self-sufficient team. This is built by leadership, example and culture, not by any kind of project management methodology.
The more I think about it and get experience in the industry, the more sure I am that the best Project Managers are the ones-that-don't-get-in-the-way. The silent, almost fatherly types that discretely feed producers and other leaders with info and rapidly adapt planning to their feedback. All project managers that take "boss roles" are evil, especially the ones that decide to show off and justify their big-bucks earnings by applying exotic and stringent methodologies that just help getting people annoyed. "Annoyed" to put it lightly.
Like someone else said above, a flexible, adaptive and iterative (ie. good'ol common sense) waterfall system works fine as long as the team is tight and properly led - that is, by example and interaction, not by some magic-rules strings.