Scrums

April 10th, 2006
[ Software Development ]

We’ve been toying with aspects of Scrum for a while now with a few of our projects. If you’re picturing a bunch of developers gathered in far too intimate of a group hug then you’re thinking of the wrong scrum.

Someone recently asked me what exactly scrum was. Before I read the above wikipedia explanation I’m going to try to repeat my answer here. So you have eXtreme Programming, or xp, which is a methodology for building software. XP is often described as an agile or lightweight methodology. Methodologies are about how you build software. Scrum is a means of managing, or wrapping a process around, lightweight or agile methodologies.

What are lightweight methodologies? I often describe them as a response to traditional software processes such as the waterfall model. Traditional models try to freeze things. You start at requirements then at some point you freeze them and move onto design. Then you freeze the designs and move onto coding, etc. Sure the phases overlap somewhat but the ideal model is a staged one.

What you’ll quickly find in a traditional model is that it requires a certain level of delusion, or you all simply bs each other. The reality is that nothing is ever frozen, especially for the eight to twelve month release cycles products typically have. Lightweight models are a response to this delusion, or an attempt to bring it forward and deal with it openly.

Here’s what I like about Scrum today:

  • It forces everyone to get real, real fast. The speed, quality and level of information for all stake holders in a software project goes through the roof. This is great, however, it does require attention as not everyone is used to, or wants, this level of information.
  • It offers new levers to business owners. Business owners may be actual business owners or product management or a board. They are the non-technical people that keep poking the techies for releases. Typically the only real levers business owners have at their disposal are cash, features, and dates. A business owner will set a date practically at random as a means of incenting a team to work their ass off to nail that date no matter how reasonable. In scrum the business owner has the product backlog as their main lever.
  • History. Scrum provides great tools to formally track how a particular team tracks over time. I feel they’re attempting to do this in a way that’s reasonable for team members to truly participate in. By truly participate I mean that scrum has attempted to build a model that team members won’t continually try to fudge or subvert. Over time you build a decent representation of how a team tracks and delivers. I’ve gone through every form of post-mortem and followup meetings you can think of and none have had any real benefit to the team members.

Now I’m going to actually read some of those wikipedia links above to find out how wrong I am about all this….