5 out of 6 software projects are late and over budget. This article outlines a different approach to project planning that's gaining popularity.
Agile Project Planning – an overview
So you’re in charge of a new software project, and you’re staring at a blank MS Project screen, wondering how you got so far away from the fun work. You’ve heard about this agile stuff, but the boss still wants a project plan, and a guaranteed delivery date, and the feature set has already been promised to the customers. Sound familiar?
Far too many software projects start this way. Aggressive delivery dates, over-promised feature sets, and unrealistic project plans that don’t reflect technical reality. But software project planning doesn’t have to be like the journal of a death march. It can be a rewarding, interactive experience that benefits both business users and the development team alike. This article tries to shed some light on some of the challenges teams face on software projects, and how an agile planning approach can help.
The Trouble With Traditional Project Planning
So what happens at the start of a new software project? The business stakeholders usually have these three things in common for each project:
- They have a specific problem they need solved
- They have a timeframe they need it solved by
- They have a sense of how much its worth to solve the problem
The specific problem to solve usually takes the form of “requirements” that are either communicated informally in email, discussed in a meeting, or proposed by a project sponsor. In a traditional planning approach, every detail of the project needs to be uncovered before any work starts. The business users are expected to understand all aspects of the problem and how they want it solved, and to sign off on a requirements document. This tends to create anxiety, since naturally they’re not entirely sure they’ve thought of everything that might need to be in the software.
To compound this problem, the technical team typically wants to have the requirements “locked down” as soon as possible in order to provide an estimate for delivery. This seemingly reasonable request is often the beginning of the trouble. The business wants to know how much the project will cost, but the development team needs to know what’s going in it before giving a cost estimate.
So the requirements game begins, with the business and technical teams as opponents, trying to outwit each other. The business tries to think of everything they might need, fearing that the team will never do it if they don’t include it. The development team tries to nail down every detail to avoid “scope creep” later on, making the analysis drag on and on.
By the time everyone is finished, the project usually is expected to take much longer than anticipated, and has a much larger scope. Meanwhile, the business users need it sooner than the developers think they can build it. The date is artificially moved earlier to accommodate the business, and the feature set remains the same. Small wonder that according to a study by the Standish Group (1), only 1/6 of all software projects in the U.S. were completed on time and within budget. The same study found that 1/3 of projects were canceled outright due to time delays and cost overruns, and over half were considered to be challenged.
Planning In An Uncertain World
Agile project planning is a different approach to this problem. Instead of forcing business stakeholders (we’ll call them “the customer”) to define every detail, agile planning says that they can plan incrementally, starting with the most important features. The development team can then determine which of those features they can complete in a specific timeframe or “iteration” that typically ranges from 2 to 4 weeks.
Each iteration allows the customer to choose additional features (or enhancements to existing features) and to prioritize the remaining work. The development team can learn from each previous iteration to improve their estimating. If they complete all of the features agreed to, the team can start working on the next priorities as determined by the customer. If they can’t complete the set of features, again, it’s the customer who gets to decide which ones to defer until later.
What’s so special about this? It changes the dynamic between the customer and development team from an adversarial relationship, into one that is based on mutual respect. The customer knows they always have the final say on what should and should not be worked on. The development team has the reassurance that they are working on the most important things.
The key to all of this is communication and rapid feedback. The customer communicates in the form of clear, prioritized needs. Development communicates in the form of estimates for specific, measurable functionality, which is critical in the prioritization process. Finally, there is rapid feedback to both teams on how things are going. Project risks are discovered early, and changes in priorities are likewise not only feasible, but expected. The development team delivers working software at the end of each iteration, even if it’s just a skeleton of the finished product. This tight feedback loop is a big part of why an agile approach works better.
But What About the Project Plan?
Agile projects don’t use traditional project plans that dictate every task, when it will be completed, and who will work on it. The tools used for planning include a release plan, and a series of iteration plans.
A release plan is just a list of the features most wanted by the business, and roughly when these might be available. The release plan doesn’t necessarily drive the project, its just a way of communicating the shared vision of the team. Commercial software is often developed with an understanding of key features that need to be in the next release, and this is the sort of thing a release plan captures. The marketing team can refer to this for external planning purposes, and it provides a roadmap for future functionality. Most agile teams try to plan for 2 to 3 releases ahead.
An iteration plan is a tactical development plan for a specified period (usually 2 to 4 weeks). The iteration plan takes the highest priority features (often called “user stories”), and based on developer estimates, selects a set of them to work on for the iteration. Each story is broken down into tasks by the development team. Tasks can then be individually estimated, and developers can sign up to work on them.
Project managers can now use the iteration cycle to track progress in terms of completed features (stories), and outstanding tasks. Iterations are short enough, that major issues are uncovered very quickly, before they become show stopping disasters.
Agile Project Planning Tools
If you’re thinking of giving up MS Project, but still craving a tool that gives you better project visibility, there is hope. Several tools, both commercial and open source, are available for supporting an agile project. Some agile proponents believe that index cards are the best way to manage these projects. While they are very simple to start with, I believe that larger projects with more moving parts need a little more support, and can benefit from the new generation of project management tools.
References
- Standish Research Paper, Chaos Study, 1995, available on-line at http://www.standishgroup.com
About the Author
David Churchville is a 15-year software industry veteran in the capacities of developer, project manager, and software executive. He is the founder and CTO of ExtremePlanner (www.extremeplanner.com).
