Choosing the Right Methodology

It never ceases to amaze me how many companies spin their wheels when it comes to their software development methodology.

There is no single methodology that is a panacea for all things process related.

The process heavyweights, such as literal interpretations of the Rational Unified Process (RUP) and traditional waterfall approaches, are very thorough, and leave very few, if any, stones unturned. However, it introduces a significant amount of overhead when deployed. It has a rather large implementation footprint. The Rational documentation far eclipses (in size) most of the documentation of the projects that go through it!

On the other end of the spectrum, you have the lighter, nimbler methodologies, such as Agile, Scrum, and eXtreme Programming (XP). Their implementation footprint is much, much smaller, however, that savings in overall weight came with a price – a lot of good stuff was thrown overboard to lighten the load. They don’t call it “agile” for nothing.

So which is better?

First, and foremost, you need to take into account the overall scope of the project in question. If you are building a rocket ship that will carry 75 people to the moon and back, cost $300 million to build, and will take 5 years to complete, then I would leave the Agile handbook at home and go for something a wee bit sturdier. In situations such as this, issues such as rigid requirements management, redundant quality checks, linear documentation phases, and strict testing tollgates become paramount. Failure to do so will more than likely result in additional costs as problems have to be repeatedly revisited, constraints are not put into place to prevent scope creep, etc..

Likewise, if the scope of your project is very narrow, such as a middleware script or simple system automation tasks, then breaking out the Rational approach would result in a ridiculous TCO (total cost of ownership) multiplier. Imagine that in order to rollout a service with a very narrow scope, you had to spend a week gathering requirements, another week to design and prototype a solution, another week for a facilitate session to refine the prototype, another week to develop the product, another week to fully test it, and another week to roll it out. That’s 5 weeks or so. That $500 JIT project to create a simple backup script for your database server just turned into a $10,000 venture. If the product’s scope is narrow – don’t bother. Shotgun it – get it done and move on with your life.

So what am I saying? In essence: choose wisely. Use common sense. Just because a waterfall methodology is out there doesn’t mean you have to use it for everything you do. Likewise, just because most of your projects use the Agile method doesn’t mean you can’t resort to using something a little sturdier if the scope or criticality of the project deems it necessary.

Culturally, there are some inherent hurdles to this “common sense” approach. If your firm manages all of its projects through a project management office (PMO), then introducing a lightweight approach such as Agile could cause some intereference, as the PMO tends to lose some visibility into those types of projects. Conversely, if your development machine is lightweight all the way, introducing some heavy-duty waterfall approach will most likely cause some angst as well, especially among your development staff. To mitigate this, an educational approach must be taken to ensure that all relevant stakeholders are aware of the need for either cost savings for smaller engagements, or increased visibility and controls for larger ones.

My advice? If you are a cowboy coder, an Agile junkie, a waterfall diver, or a RUP purist, get over yourself and start using your noggin’. The world doesn’t revolve around any particular platform or methodology. IT is a business – and as such, CIOs and CTOs should choose the best possible path forward, given the nature and budget of the project, as well as the long-term interests of the firm.

Firms that remain philosophically “stuck” on one approach, and unwilling to explore other, potentially more efficient means, will find themselves as the beneficiary of a lot of wasted effort.

The competitive advantage will fall to the firm who can make wise, project-centric decisions. The one-size-fits-all approach is, well, so 1990s.



  1. B. Scott,
    Great article. I recently posted an introductory article discussing the tradeoffs between waterfall and incremental processes, which complements your points about choosing the right process for each project. Hope you enjoy it.

  2. Scott, that’s a great article with some good info. I’m sure others will find it of value.

    Nice name, BTW … :)


Leave a Comment

Your email address will not be published. Required fields are marked *