Having been ‘doing’ both Waterfall and Agile for quite some time now I feel fairly qualified to point out the idiosyncrasies in both approaches. None of these approaches is completely wrong, and equally, none of these approaches is completely right. It all depends on the circumstances, the organizational maturity, attitude, culture and inclination.

So, while I have had my fair share of frustrations with pure command-and-control organizations, my beef today is with Agile advocates that are exhibiting less than agile attitude when attempting to bring Agile into large command-and-control environments.

The scenario I’m referring to is as follows:

An organization with long and established ‘Waterfall’ methodology and way of working is convinced to give Agile a go. The Agile practice is getting momentum in certain quarters of the organization and the Agile portfolio is steadily growing. While it is growing in absolute numbers, in relative terms it is still but a small percentage of the overall development effort managed throughout the organization. Furthermore, crucial support services, like Release Management, Production Support, Infrastructure deployment, Enterprise Architecture, Enterprise Testing, and others are not yet fully integrated into the “Agile way of working” and are still operating with what would, traditionally, be referred to as Waterfall.

The reality in such circumstances is that while the software development aspect of the project/program can utilize Agile methods, the project in its entirety is still bound to interface with non Agile delivery teams, operating with a different cadence, different milestones, and different operational requirements.

For Agile professionals, such an environment is an ongoing challenge. It requires them to accept that being adaptive also means being able to operate within a Waterfall set of constraints. Integrating Agile into a Waterfall, command-and-control organization is not a nuisance, it is not a hindrance, it is not an anomaly, it is just the way things are.

Clearly, “operating” Agile in a fully ‘Agile-committed’ organization is relatively straight forward but many organisations are not yet adapted to allow for Agile practices to flow through the organisation structure, and in such cases, being insistent of doing ‘pure’ agile is not just childish but also unproductive at all levels. Attempting to force Agility down an organization is not being able to accept the fact that agile does not operate in an organizational vacuum. As an agile professional you need to remember that it is not the ideology that is important but rather the ability of the organization to reap the benefits of its technology investments.

Think about it!

Print Friendly

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...

8 Comments

  1. So great to have you back with a blog. The world has not spun as smoothly while you were busy.

    Wonderful post that really hits reality: capability is not the same as ability. That you should use Agile principles, for example, does not mean you must use them all for benefit.

    Waterfall was designed as an iterative approach. Too many have abandoned that aspect for the ‘command and control’ oversight they believe brings control.

    The speed of change certainly stresses the credibility to control risk and scope and begs for rapid learning through rapid iteration. With budgets and competition so fiercely contested even failing fast is a win that frees up resources to get back in the game.

    Thanks for sharing your perspective – it is good to have my main protagonist back.

    Toby

    Reply

    • Hey Toby, life is taking its toll and priorities need to be adjusted accordingly 🙂

      Been up to my eyeballs with professional and personal matters (and this is still the case).

      Been thinking of writing on this topic for quite some time. In fact the draft has been sitting ideal for 4-5 weeks before I could find the time to give it the final polish and publish.

      How’s life at your end of the globe?

      Cheers, Shim.

      Reply

      • All is good in the northern hemisphere, thank you for asking.

        I look forward to when you share your thoughts – whether a 4 to 5 week gestation or 4 to 5 year gestation, I appreciate your view and learn more from your view each time.

        Don’t forget: rapid prototyping allows to fail fast and retrospectives allow to learn even faster.

        Stay sane,

        Toby

        Reply

  2. I hope the org can Reap rather than Rip the benefits ;>)

    Reply

  3. Great stuff mate. Good to see you back!

    Regards,

    K.

    Reply

  4. Hey, glad to see you are back!

    Sadly lots of people, especially in software development, fall in an ideology trap about methodologies, programming languages, etc. You have to be and stay pure. That is not realistic.

    As you pointed out, a project has to interface with the rest of the world and some of that world can be regulated or set in its ways. In some cases the MVP is pretty much the end product or outside influences change the needs in a major way, forcing massive rework.

    I routinely meet people that still believe that if you are not Agile certified, you are in cast-in-stone waterfall mode. Of course we know that engineers (guilty!) are waterfall zealots. Surprisingly, I can’t remember a project (and I go way back) where the client did not want to see how things were coming along. So every month or so we’d show the latest evolution. Sounds like something an Agile team would do…

    Reply

  5. Pingback: New PM Articles for the Week of June 21 – 28 - The Practicing IT Project Manager

Leave a Reply

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

%d bloggers like this: