Agile project management vs. the ‘waterfall-approach‘: Two ways of project implementation
Common software projects have three phases at their core: Conception, implementation and quality assurance. Usually the project, laid down in the description of requirements, is developed further into a precise system specification. This document is drafted by the contractor and then reviewed and modified with the client over the course of several sessions. As soon as the review is done, a team start implementing the project based on the agreed upon documents. This phase is followed by quality assurance (on the contractor’s behalf), and once this phase is completed, the client receives the ‘final’ product.
At this point there is often astonishment on both sides. The client actually gets what he asked for – but not necessarily what he expected. If it went well for the contractor, his price estimates were not totally wrong. Because, in reality, is it not true that only at the end of a project you really know how long it took? And which difficulties would come up in the process and had to be dealt with and the areas that had to be done ‘quick and dirty’ in order to meet to the agreed deadline? Ideally then the client is only a little bit disappointed about the product …
This approach is called the ‘waterfall’ because it is graphically represented as a cascade (it goes gradually downwards). Product development that follows the ‘waterfall-approach’ can be successful of course. Well … occasionally.
Agile project management
You could learn something fundamental from these experiences and begin to change. It is about shortening the three phases (conception, implementation and quality assurance). These phases are not understood as separate, chronologically completed stages of the entire project, but instead these phases are being completed cyclically for individual functions throughout the entire project. The project is structured in periodic short intervals, within which the phases are repeated. These intervals usually take a few weeks to complete and are being repeated until all functional requirements of the project are implemented.
Crucial here is the necessary transparency. Transparency among the team of developers as well as towards the client. Since he knows best what is required, he will know best if they were implemented according to his expectations. It does not really matter whether the requirements are expressed in common language (‘if a user is registered she should be able to download protected documents’) or rather technically, e.g. as a flow chart.
The team discusses the optimal approach to implement a requirement, and after its implementation, the whole team completes the quality assurance for the solution before asking the client to sign it off. Correct: this approach involves the client to a much larger degree, she is encouraged and even supposed to check temporary results for a correct understanding and implementation of the requirements. If the requirements are not met, individual components can still be modified at this point - before other components will be based on them.
Transparency encourages not only understanding between contractor and client, but also leads to higher productivity with the developer team. Regular exchange in short joint meetings makes clear what the obstacles are that hinder progress and where there is a shortage of resources (usually solved immediately thanks to the high level of transparency). Since the client is actively involved in the communication process, he or she is able to redefine his or her priorities during implementation, or even drop some of them. For example if it turns out that implementing a requirement is extremely time-consuming but also not of much use, it can be agreed to drop the task for the sake of the project’s progress.
There will always be uncertainties in software development. Even if at first a project looks like it will be routine work. Every project is a little different. And because one is able to respond to these uncertainties in an agile way, a traditional (and often demanded) element of the ‘waterfall-approach’ needs to be dismissed: milestones with deadlines. Of course there should be a release date (‘The site needs to go live until the fair opens in November.’) But there needs to be room for concessions. Full functionality in excellent quality, a tight deadline and a budget that is met rarely go together. Let go of this expectation and you will not be confronted with unpleasant surprises.
Agile project management assumes that each team member is interested in the project’s progress and its swiftly completion. The fact that more and more software developments teams adopt agile methods confirms that this assumption is to be preferred over the suspicion that human beings are generally lazy and need to be pressed by time or even threatened by sanctions. An approach that is only applicable in economic dependencies anyways. Based on voluntariness, the open source community proves that software development works well even if the focus is solely on the completion of tasks.
In-depth
The comparison of different methods of agile development would exceed the scope of this text. For an introduction into each you may look up the following methods online:
- Kanban
- Scrum
- Extreme Programming
- Prototyping
There is an increasing number of regular meet-ups around the term ‘agile’ – maybe also in your area. In any case, a search in the popular social networks should be worth the effort.