Once considered a fad, Agile has matured into a respected set of PM development methods
The question isn’t who can and can’t be Agile, Everyone can! — The real question is: How does a programme lead ensure Agile software development maps to waterfall Change projects in your organisation?
In fact, you may have seen Agile expanding outside of software development and IT into sectors like banking, management consulting, automotive manufacturing, and healthcare. Companies are moving to Agile methods because the global marketplace demands they bring products to market that better reflect their customers’ needs. Where the traditional “waterfall” approach —with its sequential phases and heavy investment in large-scale, up-front design—lacks the flexibility to respond swiftly to changing markets, Agile approaches offer faster delivery, higher quality, and an engaged development team that can deliver on its commitments.
Agile can improve your efficiency. Instead of designing an end-to-end, upfront solution (a solution that may be infeasible or outdated before it’s even implemented,) Agile teams build the solution incrementally—allowing you to mitigate risks, accommodate changing market needs, and deliver valuable features more quickly. Agile methods have been shown to cut time-to-market by 50% and increase productivity by 25%.
According to a recent global survey from PricewaterhouseCoopers on the state of project management, 34% of you now use Agile PM methods within your companies and a majority of PMs (62%) are certified Agile practitioners.
The only people in danger of losing their jobs from Agile are those who’ve been hiding within the inefficiency of the system (Agile is remarkably good at holding up a mirror to an organisation and exposing its waste, inefficiency, and dysfunction). What matters most in Agile project management is not your title or your role, but your contributions: what you do to add value and keep the organisation moving forward.
Mapping Waterfall Project Management to Agile Practices
Agile and waterfall development aren’t as different as people imagine.
Both approaches recognise the triple constraints of cost, schedule, and scope; where they differ is in the implementation.
- First, waterfall development encourages locking down scope requirements so that schedule and cost can be planned, and sees feedback as “rework” — something to be avoided through better planning. Agile, on the other hand, recognises that scope is always variable, and sees feedback as a critical and inextricable part of a planning process that continues through execution.
- Second, Agile shuns waterfall’s traditional directive tactics in favour of collaboration and facilitative support—or what’s known as “servant leadership.”
In traditional project management, you—the project manager—are responsible for balancing scope, cost, and schedule, as well as managing quality, reporting, and interpersonal issues. In Agile project management, the whole team commits to shared decisions and collaborates in its work to meet these commitments, challenging traditional PMI deliverables.
Your Agile project management support equips the team to become fully engaged and motivated contributors, who can produce high-quality work at a faster pace.
Despite the differences between Project Management Institute (PMI) and Agile approaches, many of the practices identified in the Project Management Book of Knowledge (PMBOK) are quite compatible with Agile practices.
In fact, when followed with discipline and rigour, Agile methods are just as compliant with the Capability Maturity Model Integration (CMMI) as traditional waterfall methods. The differences lie in when and how these practices are executed and the lexicon used by their practitioners as seen in the table below.
The PMBOK identifies Initiating, Planning, Executing, Controlling, and Closing as the process groups within project management. The Agile process phases of Envisioning, Roadmap, Release, Adapting, and Closing are similar to the PMBOK phases, but better reflect the reality of how a project is delivered or software solutions are actually developed.
“The question isn’t who can and can’t be Agile”, states Craig Ashmole, founding Director of London based CCServe IT consulting. “Everyone can — The real question however is : How one makes Agile work and integrate into the wider deliverables for your organisation?”
Most large IT departments are typically set in their ways and resist change as it takes individuals out of their comfort zones, especially those hiding behind the wall of, ‘Well IT is working why change.’ — This will be the biggest challenge the CIO office will face.”