Monday, 30 November 2009

10 Reasons why I like Scrum for Games

This is a response to Steve Tovey's 10 Reasons why Scrum sucks for Games. Steve and I used to work at the same company (but on different projects), and it sounds like he and Scrum didn't get along very well. I think Steve's a very clever chap, but I had a somewhat different experience of Scrum.

Scrum is a project management framework. A project is broken down into a strictly prioritized set of components (the backlog) and every few weeks (called a "sprint") the highest priority items are taken off the backlog, divided among the Scrum teams, developed, and signed-off. Additional features include Planning Poker, Sprint Planning Meetings, Sprint Retrospectives, and a Scrum Master whose job it is to make sure things run smoothly.

My team (the tools team) was one of the last teams in the company to adopt Scrum, and when the Powers That Be were trying to push Scrum to us, we resisted at first (why would I want to Scrum? sounds like a load of rubbish!) It was the early days of a new project, and we had all the time in the world, so there was no pressure on the tools team, no deadlines, and it felt like we could do whatever we wanted. The trouble is, without targets, there was no feeling of achievement - things just rolled along at a less than optimal pace. When we started Scrum, we suddenly had deadlines and targets, and over time we could see where our work fit into the bigger picture. Which leads me to my first reason:

1. Scrum improves visibility. You can see exactly what is important and what isn't - what you should be spending time on, and what is acceptable to slip.

During the sprint planning meetings, you divide tasks into manageable chunks. In Scrum, "Manageable" is no more than a day, and preferably less. If a task is estimated at taking a week, it needs breaking down some more and thinking about more. As Steve rightly points out, estimating is hard. The first few planning meetings are going to have estimates that may be quite a bit off the mark. But estimating is a skill that can be improved with practice. This is reason number 2:

2. Scrum improves developer's estimation skills. And when management sees that the developers are able to give accurate estimates, they get more realistic expectations of what can be achieved by the end of the project.

When development time is underestimated, tasks end up dropping off your current sprint and returning to the backlog, but the important thing here is that they are still at the same relative priority to all the other tasks. They will be dealt with next sprint. Eventually, when you run out of sprints, you will inevitably have to drop features because you ran out of time. But thanks to the strict ordering of the backlog, the features you ultimately ship without are of the lowest priority, meaning

3. Scrum makes sure you work on the most important things.

That isn't to say there's no time for polish. Between sprints is a period of time for integration (combining all of the Scrum teams' work). While this is going on, and developers get a bit of a breather, they can use this time to add the bits of polish that didn't fit into the main product backlog. Also, if the product owner wants to put more time on polish, he can simply bump up the priority of polish - with the understanding that anything of a lower priority will move down the list, possibly causing another of the lowest priority tasks to be unachievable.

4. Each sprint generates "deliverables".

In a project meant to run over a couple of years, you might expect to see somewhere in the region of 10 - 20 sprints. At the end of the early sprints, you might not have anything that could be boxed and sold, but towards the end of the project, it is possbile that you could finish the project early because you made sure that there was a deliverable at the end of each sprint. Alternatively, you could ship on the expected end date, and then run extra sprints for a patch or version 2.

I will agree with Steve on his point 5 "Why do I get a say?" I was lucky in that my Scrum team consisted entirely of programmers. I can imagine it being very frustrating having an artist telling you how simple (or difficult) a programming task is, or generally just pulling numbers out of thin-air during planning, and similarly having a programmer tell an artist how much time it takes to be creative. So I'll give my reason 5 as

5. (assuming your Scrum team is composed of developers from the same discipline) Everyone relevant gets to have a say.

Steve says taking an entire sprint to react to change isn't very Agile. After a quick glance at both the Agile and Scrum entries on Wikipedia (thus making me an expert in the fields) I'd says that the Agile timeboxes (of one to four weeks) correspond rather neatly with sprints, and I'd say that adopting changes between the timeboxes fits in rather comfortably with the Agile ethos. If reacting to changes every 4 weeks isn't rapid enough (say I want to react in a day), then by all means make an emergency change to the sprint - it's not going to bring the whole system crashing down! So

6. Scrum is Agile, in my expert (ha!) opinion.

I partially agree with Steve on his point 7 "less done". You do get less coding done if you spend more time in meetings - it is a simple calculation. But to be fair, (anecdotal evidence alert) I don't feel that you loose that much, especially if you value what you gain - a better ability to estimate tasks, and a greater focus on what the customer (project manager) wants. So

7. While less overall code gets done, more important code gets done. There's no risk of not having enough time to finish the critical features just because you decided that it would be nice to work on a small pet project / task / feature.

In the daily Scrum meeting, the team move Task post-it notes from the "pending", to the "in-progress" to the "complete" sections of the Scrum board. I have a feeling Steve found this a waste of time! I think they served a useful purpose.

I remember reading about computerization of air traffic control. Prior to computerization, aircraft were represented by plastic tags on a board, and when an aircraft changed position in their queue, the controller responsible for that aircraft had to move the tag. I don't remember details of what disasters happened after the computers took over, but I remember reading that the controllers felt less responsible for their charges. The reason I read was, that the tags that they moved around were things they could physically grab hold of or pass to other controllers and that physical movement or handover, psychologically, made the controllers feel more responsible for the planes they were in charge of. Without the physical tags, there was a psychological disconnect between the controller and the plane.

I think the post-its, in their small way, make the team members feel more responsible for their tasks. Usually. I do remember on a number of occasions a team member who would say things like "I've done X and I'm just waiting for Y so I can finish it" or "I can't do Z this sprint" while moving his post-it note into the complete section. Occasionally I would (in a joking-but-not-joking kind of way) try to pick him up on this, but his post-its still managed to find their way in to the complete section anyway! I think this was partly due to a slightly competitive feel that some people might get when you can see how many tasks you've completed compared with your team mates; but I also think a bit of friendly competition is healthy for the team. I'm not saying you can't be competitive without Scrum, but I'd say that Scrum makes your progress that much more visible.

Steve says "Too many coders spoil the broth". I'd use the saying when it came to Scrum team sizes in general - lots of coders in a daily meeting wastes a lot of peoples' time - but I'd say sharing higher level tasks among three or four people is a sensible idea, because I'm a fan of team ownership.

I hear a lot of people voraciously cheering the Code Ownership bandwagon, but they are supporting Strong Code Ownership - the idea that every piece of code is owned by exactly one individual. While it sounds like a good idea that one person knows everything thoroughly and is the highest authority on that code, if that coder leaves the team, or company, (or gets hit by a bus), the company is in trouble. The opposite extreme is that nobody is responsible for any code, anyone can change anything, and if anyone wants to know how something works, they pretty much have to work it out for themselves because so many people have had their fingers in the code pie.

In the middle, you have team ownership. I don't remember reading a definition of it anywhere, so I may have invented it, but probably not. Anyway, with team ownership, while individuals work on components, the team should be more or less knowledgeable of the whole subsystem that they have been made responsible for. Which means if one member is ill, or on holiday, or leaves the company, any of the other team members can quickly and easily take up the slack.

This fits in nicely with Scrum - during the sprint planning meeting (the process by which high-level post-it-notes get turned into lots of low level-post-it-notes) the low-level tasks can be shared among the team (as long as the tasks and boundaries are well defined). I like scrum because

8. Scrum facilitates shared code ownership.

Each daily sprint meeting is attended by the Scrum master. Each day, the team has the opportunity to bring to light any impediments and the Scrum master can go off and prod the relevant people until the impediment is removed. The impediments can also be brought to the Scrum master at any time, not just during the daily meetings.

9. Having a consistent Scrum Master really helps remove impediments!

After each sprint you have a sprint retrospective. The team brainstorms about the past sprint, trying to decide what went well, what went badly, how to improve things in the future. Also, each team member draws a graph of how they felt during the sprint - from very happy, to very sad. There are no numbers on the graph, the important part is sharing the reasons behind the peaks and troughs of the graph, hopefully helping to improve future sprints.

10. Scrum encourages frequent communication.

No need to wait until the end of the project for a post-mortem!

Just before I finish, I will say that you don't need Scrum in its entirety to get all of the benefits - individual elements are probably strong in their own right. But I do feel that there are a lot of good reasons to adopt Scrum as a whole.

Sorry the post was so long! Feel free to blast apart any of the arguments I just made :)

1 comment:

Clinton Keith said...


Good article! I like how you describe how your team adopted it and how Scrum created a sense of urgency which hadn't existing.

The likely issue with Steve's experience is one seen elsewhere. Teams are often thrust into using Scrum without understanding the principles you outline. This leads to a parroting of the rules of Scrum that don't make sense without the context of the principles. They end up failing with Scrum and blame it, calling it a methodology when in fact it is only a framework, as you point out.

Scrum can neither be credited or blamed for a team's success or failure. It's like crediting a hammer for building a good house. Studios build their own methodologies and sometimes their cultures and frameworks do not support communication, self-management and iterative practices. Scrum doesn't find much purchase there.