For the past few years agile development techniques have been trumpeted as the solution to many of the problems commonly encounted in software project management. A number of techniques appear to be in widespread use, so I decided to pick one mostly at random, and attempt to figure out what to make of the whole agile extravaganza.

Thus, I recently started reading “Agile software development with Scrum” by Ken Schwaber and Mike Beedle.

For those unaware, Scrum relies on sprints (2-3 weeks of focused development based on a frozen set of requirements) followed by demonstrations of working vertical prototypes. The underlying idea being that freezing the entire requirements specification up front makes little sense, as the client is bound to change it anyway. Making rapid releases, and allowing the client to change the list of requirements between sprints, supposedly satisfies both the development team (who get to do focused work on a frozen list of requirements) and the client (who gets to see early working prototypes and  modify the requirement specification every 2-3 weeks).

These are my impressions so far:

Scrum, much like extreme programming, greatly appeals to me as a programmer with a focus on professional integrity and software quality. Indeed it appears to embody many of the virtues that I’ve been pushing for quite some time. Among these are:

• granting programmers room and conditions that support focus on “getting in the zone”
• forcing the project manager to handle impediments, organizational or otherwise
• freezing requirements during development

Considering how common-sense these virtues are, it is quite remarkable how few software developing organizations manage to adhere to them. I for one have never been fortunate enough to work in such an organization, although I should greatly like to try it some day.

With that being said, I am not entirely convinced that Scrum will work for the majority of projects in which I am involved, although it should be noted that I certainly have no empirical basis in which draw that kind of conclusion.

First, Scrum teams are recommended to consist of around 7 members, including the Scrum master. Currently we don’t even have 7 full-time staffers.

Second, Scrum appears to require that development projects take at least 2 weeks (for 7 people) to complete. Unfortunately that’s not really the case for quite a few of our projects.

That’s not really Scrums fault though. I guess it boils down to our organization having a problem with attracting even moderately sized projects. Hmm.

This entry was posted on Sunday, October 4th, 2009 at 8:27 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.