Saturday, September 09, 2006

More Thoughts on Scrum

I've been doing a little more thinking about Scrum, and have had a little success in getting it kick-started at work. Our first sprint, with a team of seven excellent developers, starts on Monday.

Here's some more thinking on the subject. The basic theory behind scrum is based on traditional process control theory. At first glance, it appears to be simply "management by to-do list". But there really is method behind the madness. Most existing software development processes assume that software development is a defined process--similar to that of building a car on an assembly line. If you've been doing software for a while, I'm sure you realize that is absolutely not the case.

Scrum is different. It acknowledges that software development is really an empirical--unpredictable--process. The methods used to control an empirical process are vastly different from those used to control a defined process. For a defined process, you can follow a recipe or series of steps to produce the correct output. For an empirical process, you closely examine the inputs prior to performing a process and the outputs once the process is complete. You put controls in place to react and change course when things go haywire.

So it sounds ideally suited to certain software development activities. But I'm trying to apply it to production support--maintenance of a system that is already in production. As with any support organization, our reacts to constantly changing priorities: we scramble to deal with the latest "emergency." Maintenance releases occur weekly on a regular basis, and sometimes as frequently as once a day. To complicate things even further, 80 percent of our support team resides in India, while the other 20 percent is located here in the U.S.

Scrum is really intended more for longer development periods, prioritized task lists that don't change, and development teams that have the luxury of being co-located and being left alone. There has been some talk about evolving Scrum to deal with concurrent development periods, and even weekly maintenance releases. And that will be the subject of my next blog.

No comments: