Saturday, December 8, 2007

Scrum, agile, waterfalls, iterations....

SDLC or the Software Development Life Cycle has taken many forms over the years. From the rigid and carefully documented step by step approach common to mainframe programming shops through to the more versatile "Rational Unified Process" of the Nineties. Now we are really seeing something else starting to make inroads in a formalized way.

Agile process coding is not new, it appeared first in the code slinging days of the early Internet. Throw up a web site, does it work? No, change it and try again. All in the context of continuous user review and feedback.

More recently with the standardized Agile models like Scrum taking off, we are again searching for the best, quickest and of course, cheapest ways to make applications work the way they are expected to.

Our recent experience with Scrum shows it can deliver, in smaller projects at least.

The repeated review cycles, the weekly or bi-weekly sprint reviews and poker sessions (not Vegas poker but a session where people put up estimates based on how long a 'story' will take to complete) the constant reprioritization and the daily standup meetings all have great value in getting things out the door.

Where things seem to come apart, a bit anyway, is when you try and create a project plan (I use MS project) and locate the start and endpoints for feature creation on the plan.

Given the way Scrum keeps moving things around and the apparant freedom from other constraints which may not be well articulated in the poker sessions but are very real from a deployment perspective, the larger projects with lots of moving parts are not so well served by Scrum. At least this is the perspective I have gained so far.

While Agile seems to play very well in an environment where multiple iterations and a get-something-up-quick attitude are key business drivers, it has yet to be proven a good way to build mission critical systems that pay the bills, calculate your ATM balances or process your medical claims.

On the other hand, those system are still almost exclusivley huge legacy code mountains of COBOL, BAL using IMS/IDMS data files and nothing so far extant will change that.

No comments: