Sequentially phased projects require that you commit very strongly to a set of requirements at the start of the project. You have to be thorough, since if you miss something, it will be significantly more expensive to get it in later, and a big hassle, too. Also, you can't really change your mind in any significant way because phased projects don't handle change well. Where does that lead us?

According to a Standish Group study of a large number of phased projects, almost two-thirds of the features in the completed solutions were "never" or "rarely" used. All these were just as costly to make as the really useful features, but provide no real value for the outcome. They also made the projects a lot larger and added complexity to the planning and implementation effort.

A thing not discussed in the study is "how many necessary features were not actually made?" In real life, many user needs are discovered during development stage or even after the use of the application has started. Many of those features are critical to the effective use of the software, and their absence has ruled out many otherwise promising software solutions. Poor usability can also be interpreted as a "missing feature", since improving usability in deployed applications is expensive.

Getting 80% value with 20% of features
Agile projects are value driven. In every iteration, the customer goes through the feature list and reprioritises it, selecting the next features to be implemented from the top of the list. The reprioritisation is not only based on the estimated business value, but also the architectural impact and implementation risk of the features. The implementation team gives feedback to the prioritisation. This allows the really valuable features to "float up" and simply leaves the "not important now, if ever" sink to the bottom. At some point the customer will realise that the project has reached the cut-off point, after which there are no more sufficiently valuable features to be made, and the project can be closed down.

Does that mean that Agile projects never make a useless feature? Unfortunately no. At the very beginning of the project, the customer and the team have to work based on their initial understanding of user needs. The initial accuracy can be increased by spending a little time on effective prototyping and user needs research. It is recommendable to use light-weight tools at that stage to quickly refine the key issues in the designed application and polish the initial product vision. But prototyping must never be used to convert a would-be Agile project into a phased project.

As the project team starts to crank out working versions of the software to actual users for testing or use, they start getting feedback about the real value and the missing features, allowing the customer to refine and prioritise the list more accurately. It may also mean that some of the already implemented features need to be removed, as the solution is more valuable to the users without them.

Agile projects have additional benefit in the lack of need for "initial completeness". In the beginning of the project, the customer and team can focus on the features that are "obviously valuable", be that core functionality or some currently business critical feature. They don't have to worry about everything, allowing them to create initial versions much quicker and then provide them to the users for feedback. It gives the customer the potential to realise the value of the first features much sooner than in a phased project, where the initial release of the software might be even years away from the identification of the business needs.

Feedback and interaction as sources of right features
Every change is an improvement to existing plan or functionality. Since agile engineering practices focus on keeping the cost of change down, the project can incorporate these changes at any time. Naturally, the changes go through the same prioritisation as all features, and suggesting a change does not necessarily mean that it will be implemented.

Agile methods often talk about "emergent features"; the true requirements emerge from actual usage of the solution. Another way of saying this is "I'll Know It When I See It". It is the nature of us humans that we provide the best feedback only after we've had a concrete opportunity to use the solution. No amount of preliminary research can overcome this completely.

Getting feedback and emergent requirements requires that the customer and team actively seek it out. All possible stakeholders must be involved in the project, with maximal possible participation. There is no such thing as too much feedback, really. Agile methods provide ample opportunities for building this communication and participation straight into the project progress. The concrete deliveries make it easy to communicate progress and features. Feedback on upcoming features can be received by continuing prototyping during the project.

Changes lead to best results
Agile project management does not have a change management process. It is a change management process in itself. It does not impose any difference to requirements proposed at the start of the project and those that have emerged during the project. It is just as important to identify and remove unnecessary features as getting new valuable features in. This way agility allows a continuous improvement of the planned solution, resulting in the best possible solution in the given timeframe and costs. It can actually meet the customer requirements at the time of the release and has a minimal amount of unnecessary features.

For further information, please contact:
Petri Heiramo, Process Improvement Manager, tel. + 358 40 709 2526