Geeks With Blogs
Code.Blog Code Talk for the Game Developer

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 at my new workplace.  I took a course last semester in which we used a Scrum development style based on the input given by a student who worked where I've just started and 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.

How does Scrum add onto Agile development?  Scrum has multiple user roles defined with it and a specific technique for processing those 'pieces' 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 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.  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 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 that person 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:

  • What have you done since our last Scrum meeting?
  • What are you going to do before the next meeting?
  • What is preventing you from completing your plan?

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 office 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.


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.

Posted on Thursday, May 28, 2009 1:38 PM Tutorials | Back to top

Comments on this post: Intro to Scrum Development

# re: Intro to Scrum Development
Requesting Gravatar...

There is some great info here. The information in here is expanded on [a lot] at with comic strips and more.

Nice job!

-mike vizdos
Left by Mike Vizdos on May 28, 2009 5:51 PM

Your comment:
 (will show your gravatar)

Copyright © Matthew Christian | Powered by: