Agile methods are one way to use iterations and frequent feedback to manage risk. Getting feedback early so that you can make corrections or change expectations isn’t a new idea, but implementing a process that can give you both this feedback and the tools you need to make corrections is difficult for a number of reasons.
One reason you may be trying to adopt agile is that you are having trouble delivering software predictably in your business, technical, and team environment. One of the main differences between agile and traditional projects is their different approaches to managing and mitigating risk.
Software projects are complex and can quicky go off track. This isn’t a new phenomenon. Consider that Fred Brooks in his 1975 book on software projects, The Mythical Man Month, asked, “How does a project get to be a year late? One day at a time.”
Agile methods are one way to use iteration and frequent feedback to manage risk. Getting feedback early so that you can make corrections or change expectations isn’t a new idea, but implementing a process that can give you both this feedback and the tools you need to make corrections is difficult for a number of reasons. Even though agile came to popular awareness in the late 1990s, it’s still hard for teams to fully adopt agile. Part of the reason for this reluctance to adapt new ways of working is that the traditional approach to risk management is both deeply ingrained in the culture of many organizations and also appealing at some level.
Traditional Project Management
Non-agile projects attempt to manage risk by trying to anticipate problems, plan for them, and then move slowly to avoid the unexpected. Plan-driven approaches are focused on minimizing losses rather than maximizing gains, which according to some research is a tendency humans are likely to embrace.
We like to think that we can anticipate every contingency and deliver a plan that can effectively drive the project. Trying to work in the context of a plan-driven approach like this involves the following: doing a lot of up-front work, such as detailed requirements, design, and estimation; making decisions with risks to the plan as a primary consideration, rather than evolving business situations; and checking progress against the plan and considering whether to continue or cancel the project depending on the progress.
A plan-driven approach may be fine for very short-term projects when things are predictable. But things almost always change over time, and projects rarely go according to plan. Even something as simple and risk free as running an errand can be difficult to plan in a predictable fashion. With bigger projects we feel more of a need to plan things out because we feel that there is more at risk, and thus we should apply more control.
Some teams may choose to manage technical risk by scheduling more technologically risky work first, rather than more important features. This will mitigate technical risk, but will make it more likely that your project will suffer when there are changes to the business environment.
For example, you may decide to do a detailed database implementation to validate that your database design will support all of the features scheduled for the project. However, you may later discover that this work puts you behind schedule when you need to release, and as a result, you’ll be missing essential business features.
Following a master plan is comforting, but it doesn’t always work in the face of the various forces that a project deals with. There are technical challenges, team challenges, and changes in the business environment that make following a long-term master plan a risky approach, especially when you don’t periodically re-evaluate your plan. Some of the things that can cause a plan to go awry include frameworks that don’t work as you expect, staffing changes, a competitor introducing a new product, or a change in business rules.
Adherence to a plan can also present business risks. For example, you may be planning to introduce a new feature as part of your big semi-annual release when a competitor introduces a similar feature before you are finished. Unfortunately, you discover that the most important feature was planned to be completed last, so you can’t deliver it in a timely manner.
Confidence in in a plan-driven approach leads you to build plans that are fragile, or at the very least, do not force you to develop robust, incremental plans. Quite often when the plan no longer seems to meet business needs, the only option you may have is to cancel a project, since the plan may be difficult to change.