If I had a dollar for every time I heard “SCRUM But” mentioned I would be a wealthy man.
In my role as a Senior Production Expert at Hansoft I daily meet producers in the games industry, discussing production practices. Increasingly often I notice that “SCRUM But” seems to be an umbrella where bad practices are hiding. The “but” usually means some or all of the following:
- We do SCRUM, but management plans the sprints for the teams, because sprint planning meetings tend to take a lot of time.
- We do SCRUM, but we don’t do daily stand ups, because there’s usually no important information discussed in the meetings.
- We do SCRUM, but we don’t do retrospective, because we don’t have the time to handle the output from the meetings.
- We do SCRUM, but we don’t manage our backlog because things change all the time and it takes too much time to manage the backlog.
- We do SCRUM, but we don’t do sprint reviews because there’s usually nothing to review at the end of the sprint.
- We do SCRUM, but we can’t have sprints uninterrupted because there’s so much feedback in that needs to be managed on a daily basis.
If many of these statements are true in your studio it’s a stretch to say that you are running SCRUM. That can work perfectly fine as long as you have some well-defined way of working, a tactic that all team members are aware of and are following. The title of this post refers to a highly unorthodox formation, 1-6-3, played by the Japanese soccer team in the 1936 Olympics. This Japanese team beat the Swedes by 3-2 before suffering a large defeat versus Germany. Bringing a player into this team was probably a difficult task. Most soccer player would have no clue on how to play a 1-6-3 formation and would need quite a lot of instructions, whereas any player would understand the broad strokes of a 4-4-2 system within minutes.
The benefit of using a well-known method is that less time is needed to instruct the team into how it works.
The game industry has always suffered by the “not-invented-here” syndrome. In my experience this is one of the main reasons why it has been so difficult to bring in SCRUM as-is. We feel the need to come up with a method that works better, but due to the lack of time (see The producer dilemma for elaboration) we rarely get there. Developing a new method has a high cost associated to it. First it needs refinement, and for that you will need to fail a number of times. Secondly, no matter how good it is it won’t work unless the team masters it.
But the wise man then says; who needs a method, we can just do it!
Yes you can, but how well does a team play with no tactic at all? It can work in the lower leagues, but if you intend to compete at the highest level and don’t have a sheik pouring money into your team you need to find a way of being smarter than your competition. Today, a well-executed SCRUM implementation is just that.
The point of this post is not to praise the greatness of SCRUM. I have no doubt there are a million ways you can be smart when building a game, and firmly believe in running a methodology that is comfortable for you. SCRUM-but tends to be comfortable, as it allows you to hide a lack of discipline in the word “but”. In reality SCRUM-but is the kamikaze formation.
As a final note I’d like to refer to this post by Ken Schwaber where he talks about Scrum But Replaced by Scrum And.