I’m a huge advocate of scrum and agile project management, but there are a lot of snake oil salesmen out there that really don’t know jack shit about Scrum and have had a 2 day training but no real project experience, know less about Agile theory as a basis of why Scrum is what it is and can’t even spout the Agile Manifesto on command (sorry you HAVE to be able to do this if you think you know agile software development) and a lot of companies that try to dip their toes into it and get burned because they do not by any definition understand the fundamentals. That said, a lot of game companies are moving to the scrum model, some Blizzard folks were at my training in March with Mike Cohn, and I can only assume Torchlight was managed via some form of scrum (I’d be very curious to confirm this if anyone knows). So game companies have had success with the methods.
With the disasterous failure of the initial release of Elemental War of Magic basically tanking the game for now and the future (who will care about this in 18-24 months when it’s fixed?), I want to know if it was a game company trying to do Scrum for the first time, assuming that the rapid development and approval cycle would lead to a good game? It’s tough to tell, but with the constant releases of screens and gameplay to the public early on, I’m betting this was a factor. It’s not THE factor though: granted you had the owner of the company working as a developer, designer and product owner for the game per his admittance (honesty is nice to see in the industry), and that would taint any type of project method, whether waterfail or scrum. Who on his team would tell him–” boy boss, this game sucks bad and is fundamentally not fun and lame and you tried to copy a game design from 1994 that sucked in the first place?” Only someone who is quitting that moment. What’s more, because the team may have been doing scrum, team member happiness can be at it’s maximum possible during the development process– adding to the “this game will be great” pollyannishism because team members know what they need to do, what the goals are and have a massive level of autonomy to get their shit done (this makes good developers happy and the bad quit and go somewhere where they can be mediocre together with others via the Waterfail method). We’ll have to keep watching to see if any clues drop as to their development methods. Oh and see Keneda’s review here.