A Disturbing Assumption
I occasionally come across comments like this one:
I don’t agree with this prediction either way and we have tried to emphasize this in the presentations:
Agile is not a silver bullet
Some of the key points we stated were:
- There is no “right way” to make a game.
- The talent of your team is the main factor in the quality of the game.
- Agile has benefits:
- Reducing wasted effort
- Finding the fun first
I’m not saying:
- Using agile makes you a hit factory
- That High Moon has any greater insight than anyone else using agile
- We’ve just been talking about it for a few years.
- Waterfall will always fail.
As for High Moon, I’m enjoying myself. Its fun, challenging and we are improving how we make games every day. Will the next game be a hit? I don’t know. It has the strong potential but I’ve given up predicting success solely based on the development side alone. I’ve never predicted it based on the process used to create it!
Let me back that up with a look at a past project I worked on.
One game I worked on was Midnight Club at Angel Studios. It was not a game developed using agile practices which makes for good comparison.
- Fixed price, fixed schedule development (it was a PS2 launch title).
- We shipped on time and budget
- The original scope included six cities
- We shipped with two
- The last four months of development was tough.
- 72 hour weeks for most.
- The game sold 2.5 million units
- It was a success for the team and the customer
How did it succeed?
The keys to success were:
- It was a great team, especially with the technical leadership of Dave Etherton and design leadership of Fred Marcus.
- The team largely consisted of the Midtown Madness team. Vision wasn’t a problem.
- Marketing of Rockstar
- These guys were amazing. Who else would pay to close down
Times Squarefor a night to get box cover shots?
- Closely tied with talent and experience, but there is benefit to knowing your mature and adoptable technology base from the start. Adopting the PS2 was not easy though.
How would agile have helped Midnight Club?
Agile could have helped mitigate the crunch at the end. Many of us were truly burned out after MC1 and a few good people left. I don’t know if we could have turned out a third city, but dropping that city late in development had a major impact on the flow of the game. Knowing we were going to ship with two cities earlier would have reduced the effort wasted on the third and allowed the designers to adapt the gameplay for two cities.
There are two key points to summarize
- We succeeded with waterfall.
- Agile could have helped significantly with crunch and somewhat with gameplay.
Waterfall is not a blank bullet
Waterfall has been rejected largely due to the higher percentage of projects that using it fail (miss budget, quality or schedule goals or are canceled outright). That percentage is not 100% though. Process contributes to but does not determine success.
The point of agile means you shouldn’t accept or reject it blindly
Agile methods use an iterative approach. You are constantly in an “inspect and adapt” cycle. This applies to products, teams, whole companies and even the process itself!
Frameworks such as Scrum or XP suggest practices that support the “inspect and adapt” cycle. What you do with the results of your inspection is up to you. If you find yourself inspecting how teams work together, including everyone in how the operations of the company can be constantly improved and trying to honestly ask yourself if the projects are headed in the right direction on a regular basis, then your shouldn’t care about High Moon’s games!
Scrum is self modifying in nature. If you aren’t achieving the results, then change the process! Just try to preserve the principles though. Too many scrum adopters remove or ignore the principle of change to their detriment.
High Moon’s Next Game
Regardless of the success of failure of our next game, I believe that we are better off using agile to develop it.
If our next game is a hit, does that mean you can do the same by just adopting our practices? No! It means that we had the talent, technology and marketing to make a successful game. If the game fails, we will not blame our process, but ourselves.
The goal is to compete with each other on the basis of talent and not the illusion that we are competing on the basis of who has management that can make their people work longer hours.
Building your studio culture to never be satisfied and to improve your games and how you make games is the ultimate goal. When I read articles like this, I get anxious to help build a culture like that. The irony is that you can't impose this kind of culture. It has to be grown though trust and ownership at every level. These are principles which were used to create agile. Agile can contribute to culture, but it's just a part.