A 1st-hand description of doing Scrum/Agile correctly (in games industry)

Let’s be honest: many games-industry teams/studios abuse Scrum. Then, after months of pain and suffering (and poor project-progress), the team members go to other teams or companies, and take a hatred of Scrum/Agile with them.

So it’s interesting to hear from people who’ve made the transition from “Agile/Scrum done wrong” to “Agile/Scrum done right”.

Quotes I’ve heard repeatedly:

  • “It doesn’t work”
  • “It’s a load of corporate-trainer bullsh*t”
  • “It works for industries that have no uncertainty in their design; but in games, you don’t have a spec to start with”
    • [this is depressing; it’s where Scrum shines – but people have mis-applied it so much that they’re getting the opposite result]
  • “Have you seen how easy it is to become a Certified Scrum Trainer? And how much they get paid? It’s just a big con”
    • [IMHO the ScrumAlliance has a lot to answer for, in how they’ve allowed this problem over the past 5-10 years. It seems to have been a strategy of short-term gain (more practitioners) for a long-term loss (reputation and quality of practice)]
  • “In Scrum, you have to do a 2-3 hour meeting every day, where everyone on the project gives a full status update, so we never got any work done”
    • [I’ve heard this worryingly often. It’s stunning that anyone could allow their Daily Scrum meetings to go so wrong]
  • “Scrum is all about equal authority and shared responsibility, but some (our manager) are more equal than others, and never responsible for the failures”
  • “Agile is where you can do anything you want and when someone on your team is lazy and claims everything will take 10x the actual time, so they can do no work all day … you’re not allowed to disagree. Because Agile/Scrum says you can’t disagree with each other”
    • [Again, I’ve heard this often. Did these teams accidentally read the Black Bible of Scrum? The one where everything is inverted?]

This came up on a forum today, and one of the posters chimed-in with their own experiences. The forum’s private, so I can’t link to it, but I’m reposting their summary (with permission):

“I’ve done scrum/agile 4 times in games.

Work does 3 week sprints and is now split into 2 teams so we have 2 scrums a day. Time of this is strict, on-time and 15 mins long*.

Our Producer/Product Manager only sees the program in the Sprint meeting. The entire team is in the Sprint meeting also, which is now pretty good. The Sprint meeting lasts the whole day. So that’s 6-8 hours every 3 weeks*.

The morning is broken into what we did in the previous Sprint. We demonstrate each story and if we tick all the requirements defined in the story it gets marked as complete. If we don’t complete it, we say why and a new story gets made with what’s left. This is only if it is still required and may be put into the Backlog and done several Sprints later.

The afternoon is spent deciding on the next stories. These have been defined by: the Customer Requirements/Publisher/Whatever, the Producer and the Leads. The 2 teams break off and the whole of that team decides the requirements AND the time it will take. This prevents the wasters on the team getting away with poorly defined requirements and giving a time that is clearly taking the piss*. It also covers people underestimating. The peer-pressure means people work because next Sprint people have to explain why it wasn’t finished when everyone decided on it. If no one can decide on the time then it clearly hasn’t been defined well enough*. It helps because the team works closely together and they all understand those parts.

We can ask the Product Manager questions at any time etc, but like I said: he never sees the work in progress for 3 weeks. He also never comes in and changes things*. Because it’s the whole team plus the Producer/Product Manager agreeing on things, features gets dropped when needed, priorities get sorted, and blame can be removed from the development cycle*.

There are various other small details but that’s the main bit of it.

If you aren’t doing these things in scrum/agile then really you’re just wasting people’s time and giving waterfall development the wrong name.

* All stuff Game Development scrum failed to do in my experience.”

Leave a Reply

Your email address will not be published. Required fields are marked *