The statement above will provoke outrage and bluster in many Producers and Programmers. It’s an assault on an unassailable truth they hold dear, and like most statements that provoke impotent rage by attacking widely held beliefs, it also happens to be true. The things we believe in, should be open to scrutiny so that they can be improved. The Agile manifesto isn’t a sacred text (despite the level of reverence some hold it in), it is a document written in a lodge by a group of (possibly grumpy) Senior Developers who were fed up with Waterfall development and Managers “interfering” in their work.
At some point in the early-2000s game developers found the silver bullet which overnight was going to resolve all of their development woes. Agile development, and specifically Scrum was going to fix everything.
Schedule overruns were going to be consigned to the dustbin of history, crunch would magically end, and interfering Project Managers would be replaced by ScrumMasters whose role it would be to subserviently facilitate the team’s work whilst wielding no authority.
Something like a developer’s idea of heaven would dawn and all would be well.
Despite widespread adopting of Scrum and millions spent sending developers and managers to Scrum training workshops, none of this happened. Delays still occur with most major releases (GTA V PC anyone?), according to the IGDA’s 2014 figures 81% of developers still crunch, with some 38% of the IGDA’s 2014 respondents reporting typical crunch times of 50-69 hours per week.
(Given the lack of tangible results, what could it be that’s attracting seasoned developers to quit their demanding day jobs to lead Scrum “training” sessions charging participants several thousand dollars per head to attend?)
Utopia did not dawn, even though many PMs remain convinced that if they just follow the book closely enough it will do… below is just a small subset of big issues with Scrum and why it isn’t actually a particularly smart way of making games:
With great power comes no responsibility
Scrum dictates that the team should be responsible for the planning and execution of work, with no outside interference from the Product Owner (the person who’s actually accountable for shipping the game/feature) beyond setting priorities and direction.
In essence this creates a situation where the people planning and doing the work, are not held accountable for its success or failure, and the person who’s accountable for it can’t “interfere” in how it’s done. So if the team misses their deadline, there’s no accountability or repercussion, and the person who is accountable for the failure had no say in how the work was done.
Anyone who’s accountable for a piece of work and adopts this approach is either a) working with the most reliable team in history or b) asking for trouble.
A person (PO or otherwise) who fails to deliver on their responsibilities while entrusting all of the planning, oversight and execution to other people is guilty of nothing short of negligence.
We can’t all be rockstars
Scrum relies on developers being able to accurately predict the complexity of their tasks and how many of these tasks (based on their complexity and their previous workrate) they can perform within a “sprint” (usually 2 weeks), at no point should the PO impose deadlines. The team knows best what a reasonable amount of time is to deliver a feature, and no outside interference or deadlines should come into the picture.
In terms of finance, most of us can’t even predict exactly how much we’re going to spend within a two week window, despite most of our costs being roughly the same every month, let alone how difficult a new task with multiple interdependencies and external factors might be.
Unsurprisingly, this problem gets even worse when you start introducing Junior Developers into the mix. At this point the planning can become so bad, that an experienced PO might (secretly) start adding a 200-300% buffer into the team’s tasks, communicating one set of earlier intended dates to the team, whilst communicating a different set of expected dates (with the 200-300% buffer built in for management) to ensure they don’t get burned by the team’s inability to accurately estimate their work.
Scrum also relies on the team being “self-motivated” and always striving to deliver 100%. Anyone who’s ever been on a large team, and then seen the team continue to deliver the same (or even greater) output after several members of the team were reassigned to other projects, will know that this isn’t the case. In any large organisation (and in some small ones), there will be people who will try to “hide” and get away with doing the minimum, leaving their colleagues to pick up the slack. The larger the team, the more of these people you will be carrying, and Scrum gives these people the perfect “get out of jail free card” when they do fail to deliver.
To top this off, teams are supposed to be “self-organising”. Outside forces don’t tell them what to do, and the workers collective will join together to establish the most efficient and effective means of production. Without leaning on crude stereotypes, it’s not a stretch to state that many developers don’t have particularly strong social skills. So, putting a group of developers together and asking them to take collective ownership can often result in no-one taking a strong lead and a lack of communication and coordination – many developers will try to avoid treading on each other’s toes or being seen as telling their peers what to do. Again, this problem becomes more acute when you inject a higher ratio Junior Developers into the mix…
The standard response from Scrum advocates to these complaint is that “Well… you can’t expect tot achieve anything with a high ratio of Junior Developers”, which is:
- Unrealistic: Not every company has mountains of money to spend on Senior Developers, or even if they do, the ability to attract them.
- Counter-productive: How are you supposed to be developing your next group of Senior Developers if they don’t fit within your idealised version of a dev team?
- Self-defeating: Junior Developers bring fresh ideas and energy to the team. Having a good balance of Juniors and Seniors is essential to having a harmonious and enthusiastic team.
Here’s another dirty secret… Not everyone can or wants to be self-organising. Many developers are much happier and productive when they don’t have to worry about leading or owning features. Many of us who have worked in teams that transitioned to Scrum will have heard developers complain about the Scrum process and how they are not comfortable self-organising or taking ownership of features.
If you’ve worked in continental Europe, or even more so Asia, you will also have seen that the assumption that everyone wants to be a stakeholder or own part of the responsibility for delivery is rooted in Anglo-Saxon (and specifically, American) cultural bias. Not every developer wants to be “the boss”, many just want to focus on their craft.
Some people will be more productive if you allow them just to focus on what they’re best at doing. Why not let these people focus on what you hired them to do in the first place, rather than try and force them to try to be something they’re not?
Not all disciplines lend themselves to iterative development
Even if all your programmers, QA and Designers can work perfectly in Scrum harmony, other parts of your production pipeline will not. For example, building 3D assets is very much a waterfall process with clearly defined stages, inputs and outputs. Trying to shoehorn this into an iterative approach for the sake of consistency (or dogma) will not make you faster.
If you look at the history of the Agile Manifesto, it was authored almost exclusively by B2B application programmers and coaches, so it’s perhaps unsurprising that it’s entirely skewed to the needs and desires of Senior Programmers, and won’t necessarily meet the needs of other disciplines.
The failed PM’s shield
Your ScrumMaster is not a Project Manager, and as such is not supposed to guide or direct the team, even if they’re misfiring. This is the perfect shield for weak PMs, as they will have the perfect excuse to hide behind the team and not take ownership when the team is consistently failing to deliver. As mentioned above, the team holds the responsibility (but not the accountability), so there is no recourse here. In practice a good SM will throw this out the window and step up and start challenging the team when they’re failing.
If you can’t react, you’re toast
Scrum dictates that the Product Owner can’t change the content of a “sprint” (usually 2 week’s worth of work) once the team has committed to it. In order to change, they’re supposed to stop the sprint, redo all the planning and start again, even if the team has built a buffer into their estimations. As anyone who’s every worked on an online game (or any online service for that matter) will tell you, this is simply not a viable way of working and in the realm of fantasy.
Imagine a scenario where 1 day into a sprint, a serious exploit surfaces in live. It needs to be fixed yesterday or the damage to the game’s economy will be serious and long-lasting. Would a PO worth their job waste valuable hours (with the exploit still live) stopping the sprint, re-planning all the work for the next two weeks and then getting the team to self-organise and reassign the stories? Or worse still, wait another 13 days until the end of the “sprint”!?
No, the PO will put the relevant people on the issue ASAP, reprioritise their other tasks, and hope that the team will still somehow be able to deliver most of what was agreed for the sprint.
When you’re operating a live game your development methodology needs to be able to adapt to the needs of the business, not the other way round. If you prioritise development best-practice over your core business needs, then you’re destined for the dole queue.
You’re not praying hard enough!
Sometimes terrible things happen to good people. Someone who is of a religious disposition can be struck down by a sudden illness or a tragedy (self-inflicted or otherwise). Rather than focus on the issue itself and its causes, these people will instead blame themselves for not having prayed enough as if their faith were the actual root of their issue.
Similarly, things will inevitably blow up in your game development at some point; in a Scrum environment this can often be perceived as a challenge the development approach. The stock response by Scrum advocates in this scenario will be to proclaim that the team “wasn’t following Scrum enough”, and that the solution lies in a more rigorous adherence to textbook best-practice.
This response doesn’t take the time to analyse the problem and its causes in depth (Toyota’s famous “5 whys” is a great way of doing this), and unless the issue is specifically a problem with your Scrum implementation (which more often than not, it isn’t), you can be certain the problem will resurface at a later date.
Rocking in the real world
The real answer (like so much in life) is to not blindly follow any one set of rules blindly.
Every single team and project is different and will have different needs. The best Project Managers will adapt their approach to their team and combine the best bits of various different development and Project Management methodologies.
Despite all of the above, there is a lot about Scrum that is laudable and generally works well for dev teams (iterative development, constant releases, sprint cycles for development, etc.) just like there are aspects of PMP, PRINCE2, Kanban, Lean, and other Development and Project Management methodologies that also make a lot of sense. However, blindly applying one catch-all approach to developers of all shapes and sizes with differing needs is doomed to failure, and ironically, goes against many of the principles Scrum is supposed to embody (people over process, agility and pragmatism).
The simple fact is that there isn’t one method that will work for every game and team. Anyone who says so is either grossly oversimplifying things, deluded, or trying to sell you a 3-day course for $1,500.