Agile vs Waterfall – a comprehensive review of Agile’s utility

Section 1: Introduction: Why the debate on ‘Agile’ Project Methodology is important

There is market and academic debate about the usefulness and success of ‘Agile’ as a methodology to manage IS/IT projects.  In the IT media, there are competing claims that most Agile projects fail (Cunningham, 2017), or that Agile has a much higher success rates than traditional methodologies such as Waterfall, or ‘stage-gate’ (Mersino, 2016).  Agile is spreading outside IS/IT and into other domains as a methodology to help project managers better manage complexity (Lechler & Yang, 2017).  Any project or system that has many deliverables, changing demands and client interaction, can use Agile (Pierce, 2016).

The general debate on Agile as a project management and deployment methodology is important.  Agile proposes a compressed, interactive, and automated approach to project management and deployment (Agile, 2001).  Agile attempts to increase the success rate of projects and mitigate failure (Madadipouya, 2015).  Traditional methods such as Waterfall or Phased-approaches, offer a slower, more controlled and deliberate approach (Read, 2017).  These ‘traditional’ project management methodologies are criticized for a high failure rate (Cooper, 2016).

The key question to be answered would appear to be: ‘Is Agile a better way to manage projects, than traditional methods?’ (Lakemond et al., 2017).  The answer is clear, obvious with a clattering ‘YES IT IS’.

 

1.1 What is Agile?

Agile is based on quick development of discrete functionality and incremental delivery, while constantly interacting with the client (or business).  Each ‘cycle’ within Agile, is based on the previous cycle, client feedback and integrated testing (Dingsøyr et al., 2012).  Flexibility and responsiveness are built into Agile (Pierce, 2016). Given the potential for a change in customer needs during a project life-cycle, Agile methodologies build in requirements and specifications changes (Kerzner, 2013).

There are many implementations of Agile with Scrum being the most popular.  Agile methods rely heavily on the use of technology to capture requirements, changes and to promote continuous software development, testing and delivery (Pierce, 2016).  Training and the use of automation are central to Agile success (Cunningham, 2017).

Note that ‘DevOps’ or the current fetish ‘DevSecOps’ is a subset of Agile.  If you are deploying a DevOps model the methodology of project control, management, documentation, governance and development is ‘Agile’ and quite likely ‘Scrum’ which is an implementation of Agile. 

1.2 What is the Traditional approach?

Hansson et al (2006) in an academic review claimed that traditional development methods put up barriers between engineers and the client after the requirements and scope were signed.  These traditional ‘command and control’ processes are phased approaches following a certain pattern often incorporating ‘stage-gates’ and signoffs between various well-defined stages including: scope, a first stage development, testing, demonstration, a review and rebuild (Abrahamsson et al 2009).  This first iteration, is then followed by a second stage development including deployment, testing, and a review leading to a third stage.  All of the stages in the traditional cycle are aimed towards a final product (Sommer et al 2014).  Figure 1 below compares the traditional approach with Agile.

Figure 1:  Comparison of Agile and Waterfall (Read, 2017)

The traditional methodology given in Figure 1, can be long, cumbersome, and subject to delays (Dingsøyr et al., 2012).  As well there is often a lack of communication between the development team and the client which can lead directly to project failure (Abrahamsson et al 2009).  Clients must wait until a product is produced during the stage development, to see if the requirements were implemented correctly.  Often, there would be issues and the entire development would be restarted or changed significantly, adding to time and costs (Kendrick, 2016).  Errors would not be found before deployment, or a lack of clarify on requirements would lead to poor design and implementation (Martinelli & Milosovic, 2016).

Figure 2:  Scrum Process which is the most popular implementation of Agile

1.3 Academic reviews on Agile

Agile methodologies were developed to overcome the perceived deficiencies of traditional ‘Waterfall’ methods.  Literature scans reveal marked increases in interest around Agile in both academia and business practice since 2005 (Dingsøyr et al., 2012).  Recent academic reviews on Agile reveal an emphasis on distributed team management, culture, training and the difficulty of embedding client interactions inside a development process (Lechler & Yang, 2017).  Studies also indicate that many teams embed Agile ideas within traditional Waterfall processes to create ‘hybrid’ development structures within traditional ‘stage-gate’ models (Cooper, 2016).  Such investigations of ‘hybrid’ models strongly suggest that they will form a distinct area of investigation within the academic Agile review (Sommer et al, 2014).

Section 2: Critical evaluation of Agile

Table-1 below provides a summary of the strengths and weaknesses (objections) of Agile, found in academic reviews and within general market practice.  The strengths of Agile highlight its general weakness regarding training, knowledge and culture (Read, 2017).

Table 1:  Critical evaluation summary of Agile

Strengths	Objections	Mitigation of Objections
1-Client sees work delivered, can make changes throughout development.	Many clients don’t have the time to invest in a compressed interactive cycle.	Complete understanding of scope and requirements.
2-Client interaction ensures ownership and interest in the project.	Client involvement often leads to additional requested features adding cost and time	Agile works well if there are dedicated teams.
3-Iterations producing discrete functionality are usually easier to build, test and approve.	Many projects don’t need to produce smaller discrete sub-projects.	Automation of processes and output.
4-User focused development, given extensive client involvement.   https://apotekerendk.com/	If full scope not understood, frequent code changes result from Agile methods. Especially true with complex, integrated systems.	Governance models are mandatory including RACI, RAID.
5-Agile teams are usually smaller, improving communication and workflows.	Agile workflows can be quite complicated with many smaller Agile teams needing to work together and communicate.	Governance of teams through joint committees.
6-Quality standards can be higher because development, testing and delivery are automated.	Quality can suffer if automation not used properly or training is inadequate, or constant scope changes.	Training is essential and proper automation.
7-Production environment is frozen. This creates stability.	Production environment can still be frozen with errors.	Process flow to ensure immutability is vital.
8-The development environment is the same as the Production environment reducing deployment errors.	Usually there is a ‘handoff’ from pre-production, to production, so errors can still occur.	Development processes automated and tested.
9-Shorter life cycles preclude enormous documentation.	Not having proper documentation increases Risk and reduces quality.	Governance structures.

(Pierce, 2016; Abrahammson et al 2009; Madadipouya. K, 2015; Chow & Cao, 2008; Cunningham, 2017, Lechler & Yang, 2017)

Key points presented by Table-1 would include:

1. Agile works best with dedicated teams who are trained with clients who can dedicate time to be a part of the Agile team.
2. Agile development must be automated. There are many forms of ‘Agile’ and many tools to support Agile.  Appropriate tools and technique choice is vital for Agile success.
3. Integrated testing within Agile is one of its chief strengths and this must be built into the processes and engineer training.
4. Agile is an attempt to improve project management and professionalization and is as much a cultural shift in mind-set, as it is a use of methods and technologies.
5. Governance of risk, documentation, requirements and change requests are fundamental to have success with Agile.

(Kendrick, 2016; Kerzner, 2013; Martinelli & Milosovic, 2016; Cunningham, 2017)

The above points inform whether a firm should use Agile, Waterfall (stage-gate), or a hybrid.

Section 3:  Conclusions

In the introduction section, the question was asked: ‘Is Agile a better way to manage projects, than traditional methods?’  The answer based on the academic reviews and market practices outlined in this paper is simply, ‘it depends’.  Agile is not a panacea, it is not easy, and involves an almost complete change of culture and mindset (Cunningham, 2017).  These are the primary reasons why Agile projects can fail.

Agile demands an intense use of technology to automate processes which can be complicated, necessitating expensive re-training of staff, or the hiring of external experts (Abrahamsson et al 2009).  Unfortunately, Agile for many teams has become an excuse not to document, to constantly change scope and requirements and to produce ‘code on the run’, all of which can lead to project failure (Madadipouya, 2015).

The strengths of Agile however, make the process and associated mindset an invaluable approach to professionalizing project management and deployments. Enhanced communication, clearer requirements, better delivery, automated testing, stable production environments and more relevant code are usually the result of Agile (Mersino, 2016).  A focus on relevant innovation also leads to better platforms and the ability to respond to business demands and new products (Read, 2017).

The literature and practice review indicates that the benefits of Agile are now being used to create ‘hybrid’ environments, where the risks of going ‘all-in’ on Agile are mitigated, by infusing Agile best practices into Waterfall or stage-gate methodologies (Cooper, 2016).  This approach can have the following advantages:

• Improved culture, communication, intra-and inter-teams
• Usage of graphical and intuitive progress metrics,
• Robust planning, based on iterative feedback,
• Timely resolution of documentation issues within the process enforced by a governance policy,

(Cooper, 2016; Agile Manifesto, 2001)

In summary using Agile will depend on what you are building, the type of project, in house skills and culture and if the benefits of using Agile outweigh the risks.  For example, some firms might decide that deploying more test versions within a Waterfall methodology, and to engage the client more often during the development process is a significant change which will generate real benefits – without having to go ‘all-in’ with Agile (Sommer et al 2014).  The Waterfall and stage-gate methodology does not have merit.  IT is iterative and so too must be the deployment methodology.

Agile	Waterfall
Architecture informal and incremental, current and end states are usually not documented or well known; requirements vague or ‘visionary’	Current and end states are well known, understood and documented, requirements clear, obvious
Developers share ownership of code	Silos of development, testing, business knowledge
Continuous integration and delivery	Integration and delivery are viewed as phases and milestones
Iterative to complete tasks and functionality	Milestones and stage-gate based, not iterative
Relies on best engineering practices (design patterns, test cases etc)	Relies on micro-management driven by project managers, not technical SMEs
Light process and documentation; focus on pilot projects and delivery	Heavy documentation, processes with a focus on control, not delivery, meetings a priority not pilot projects
Requires cross training across technologies and testing, technically driven	Main roles are project management related not technical
Business embedded inside Agile teams with the team composed of engineers, testers, business owners, QA and the sponsor	Silos of stakeholders, limited information exchange, formal procedures for communication

References:

Abrahamsson, P. Conboy, K., Wang, X.(2009). ‘Lots done, more to do’: the current state of agile systems development research. European Journal of Information Systems, 18, pp.281-284

Agile Manifesto, (2001). Agile manifesto and principles: Manifesto for agile software development. Available at:  http://agilemanifesto.org (Accessed: 14-07-2017)

Chow, T. and Cao D., 2008. A survey study of critical success factors in agile software projects. J. Syst. Software, 81: 961-971

Cooper, R. (2016).  Agile-Stage-Gate Hybrids. Available at: http://www.five-is.com/wp-content/uploads/Agile-Stage-Gate-Cooper-in-RTM-20162.pdf (Accessed: 15-07-2017)

Cunningham. L (2017).  8 reasons why Agile Projects fail.  Available at: https://www.agilealliance.org/8-reasons-why-agile-projects-fail/ (Accessed: 15-07-2017)

Dingsøyr T. et al., (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software. Vol 85, Issue 6, pages 1213-1221

Kendrick, T (2016). How to Manage Complex Programs: High-Impact Techniques for Handling Project Workflow, Deliverables, and Teams. Amacom Div. New York.

Kerzner, H. (2013). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 11th edition. Wiley & Sons, Canada.

Lakemond, N., et al. (2017). Match and manage: the use of knowledge matching and project management to integrate knowledge in collaborative inbound open innovation.  Ind Corp Change (2016) 25 (2): 333-352.  Available at: https://doi.org/10.1093/icc/dtw004 (Accessed 19/05/2017).

Lechler, T. & Yang, S. (2017). Exploring the Role of Project Management in the Development of the Academic Agile Software Discourse: A Bibliometric Analysis. Project Management Journal, 48(1), 3–18

Madadipouya. K, (2015). An Examination and Evaluation of Agile Methodologies for Systems Development. Australasian Journal of Computer Science, 2: 1-17

Martinelli, R., Milosevic, D., (2016). Project Management Toolbox:  Tools and Techniques for the Practicing Project Manager. John Wiley and Sons.

Mersino, A. (2016). Agile projects are more successful. Available at: http://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects (Accessed: 15-07-2017)

Pierce, W. (2016). Agile: Strong and Weak Points. Available at: https://atlaz.io/blog/agile-strong-and-weak-points/ (Accessed: 10-07-2017)

Read C. (2017). Agile and Waterfall Methods can both be valid.   Available at: https://craigread.cloud/agile-and-waterfall-methods-can-both-be-valid/ (Accessed: 10-07-2017)

Sommer, A. F. Dukovska-Popovska, I., and Steger-Jensen, K. (2014). Agile product development governance next-generation Stage-Gate process? Research-Technology Management 58(1): 34–44.