Introduction to Agile and Scrum Development

Note: The following post is adapted from an original post I wrote over at GeeksWithBlogs.net/CodeBlog  I've modified it a bit to apply to game development where applicable.

Recently I read a portion of a good book ('Agile Software Development with Scrum' by Ken Schwaber with Mike Beedle).  I read this book in order to understand the Agile/Scrum development style used in my workplace.  I took a course some semesters ago in which we used a Scrum development style based on the input given by a student who was an intern where I work now.  While we seemed to grasp the idea of Scrum, we had it often incorrect according to the book.  This is some of the basics of what I learned in the few chapters I read (no infringement intended!).  Everything is in my own words (I don't even have the book anymore).

What is Scrum?

Scrum, in the sense I'll be talking about, is a development style of the 'agile' type.  Agile development is a method of developing software iteratively, meaning you take your project, chop it up into pieces, and work on the pieces until the whole project is complete.  The game industry in particular has used this iterative development process without companies necessarily defining their studio as an agile workplace.  For many years, game studios have developed software on a schedule, meeting milestones for the benefit of anyone financially involved in the company/project.  Essentially, any time you start on a project, meet a goal or milestone, and continue to produce another milestone or final product, you are iteratively developing software.

How does Scrum add onto Agile development?  Scrum has multiple user roles defined with it and a specific technique for processing those 'chunks' of your project.  Essentially, Scrum creates a bottleneck (in a good way!) between management and the development team in order to keep the development team focused on the current piece of work.  For understanding, let's use the idea that your whole project is the engine of your car (or some motor vehicle).  We'll build on this idea throughout this post.

Roles in Scrum Development

In Scrum development, the development team, is called the Scrum team or just team.  Pretty simple, huh?  The Scrum team is comprised of those in the workplace that focus on the development portion of the project.  These include (but aren't limited to) engineers and designers (including artists).  Anyone who will have to take an assignment and produce some kind of output directly effecting the project.  (Note: In my description, directly effecting the project means something like a concept drawing, a demo build, code, etc...  More on this in a bit.)  In Scrum development a team of about 5-8 is used, though if the team is too large, it becomes difficult to manage.  If the team is too small, the work (which we'll talk about in a bit) probably won't be distributed or managed well enough between them.  In our car symbolism, think of the scrum team as the pistons of the engine.

The Product Owner or Project Owner (often shortend to 'PO') is the person at the head of the project, typically a project lead.  The Project Owner should be a single person (not a team) for reasons we'll discuss later about work (suspense!).  This person will delegate the work to the rest of the team.  This introduces the idea of the Sprint Backlog.  The backlog is a large topic, so we'll come back to the Product Owner after discussing the workflow of Scrum development.

Scrum Development Work-Flow

Remember all those times you've been working on a project (in a non-Scrum team) and someone walks up to you and says, "Could you do me a favor and add this feature?"  You know in your mind that by accepting you'll be adding more to your workload and thus increasing your development time.  Depending on when you start that feature-add, it could potentially increase the development time of whatever you were working on before your 'friend' came over and disturbed you.  Not only does this make you less productive (being productive is a matter of quality, time taken, and other factors) but it could even lead you to the dreaded feature creep (something no project EVER wants!).

Scrum prevents this situation by creating a bottleneck (mentioned earlier) between you (the developer) and your feature-needing friend.  Again, this bottleneck isn't a bad thing, it's in place to make your life easier by making you more productive.  When a request for a feature is needed, the request is dropped into the Sprint Backlog, a list of all the features and work needed to be done before the project is finished.  This can include bugs, new features, or changes to currently existing features.  Before going on, what is this sprint thing? 

A Sprint is a period of time the Scrum Team takes to work on a chunk of items that were placed in that backlog.  Typically a Sprint is 30 days (about a month).  A month typically is a long enough time to do a good amount of development but short enough that if time is spent during that month on a feature that gets scrapped, the time isn't 'wasted' time (since it was still used on the project and knowledge is gained).  Notice I mentioned a 'chunk' of the backlog.  This ties back to the idea of working on pieces of your project.  So, the Sprint Backlog contains all the work needed to be done on the project and during each Sprint, the Scrum Team selects a portion of the backlog (NOT the whole backlog) to work on.  In our engine idea, the Sprint Backlog is the fuel tank, holding the future fuel to be processed.  Thinking at a higher-level, the Sprint is the time is takes to process a portion of that fuel.  And finally, the 'bottleneck' holding back the fuel is the fuel-injection valve.

Roles in Scrum Development (cont'd)

Each item placed in the Sprint Backlog will typically have a different priority than any other item in the backlog.  This is where the Project Owner comes back in.  One of their primary roles in Scrum development is managing the Sprint Backlog.  They should be labelling each item in the backlog as well as giving each a priority so the team knows when to work on each.  Prior to each Sprint, the Project Owner and Scrum Team will meet in a Sprint Planning Meeting to determine which work from the backlog will be worked on during that Sprint.  The Project Owner will say "I want this, this, and this done."  And the Team will reply, "Well we can finish this and this during the Sprint."  This defines the work that will be done in the future Sprint.  Isn't it cool that the Team decides what to work on, instead of management?!

There is one more large player in Scrum development even though the system seems complete.  The Scrum Master focuses on, well, keeping the team focused on the task at hand.  Recall earlier I described the situation in which you as a developer are approached to put in a quick feature as a favor.  From everything about Scrum that's been discussed, there is nothing to prevent that situation from happening once again.  Sure, we can hope that all work gets put through the Sprint Backlog, but how can we be certain?  This is the primary role of the Scrum Master.  He/She makes sure the team is on task and following the work for the current Sprint.  The Scrum Master accomplishes this tasks by typically having daily Scrums, a short 15-minute meeting where each person in the Scrum Team describes what they're working on.

To keep Scrums on topic, there are numerous things a Scrum Master will do to control the group including limiting the speaking participants to only those on the team (i.e. NO interrupting, suggesting non-teammates like management).  One of the biggest ways to keep topic in a Scrum meeting is to only answer 3 key questions:

Obviously, if your friend stops by, asks for that favor, and you start working on it, it'll come up in the meeting and the Scrum Master has the task of putting you back on the Sprint work and stopping by your friends cubicle for a little 'chat' about distractions.  Essentially, Scrum Masters play the 'bodyguard' for the project by protecting the team from distraction.  In our engine example, the Scrum Master is the metal housing the pistons, engine, and other items related to the engine.

Conclusion

So that, in a nutshell, is Agile development with Scrum.  It probably seems like a lot of info but there really are only 3 primary roles.  And the benefits are amazing!  They give power to the team to control their work, not upper-upper management.  If all this sounds interesting I'd consider grabbing a copy of that book, 'Agile Software Development with Scrum' by Ken Schwaber with Mike Beedle.  They go into much more detail about their personal struggles with project teams and how Scrum development evolved.

One thing that should be finally noted, this whole process is modular and companies will adapt the process however they see fit.  For this reason, one company might hold 15 minute Scrums and another might have hour long Scrums.  One might have a 30 day sprint while another has a 60 day.  Like most programming and development techniques, once you understand the core concept, you should be able to apply it wherever needed.  Also, be involved in your companies development techniques.  Challenge how your company has adapted the process.  Because the company doesn't do agile development by the book isn't a bad thing, as long as it's efficient and effective, it's correctly done.