The term Scrum comes from Rugby where it is the formation used when the two teams compete for the ball after it has gone out of play. The Scrum is a key part of the game that is also one of the most intense times of the game. It is often the source of injuries, up to and including breaking your neck. The practice of Scrum for software development teams is not nearly as violent, but it can be just as pivotal.
What is Scrum?
The term Scrum also means an agile software development method for team organization. I highlighted method in the last statement because I want to draw the distinction between a set of techniques that you apply on a project and a full blown methodology. Scrum is not a methodology, because it can be used with any methodology (but works best with more lightweight or agile practices). I highlighted team organization because it differs slightly from the detention that is currently in the Wikipedia Article. Scrum has components of it that allow you to help manage a project, but it is more than just a project management methodology. It is a way for a team to self organize and manage their processes.
Major Components of Scrum (adapted from the Wikipedia article)
Product backlog of every feature that is requested in the product.
Sprint that is a fixed set of time (usually 30 days) that is used to deliver a set of items from the product backlog. At the end of the sprint all the items should be “shippable”.
Planning Meeting at the beginning of the sprint where the backlog items that will be delivered in the sprint are decided.
Demonstration at the end of the sprint where the product team shows of the features that were developed.
Scrum itself, which is a daily stand-up meeting at which progress is explained, upcoming work is described and impediments to progress are raised.
Common Scrum pitfalls
Scrum is not perfect (no methods are), but when the organization is really committed to the practice it almost always works. There are a couple of pitfalls that I have personally experienced that I would like to share with you as you think about Scrum:
ScrumFall - This is the term that is applied when a team is using Scrum, but the rest of the organization still follows a Waterfall methodology (the term can also work for organizations not practicing a methodology).
Using it on non-project work – The first time I was on a team were we tried to apply Scrum we tried to use it to manage all our team’s activities and not project work. There was some very useful things we got out of it (the daily stand-up was great), but when you are working on non-project based stuff, the backlog kind of falls apart)
Turning the stand-up into a status meeting – I heard about a stand-up that was going 1-2 hours everyday. Project Managers need to have status meetings (They are necessary, but I think they are also a biological compulsion with PMs). Have your status meeting without the development team, let them go to work after the stand-up.
Want to learn more about Scrum?
There are a few books on Scrum, and if you want to read about Scrum I would start with Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. This was the first book and probably the best of the bunch. Once you have the basic terminology down (it only takes a couple hours to read that book), I would recommend talking to a Certified Scrum Master (this may be a partial list and a little dated). When you are ready to take the plunge you are going to want to retain the services of one. Scrum is deceptively simple, and you will want an experienced practitioner for at least your first few sprints.
The VSTS User Group in Chicago is having Scrum as their topic this next Wednesday (November 14th, 2007 at 6:00 PM). The majority of the meeting will be focused on Scrum, but then they will spend some time showing how you can adapt Team System to use Scrum. Details and registration are located at http://vsts.sogeti-chicago.com/Pages/November2007.aspx.