When Advice Turns Out to Be a Mistake
When Advice Turns Out to Be a Mistake
No one updates their success stories with the news that it was a bad idea after all.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
I remember reading Clinton Keith’s “Agile Game Development” and getting to an anecdote about CCP Games, where I worked at the time. The following is from a Gamasutra repost of the book’s “Teams” chapter:
In the fall of 2008, CCP undertook the development of its tenth expansion pack called Apocrypha. Apocrypha was the most ambitious expansion of the EVE universe. It added major technical features and significantly extended the size of the EVE world.
This ambitious goal required CCP’s worldwide development studios to work in parallel. Features and content developed simultaneously across three continents had to seamlessly come together to achieve their goal. Normally this would be the introduction to a disaster story, but CCP pulled it off. CCP is a longtime adopter of agile methods, specifically Scrum.
In the case of Apocrypha, with more than 120 developers in 13 Scrum teams spread across three continents, 9 product owners were required. These product owners took their direction for the game from a project management group in Iceland.
I was reading this in early 2012 (I joined CCP in July 2011). Twenty percent of the company had just been laid off, a number of scandals had just unfolded, there were reorgs and more reorgs. This monumental failure could be directly traced back to the globalization of CCP’s development. Yet here I was reading about what a great model it was in the seminal work about Agile game development.
Yet, Apocrypha was pretty great. EVE Online and CCP were growing and making money from 2007 through 2010. The company, by most measures, appeared successful when “Agile Game Development” was written.
But it all came crashing down in 2011. In the soul searching that followed the layoffs, it was clear CCP was successful in spite of its globalized development and centralized management. It was so clear that the company wasted no time moving to a model where different game was being developed in each geographic location, with minimal overlap. There was much rejoicing.
Many factors went into CCP’s success at the time that were not so sexy to talk about, from the financial crisis to the insane hours some people worked. And of course, EVE Online is a fundamentally unique and spectacular game. But, the most visible change was the Agile reorganization, so management was free to hitch that wagon to the horse of success, and write articles, contribute to books, and speak at conferences.
Good Advice, Bad Advice
This wasn’t unique to CCP. Maybe you know of other times this has happened. But no retractions are ever made. No one speaks up to say, “Hey everyone, we f'ed up big time, this was a huge mistake. Please don’t listen to us, and if you made some decisions based on what we said, you should reconsider those decisions.”
You never hear when advice turned out to be a mistake. So I have developed a simple question to evaluate all the professional advice I get or read about: has this advice been tried in a difficult environment? Or has it only been used when the company has been profitable and/or growing? Anything works when you’re making money. I’m looking for a verification- or at least a strong indication- that success is because of this advice, not in spite of it.
Toyota, one of the most successful companies of all time by any measure, developed its Toyota Production System for decades before it started to train, evangelize, and formalize it for outside use in the 1990’s and 2000’s. Let that sink in before you peddle your ideas.
Published at DZone with permission of Rob Galanakis , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.