If you have been doing waterfall projects for years and have heard the buzz about agile, your curiosity may be peaked. Like the old Ragu commercial saying “It’s in There”, many of the most common project risks are resolved simply by the design of the agile approach and no separate Risk Management Process is necessary.
The agile software development process is becoming more popular and prevalent with each passing year. While the Agile Manifesto formally defined the agile values and principals back in 2001, the Project Management Institute (PMI) added a separate certification for agile only a couple years ago (2012). For many years PMI maintained that agile was not sufficiently unique to justify a separate certification from their one-size-fits-all Project Management Professional (PMP) designation. The massive shift of knowledge worker projects toward agile and the increase in the success of those projects was enough for PMI to take notice and acknowledge that projects with moderate technology and requirements complexity warranted their own discipline. As the pace of change increases, the number of projects fitting this criteria takes a larger and larger portion of the overall global project pie. As of 2011, 27 percent of projects were conducted using agile processes, but many more would have achieved success had they been agile.
The beauty of the agile framework is that many of the risks handled in the formal Risk Management Process for PMP’s are inherently addressed by the framework. While the agile framework is adapted to the specific needs of every project, it is important to make sure that adjustments don’t negate the ‘baked-in’ risk management benefits. I’ll cover a few of those benefits here. There are many more and I encourage anyone who strives for a greater success rate in projects to learn more about the agile processes.
- Risk: Unclear requirements: Famously, knowledge worker project requirements are incomplete, unclear and poorly understood (even by the customer). This is not an indictment, merely an acknowledgement that we live in a world where business needs change so fast that sometimes the best way to describe success is I’ll Know It When I See It.
- Inherent to Agile: The agile techniques of progressive elaboration, user stories and lightweight requirements gathering using use case diagrams, data models and screen designs address this. Instead of attempting to exhaustively define requirements before starting any design or development, we focus the team on a single, clear, high-level goal that describes a deliverable with customer value. Only after agreeing on that goal do we collectively and collaboratively define the details of that goal. We iteratively build and show the results to the customer to ensure we are on track. These demonstrations are conducted as often as needed, even daily, with the goal of minimizing rework due to ‘going down the wrong track’.
- Risk: Incompatible outputs: Too often, project deliverables don’t work as well together as the customer desired; think Hubble Telescope. In order to optimize utilization, we split tasks between teams of specialists only to find that the deliverables don’t mesh like clockwork.
- Inherent to Agile: Agile promotes building the Minimum Viable Product (MVP) first. In plain language, we build the smallest possible thing that ‘works’, where ‘works’ means an end-to-end operation that delivers production value. Any separate components that must work together are first roughed out in an architectural spike to prove the technological approach works. This minimizes sunk costs and opportunity costs on a product that ultimately may need to be reworked, or, worst case, scrapped. Additionally, we promote continuous integration. In this practice, code changes are checked in and run through a series of tests daily to ensure that nothing was broken. Also, small releases are used to integrate the efforts into a customer facing deliverable as soon and often as possible to quickly locate bad assumptions, inaccurate or incomplete specifications and get that I’ll Know It When I See It confirmation that the customer is getting the value they desire.
- Risk: Poor Governance: How many times has a project been 90% complete and on schedule only to find that nothing works on the delivery date? In most cases, quality (or lack therof) is not the cause, but that problems weren’t surfaced earlier.
- Inherent to Agile: The pillars of agile are transparency, inspection and adaptation. Transparency is the solution here. All stakeholders attend frequent demonstrations of the project as scope is completed. This way, everyone knows exactly where the project stands. Any issues are surfaced at the first demonstration of that scope with the issue. Engaged stakeholders and decision makers see the working product on a regular basis and have ample opportunities to voice their concerns that their definition of ‘done’ wasn’t reflected in what they saw.
I hope these examples illustrate that agile has many benefits over the traditional waterfall approach. In my experience, higher team performance, greater customer collaboration and project success are all attainable goals. With these sound steps, many projects actually become a joy to be involved in. When the right product is produced for the right customer at a sustainable pace, everyone benefits and can even enjoy the journey. It’s not uncommon for successful agile project teams to add a Phase II and a Phase III to keep them delivering a continuous stream of value. So the moral of the story is GET AGILE!
