People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to in times of crisis.

The latest such beacon is AGILE.

I must admit, having been implementing software projects in both Agile and Waterfall environments, I’m not a fanatic, one way or another. Horses for courses. Nothing in life is absolute so there is absolutely no reason to assume that one model or another will always deliver better results – it all depends on the circumstances, more specifically the readiness of the specific environment and organizational maturity to operate within the operational constraints imposed / required by that methodology or the other.

If you gauge the public opinion, as reflected in recent blog articles, you would conclude that the wind is blowing Agile. Experienced project managers are progressively casting their attention at this model and the message they are sending to their devoted readership is “agile is good” and “agile can solve your ailing problems” – so much so that the PMI has now decided to jump on the publicity wagon and institute yet another certification – yes, you guessed it, Agile PM certification.

I wouldn’t be overly concerned about this fashionable trend if not for the fact that such public relation campaign does matter. As a recent article in the NewScientist (“Following the herd actually shifts your opinion“) shows, such publications carry a lot of weight as they are likely to result in shifting in public opinion for no other reason than that it gets publicity and air-time.

One thing I find really funny / annoying is the attempt by some writers to re-write their experience and mask it behind “we’ve always applied Agile in our projects, sure we didn’t quite call it Agile, but if you look at the processes we’ve used, they were just like what Agile prescribes”.

So here’s my stand on this question: Agile is good, but so are other software development methodologies, provided that you apply them appropriately and provided that you manage them correctly. One way or another you’ve got to do things ‘right’. If you rely on the methodology to save your day, think again. It is not the methodology that brings the results but the way people implement that methodology.

Think about it!

Print Friendly

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Project Management RAD Certification Anyone? I still can't get over the recent decision by the PMI to introduce yet another, Agile PM, certification. It is not that I reject the concept of cer...
The Agile Debate – Good, Bad, or Indifferent... Given the recent influx of articles about Agile, particularly given the recent decision made by the PMI to introduce an Agile PM Certification, I coul...


  1. Pingback: Shim Marom

  2. Pingback: shim marom

  3. Excellent stuff Shim.

    I’ve run projects using just about every methodology out there. I’ve run agile projects and waterfall projects. Some were successful…some weren’t.

    What I’ve found is that Agile works in some places and waterfall works in others. Selecting a methodology is dependent on many things – culture, project goal, timeframe, etc etc – but no methodology is perfect all the time.

    Great stuff as always.


  4. Pingback: Eric D. Brown

  5. Yeah – it’s a packaging of a variety of methods. Packaging is an important aspect to marketing tough. The PMBOK is a package of a different set of tools.

    I’m finding the methods within the agile paradigm are consistently useful most of the time. There are other useful methods as well of course.

    A different approach is diagnosing the impediments and challenges ahead of you and drawing on the whole world of tools and methods at your disposal.

    Information is a commodity. The value we – as experts/professionals – add is knowing what information is useful at which point, and in guiding teams to the right approaches depending on the circumstances.


    • Hey Craig,

      I thought the PMBOK was meant to be discipline independent (i.e. not Software oriented). Wasn’t agile born out of the need to introduce a more efficient software development process? I know agile can be ‘done’ in other non software disciplines, but does this really necessitate a new project management branch, dealing specifically with agile implementations?

      I’m not yet convinced.

      Cheers, Shim.


  6. Pingback: Edmonton PM

  7. Well the PMBOK came out of an engineering centric view so it has some inherent biases. There’s an argument that software is different, but I don’t buy that so much.

    What I do think is that the PMBOK is a product, which packages information, and so it’s product managed with particular world views and constraints built into it. It also gets pushed along the product lifecycle over time. It’s far from perfect, but probably useful in many instances.

    (A side note, I was beta testing Cornelius Fitchner’s PMP test tool last night and got a hilarious number of questions wrong. I went back and checked the question against my response. I’d say my answer was usually a better response than the PMP answer.)

    Anyway, what was my point? Ahh – software centricity.

    So, all ‘enterprise projects are software projects, right? So if ‘agile’ methods are more effective for software, well… why not?


    • Craig, I agree with the inherent biases, and whether or not the PMBOK is perfect, my tack is ‘who cares’. At the end of the day no one ‘does’ pure PMBOK. We all apply our judgement (for better or worse) and a good measure of common sense, with an attempt to adapt the guide to our unique circumstances.

      Now, about ‘software centricity’. Even if, for the sake of the argument, the PMBOK is biased towards software projects (which I’m not convinced it is), is not a reason to make it even further software centric by bringing an inherently software development methodology (and this is how Agile started – pure software) into its very core. I think this is WRONG!!!


  8. Pingback: MindEdge

  9. Pingback: Links for March 13 2011 | Eric D. Brown

Leave a Reply

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

%d bloggers like this: