Why Agile Doesn’t Work for Large Projects

Why Agile Doesn’t Work for Large Projects

Why Agile Doesn’t Work for Large Projects
Why Agile Doesn’t Work for Large Projects

Picture the scene – A CEO leafing through his latest copy of CEO Magazine. He turns quickly to the section to see if he has made the shortlist for the Top 100 CEOs, discovers he hasn’t, and disappointed, drops the magazine on his desk. But the cover story catches his eye; “Agile – If you are not using this to deliver on IT projects, you must be a dinosaur!” (Or something like that.) He reads that traditional waterfall methodology is sooo 20th century, and consequently talks to the head of the PMO. They put their giant intellects together and mandate that henceforth, all projects should be Agile. Except, if they had actually asked someone who knows about IT delivery, Agile is not a “one size fits all” for every development project.

The problem for a PM trying to deliver a large integration project using Agile deployment is there are two competing perspectives. The Exec Sponsor has a deadline to hit (for all sorts of legitimate reasons), but that goes against the Agile ethos that software is delivered when it is ready, and not to a hard date on a project schedule. The Exec tells the PM, “I want it when I want it”, and the developer responds saying, “You’ll get it when I give it to you”, and the PM is caught in the middle.

At one of my clients the CEO heard that “Agile” was the way to deliver on IT projects and so talked to the PMO. The PMO then mandated all projects, even Infrastructure projects should now be Agile. Actually, I kind of liked it. It didn’t make any sense at all for Infrastructure, but the old methodology had lots of pointless documentation, whereas you could bend Agile to rationalize that leaner documentation was needed. I would set up tasks to align to 2 week periods, satisfied the criteria for Agile where I needed to, cherry-picked a few things about Agile I liked (e.g. the daily standup), and this gave me the freedom to deliver with minimal overhead.

But Agile is not only a poor fit for Infrastructure, it is also not well suited to large development projects. This is particularly true when the project’s schedule is tied to deadlines like change lockdowns, or budget year end. Agile works terrifically well for maintenance, iterative development, and also for prototypes, but large projects are trying to align budget, communications, marketing, support organizations, training, and so need to know when to mesh their efforts with the product launch. So a waterfall approach to the project as a whole fits better, but that’s not what the developers want to hear – they love Agile. When the Project Manager asks, “When will I get this delivered”, they roll their eyes and tell the PM, “Deadlines are not part of Agile.”

Think on the delivery of the project for the Affordable Care Act – Here was a large project where everything had to work on a particular day, the day when Open Enrolment started. They had to use a 4th Quarter date since coverage for medical plans were due to start on January 1. But the software wasn’t ready. They used Agile methods, (although Agile proponents claim that it was a flawed use of the agile methodology). It might be that Waterfall or Agile, Healthcare.gov wasn’t going to be ready. That may be true, but Waterfall should have been the methodology here – it would have exposed the issues earlier.

Keep using Agile where appropriate, but for large projects, development is just a small part of the picture. The reality is on large projects we need coordinated action by many teams. The necessities of these large projects present differently from development projects and since you can’t have the tail wagging the dog, development has to change to match the project, not the project change to match the development. So Agile proponents; get ready - deadlines are back in fashion!

The Author : Stuart Hamilton


About :

To structure the delivery of complex, large-scale transformational projects while managing and coaching multidisciplinary and matrixed teams. Day 1 assistance to develop strategy, roadmap, and execution plan, then execute and manage the implementation.

Post a Comment

Previous Post Next Post