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.
In case you hadn’t noticed, nobody calls it RAD anymore. That’s passe. It’s Agile. But don’t tell the agile people (and you know who you are) because Agile is different.
I have no idea what to call it but what I see more often than not is a 12 step development process.
Step 1) Code code code, (notice the absence of requirement)
Step 2) Document some of it
Step 3) Code code code
Step 4) Don’t bother to document because its gonna change
Step 5) Code code code
Step 6) Don’t bother to document because nobody reads it anyway
Step 7) Unit test (translation – fix only the stuff you have to to make it compile)
Step 8) Load to production, go home for the night and turn off your BB.
Step 9) Answer the phone and say the BB battery were dead
Step 10 ) Make excuses for why it doesn’t do what anybody needs it to do and brought down payroll.
Step 11) Blame the contractor
Step 12) Fire the PM
I’m sorry – where am I?