In the May 11, 2010 edition of Government Computer News, contributor Michael Daconta advised government IT managers to be wary of agile methods in his article, “The Good, The Bad, The Ugly of Agile Programming.” I’d like to present a different point of view from the one taken by Mr. Daconta – proposing that IT managers should consider an Agile method for any software project where risk is a significant issue.
In the well-known book, “Waltzing with Bears: Managing Risk on Software Projects” by DeMarco and Lister, the authors call out five major project risks:
- Schedule Flaws
- Requirements Inflation
- Specification Breakdown
- Under Performance
Each and every one of these project risks is directly addressed by specific practices in one or more of the Agile methods, and also reflected in the four guiding Agile principles laid out in the Agile Manifesto. This article will only look at a couple of these risks and how the Agile methods address them – a fuller discussion is available elsewhere in a series of articles beginning with “Agile and the 5 Risks of Software Project Management – Introduction”.
To start, the two most common risks threatening every software project are inaccurate schedules and the issues caused by requirements changes. Creating software is an incredibly complicated endeavor, and building an accurate and precise schedule at the beginning of a project that can stand up to the inevitable changes in requirements and environment is nearly impossible. Life isn’t static – requirements change whether we want them to or not, and either the business, political, or physical environment in which the project needs to function will undoubtedly change as well.
Agile methodologies allow a different response to changes than do other methodologies that seek to limit or prevent changes. Real world changes that force requirements to change are viewed as an opportunity to refocus the project’s efforts towards a refined set of goals, both affected by and rooted in those same real world changes. Projects governed by methodologies that don’t accept and account for change run the risk of being executed exactly according to plan, delivering exactly what was asked for, on exactly the right day, and finding out at the conclusion of the project that the wrong problem was solved. Using change to your advantage allows an IT manager to better ensure that limited funds are invested in developing requirements that will satisfy the evolving needs of the user, rather than delivering stale and unwanted functionality. This is the Agile principle of valuing interactions with customers more highly than building to a predefined and unchanging specification.
Obviously, accepting change as part of a project plan has an effect on that project’s schedule, and that’s OK. Another Agile guiding principle is frequent, incremental planning over sticking to an overall, detailed plan. Planning on Agile teams happens frequently, serves to focus the team on short-term goals (between a week and a month’s work of deliverable features), and allows for shifts in feature priority based on real world needs. Newly created features or features that have become more important are scheduled sooner, and those that are less important are delayed and may slip out of scope. At the highest levels of planning, every feature has an estimate that is used for budgeting, planning, and project tracking. At the lowest levels, every increment of work focuses on planning and delivering the most highly valued features identified by the IT project manager or customer.
At the conclusion of every increment, the team delivers a working system that has its shippable functionality that reflects those highest priority features. This is another one of the Agile guiding principles of valuing working software over other work products, such as comprehensive documentation. It’s not that documentation isn’t important, it’s just that it should support the product that is being built, not lead the product being built! Through time and close collaboration, a working system emerges and evolves. Entire working features are added in priority order until the system is delivered.
Contrary to what you may have read in other places, the Agile methods are about much more than just development. They have a rich planning ecosystem that allows a project to evolve and adapt as circumstances dictate. The evolving plan allows the team to focus on what is important, implementing and delivering completely during a short increment. To paraphrase Kent Beck, the originator of Extreme Programming, “Agile doesn’t have a risk management strategy; Agile is a risk management strategy.”