Dude, RAD ain’t Rad

I’m completely lost on this sudden move to RAD development methodologies. Originally I had hoped that it was just a fad but instead this seems to be a growing trend. In concept it’s a great idea, being able to quickly release new enhancements to projects sounds cool. But it seems crazy to me to put a one size fits all mentality on everything. You just can’t say your Agile and be agile.

There are two things that you need to be RAD. You need skills and you need reusable process. The problem is that more and more companies are adopting these methodologies and at the same time investing in new technologies or development teams. This is especially visible in content management projects where deployments are more of an art than a science and there are very few masters out there.

What is really needed is a series of RAD projects between larger more standard, dare I say waterfall, projects. Your first project is always done after a long series of analysis and design, followed by a solid development effort. These are usually in the six to nine month range but nothing says that they can’t be three months in duration. But here’s is where many go off track. After the first deployment, most companies take on a series of short projects to make changes, never to do another major development. But at some point you need to make a major changes and this should be planned in and done as a large term project.

You can see this strategy in action in the software industry where there are point release and major releases. Once a release happens, software vendors will perform minor revision to applications as point releases. Then once every few years they perform a major revision to take advantage of new technologies and approaches.

So we can’t look at content deployments as short term fast changes. After all where would we be if we lived in a one size fits all fast food world, fat and slow.

Hey, wait a minute.