One of the first decisions we can face for each of our project implementations is “Which development methodology should we use?” These methodologies are a way to organise the work of software development, it is not a style of project management or a specific technical approach.
The 2 most popular methodologies currently in use are:
Waterfall which is the more tradition approach, and
Agile which is a newer (about 10 years) proven method.
Both of these are mature methodologies, both have their pluses and minuses and advocates
The Waterfall Methodology
Waterfall is a linear approach to software development. In this methodology, the sequence of events is something like:
Gather and document requirements
Design
Code and unit test
Perform system testing
Perform user acceptance testing (UAT)
Fix any issues
Deliver the finished product
In a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin. There is also typically a ‘stage gate’ between each; for example, requirements must be reviewed and approved by before design can begin.
There are good things and bad about the Waterfall approach. On the positive side:
Developers and customers agree on what will be delivered early in the development lifecycle. This makes planning and designing more straightforward.
Progress is more easily measured, as the full scope of the work is known in advance.
Throughout the development effort, it’s possible for various members of the team to be involved or to continue with other work, depending on the active phase of the project. For example, business analysts can learn about and document what needs to be done, while the developers are working on other projects. Testers can prepare test scripts from requirements documentation while coding is underway.
Except for reviews, approvals, status meetings, etc., a customer presence is not strictly required after the requirements phase.
Because design is completed early in the development lifecycle, this approach lends itself to projects where multiple software components must be designed (sometimes in parallel) for integration with external systems.
Finally, the software can be designed completely and more carefully, based upon a more complete understanding of all software deliverables. This provides a better software design with less likelihood of the “piecemeal effect,” a development phenomenon that can occur as pieces of code are defined and subsequently added to an application where they may or may not fit well.
The Agile Methodology
Agile is an iterative, team-based approach to development – emphasising the rapid delivery of an application in complete functional components. Rather than creating tasks and schedules, all time is “time-boxed” into phases called “sprints.” Each sprint has a defined duration (usually in weeks) with a running list of deliverables, planned in advance. Deliverables are prioritised by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is reprioritised and the information is used for future sprint planning.
As work is completed during each sprint, it is continuously reviewed and evaluated by the customer, who may be considered the most critical member of the Agile team. As a result, Agile relies on a very high level of customer involvement throughout the project.
Some advantages of the Agile approach are easy to see:
The customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the development project.
The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.
If time to market for a specific application is a concern, Agile can more quickly produce a basic version of working software.
Development is often more user-focused, likely a result of more and frequent direction from the customer.
The iterative nature of Agile development may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.
So, how do we choose? I will describe this in my next blog / article
