On the Prevelance of Scrumbut in Game Teams

March 1, 2014 — 2 Comments

“Yeah, we’re doing Scrum but…”

Speak to nearly anyone in the games industry about their Agile implementation and this is what will come out of their mouths. It’s also a prevalent issue in Scrum adoption in other software creation industries. Leading to the term ‘Scrumbut’ being coined. It seems to signify, particularly in the long-term that a company has chosen to adopt Scrum, usually because they think it will fix some problem in the development process but has hit snags fitting their existing process into Scrum so they end up adapting the methodology they want to use rather than the process they want to fix. Then typically a project fails, the process is never fixed so the same problem rears its head and tears are shed. The collective take away often seems to be that Scrum didn’t work because it didn’t fix the problems. In reality it was the company or project that failed because they didn’t fix their own problems and saw/were sold Scrum as a magic bullet.

That said for any existing company and project there has to be a transition period between the previous way of working and the full adoption of a newly chosen Agile methodology. Many of the technical parts of Agile methodologies have a non-trivial amount of work to implement. For example setting up a continuous integration process and the suite of automated regression tests it runs. Further you can’t just bodge an existing set of processes into Agile methodology de jour and expect good results. Agile implementation is as much a reworking of culture as it is process. Any good Agilista will tell you we should be favoring people and interactions over processes and tools and the change in a companies working culture is probably the biggest impediment to changing process. In my experience this culture shift can’t just be a top down endeavour or a bottom up ‘revolution’ but something that is embraced at all levels and given adequate nurturing. This shift is ultimately about trust. Executives must be willing to let go of a strong command and control structure and developers ready to be open and honest about any problems they face so they can be addressed in a timely manner. The cultural shift to Agile also needs to extend to external partners/customers as working relationships will almost certainly need to change. For example you need a much more collaborative working relationship with your customer (but you know that it’s a tenant of Agile!) which for a lot of game developers means working closely with a publisher, a working relationship that doesn’t exactly have a reputation for trust in either direction! Everyone needs to have at least understood the Agile principles and what that means for their working relationship.

Some of this can result in some odd Catch-22s.

“We want to release more often but we don’t have confidence in the build, so we want to setup continuous integration, but we don’t have any regression tests, but we’re too busy working to ship the build to write them.”

Worse still there don’t appear to be ready, easy answers for how to transition any particular company or culture to any particular Agile methodology nor are there many/any games companies talking about how successful they have been. At best the advice seems to be ‘use this to fix your problems don’t expect them to magically disappear’.

In games the default methodology adopted appears to be Scrum which for a lot of reasons does not appear ideal to me for the totality of the lifecycle of a game. Games have distinct phases in their lifecycle, we don’t typically build out all the levels when the core gameplay is still being worked on extensively because it’s wasteful and we can look to Lean manufacturing to see some good discussion about why this is. Further some bits of game development like content creation which are much, much larger than in other software projects don’t really fit into the Scrum model. Games are very often boxed products or built as such and not sold as services so there needs to be a planning phase, however short and high level in order to set a clear vision, goals and build an initial product backlog. There are lots of fiddles like Sprint 0 added to Scrum to try to cope with these problems but to my mind Scrum needs to sit within a larger framework. Further Scrum doesn’t seem to scale very well beyond small teams and games projects are often huge in comparison to the ‘Scrum sweetspot’.

The really good news is that games development isn’t a unique snowflake in finding Scrum a bit lacking. In fact looking at data from the likes of the Ambysoft Surveys it’s easy to see that large teams in general are finding Agile adoption hard and that a lot of the barriers are very similar to the ones mentioned above. There are lots of other methodologies out there like Disciplined Agile Delivery that although not targeted towards quite the same projects as games try to deal with the larger complexity and team sizes found in enterprise IT projects. Whilst I don’t think they show the way out for games projects interested in Agile they definitely show the direction we should be looking towards.

2 responses to On the Prevelance of Scrumbut in Game Teams

  1. 

    So they want agile but aren’t prepared to sacrifice anything today to achieve it. Maybe they expect change to be free or nobody identified the costs?

    • 

      Yeah I think very often people don’t see the upfront cost to change. I also think Agile and Scrum in particular are sold as magic bullets to solve project problems so people expect by adopting the methodologies trappings they will fix the underlying process problems. In the end I think this actually does a good job of highlighting the process friction points but very often this is seen as ‘Scrum failing’ rather than the company failing to fix their process. Basically I think that if you’re institutionally incapable of fixing a known problem in your process that adopting Scrum is not going to help you out. 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s