Many people have a pre-conceived idea that Agile projects don't plan. The reality is far from it. They plan just the same, but starting from a different point-of-view and with different tools. The plans are more effective and yield more value per time spent.
Consider the following scenario - based on your strategic business goals, you have one month to define all your business needs for the next two years. Once finished, the definition becomes locked and, if you want to make changes to it, the key to the lock is very expensive to use. Would the list be difficult to make?
What about this scenario? You make an overall roadmap of what kind of needs you have over the next two years and then select the most important issues now for a one-month action plan. After a month, you review the roadmap and make new action plans for the next month, and so on for two years. Is this any less scary?
Traditional phased (often called "waterfall") and Agile processes have the same difference in their planning. There are some environments where the first example is more appropriate, but in a significant majority of software development cases, the second one will yield much higher quality solutions. And we're not talking about technical quality, we're talking about the features the customer ends up having in their system.
The illusion of a perfect plan
In the phased approach, a detailed plan makes sense. As the cost of change increases exponentially during the project, it is a sensible strategy to try to define as many things as possible in detail at the start of the project, and then make as few changes as possible. This works well in some projects, such as building a bridge. We can't build a simple version of the bridge, test it, add a feature, and test it again, until it is the bridge we want.
But we're not building bridges. They are essentially very simple structures. Once built, their use is pretty simple; just drive over them. Software products are very complex, and their use is often anything but simple. We don't really know in detail what they should become; we have some ideas of what we want to achieve, but the final result is exploration. At the same time, the business and technical environments are changing at much higher rate than in bridge building.
Waterfall approach says that if we provide enough specifications and make detailed enough a plan, we can define the product and the project execution to produce the solution the customer wants in the defined schedule and budget. And if we don't succeed, it is because we didn't plan enough at the start. This illusion is two-fold.
First, it is just not possible to define the requirements in detail because we don't yet know what the customer or user really needs. We only know what they think they need. There is a difference, and that difference is very significant. When we make plans based on "think they need", we create a project that is destined not to meet the real user requirements when the product is in use.
Second, adding more planning is not the way to improve the process. It only adds insult to the injury. Up-front planning more does not make the customer any more able to give better requirements, nor does it make us any more prepared against the unexpected changes in the business environment and user needs.
Agile approach
We need an overall plan. We have to know why the project exists and what it aims to achieve. We also need to know the important business milestones. Based on those, we need to understand the size of the project and some budgetary constraints. This project roadmap also includes a list of the features we now think we would like to see in the software, at a level appropriate for the team to give some meaningful cost estimates.
We also need a detailed iteration plan so that the team knows what to build next and how to do it. The list is generated from the feature list by picking the most valuable features and planning their design and implementation.
The Agile engineering practices have been designed to keep the cost of change in check, allowing us to change our plans without excessive costs. The project is planned and executed in short iterations, usually from two to four weeks. The overall plan is evaluated and reprioritized in every iteration. For each iteration, the team commits only to what it believes it can achieve, and then does its absolute best to make it happen. At the end of the iteration, they deliver a new version of the software with the agreed features, so that the customer can review the features and really refine their understanding of the software requirements.
Does an Agile project require less planning? Yes, according to one well-measured company case, Agile pilot projects spent 80% less time in planning. Were the plans of poorer quality? Apparently they weren't, since the company was able to cut the development time and costs by 50% while producing a solution that had higher customer satisfaction and 40% less errors. And this case was from a Danish company that already had certified CMMi level 5 software development processes.
Higher value and less wasted effort
Agile projects focus on creating high-value plans. They purposefully try to avoid wasting time on things that are likely to change and just aren't of concern right now. They save a lot of effort by using simple yet efficient planning tools. The projects update their plans even daily, yet without spending a lot of time doing it.
Agile methods are in use in SYSOPENDIGIA projects and are a part of our project practices and processes.
"Often detail adds no more usefulness - only a false appearance of validity." - Edward de Bono
For further information, please contact:
Petri Heiramo, Process Improvement Manager, tel. + 358 40 709 2526