Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
If the team is not aware of what tactics are being used, chaos will happen. A well oiled machinery runs on a well defined tactic.
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.
Read more about:
Featured BlogsYou May Also Like
