One of the first decisions any software development project faces, is the “Which development methodology should we use?” question. This is a topic that gets lots of discussions and often very heated debate!
The two most popular methodologies currently used are:
- Waterfall: which might be more properly called the “traditional” approach, and
- Agile: a specific type of Rapid Application Development approach newer than Waterfall, which is often implemented using Scrum.
Both of these are usable and mature methodologies. Having been involved in software development projects for a long time, here are my thoughts on the strengths and weaknesses of each.
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
• 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 the customer 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.
Here are some issues I have encountered using a pure Waterfall approach:
• One area which almost always falls short is the effectiveness of requirements. Gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development, in my opinion. Customers are sometimes intimidated by the complexity and specification details, provided early in the project, are required with this approach. In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting.
• Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.
The Agile Methodology
Agile is an iterative, team-based approach to development. This approach emphasizes the rapid delivery of an application with 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 at the start of the sprint. Deliverables are prioritized by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is reprioritized and the information is used for future sprint planning.
As work is completed, it can be reviewed and evaluated by the project team and customer, through daily builds and end-of-sprint demos. Agile relies on a very high level of customer involvement throughout the project, but especially during these reviews.
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 greater concern than releasing a full feature set at initial launch, Agile can more quickly produce a basic version of working software which can be built upon in successive iterations.
• Development is often more user-focused, likely a result of more and frequent direction from the customer.
And, of course, there are some disadvantages:
• The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.
• Agile works best when members of the development team are completely dedicated to the project.
• Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted timeframe. Additional sprints (beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation.
• The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible. However, there are a variety of ways to handle this issue, such as webcams, collaboration tools, etc.
• The iterative nature of Agile development may lead to a frequent refactoring if the full scope of the system is not considered in the initial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.
Making the Choice Between Agile and Waterfall
So, how do we choose? We consider the following factors when considering which methodology to use:
The factors above are not equally weighted, thus each should be assessed depending on the individual project and circumstances. Once you have decided which basic methodology to utilise, you can further refine the process to best fit your project goals. Ultimately, although the way in which you do your work is important, delivering a solid and maintainable product that satisfies the customer is what really counts.
Beck, K et.al (2001). ‘The Agile Manifesto’, AgileManifesto [Online]. Available at http://agilemanifesto.org/principles.html (Accessed Nov. 2016).
Górski J. and Łukasiewicz, K. (2013). ‘Towards Agile Development of Critical Software BT – Software Engineering for Resilient Systems: 5th International Workshop’, SERENE 2013, Kiev, Ukraine, October 3-4, 2013. Proceedings. In A. Gorbenko, A. Romanovsky, & V. Kharchenko (Eds.) (pp. 48–55). Berlin, Heidelberg: Springer Berlin Heidelberg. Available at http://link.springer.com.libezproxy.open.ac.uk/chapter/10.1007/978-3-642-40894-6_4 (Accessed Nov. 2016).
Jézéquel J.M. (2014). ‘Model-Driven Engineering for Software Product Lines’, Model-Driven Engineering of Information Systems (pp. 51–110). Apple Academic Press [Online]. Available at http://www.crcnetbase.com.libezproxy.open.ac.uk/doi/pdf/10.1201/b17480-4 (Accessed Nov. 2016).
Mellor S.K, Clark A.N. and Futagami T. (2003). ‘Model-driven development – Guest editor’s introduction,’ IEEE Software, vol. 20, no. 5, pp. 14-18, Sept.-Oct. 2003. [Online]. Available at http://ieeexplore.ieee.org.libezproxy.open.ac.uk/stamp/stamp.jsp?arnumber=1231145 (Accessed Nov. 2016).
Schmidt. D (2006). ‘Model-Driven Engineering’, IEEE Computer, Vol. 39, No. 2, February 2006, pp. 41-47. Available at http://www.dre.vanderbilt.edu/~schmidt/PDF/GEI.pdf (Accessed Nov. 2016).
Unhelkar, B (2012). ‘The Art of Agile Practice’, Auerbach Publications, pp 71-96 [Online]. Available at http://www.crcnetbase.com.libezproxy.open.ac.uk/doi/pdf/10.1201/b13085-5 (Accessed Nov. 2016).