Section 1: Introduction: ‘Agile’ Project Management Methodology
There is market and academic debate about the utility of ‘Agile’ as a methodology to manage 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’ (Merino, 2016). This paper discusses the merits of Agile and attempts to answer the question: ‘Is Agile a better way to manage projects, than traditional methods?’ (Lakemond et al., 2017)
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). Agile methodologies build in requirements and specifications changes (Kerzner, 2013) and are spreading outside IS/IT and into other domains (Lechler & Yang, 2017).
Agile attempts to increase the success rate of projects and mitigate failure (Madadipouya, 2015). Traditional methods such as Waterfall or Phased-approaches, offer a controlled and deliberate approach (Read, 2017). These methodologies are criticized for a high failure rate (Cooper, 2016).
1.2 What is the Traditional approach?
Traditional methodologies use phased approaches 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). Figure 1 below compares the traditional approach with Agile.
Figure 1: Comparison of Agile and Waterfall (Read, 2017)
Traditional methodologies given in Figure 1, can be long and subject to delays (Dingsøyr et al., 2012), which can lead directly to project failure (Lakemond et al 2017). Clients must wait until a product is produced to see if the requirements were implemented correctly. Often, the entire development would be restarted or changed significantly, adding to time and costs (Kendrick, 2016).
1.3 Academic reviews on Agile
Literature scans reveal marked increases in interest around Agile in both academia and business practice since 2005 (Dingsøyr et al., 2012). Recent studies reveal an emphasis on distributed team management, culture, training and the difficulty of embedding client interactions inside a development process (Lechler & Yang, 2017). Some academic reviews claim that from 2002, rates of success with Agile are 2-times higher than that of Waterfall (Orlowski et al., 2017). Other studies also indicate that many teams embed Agile ideas within traditional Waterfall processes to create ‘hybrid’ development structures within traditional ‘stage-gate’ models (Sommer et al, 2014).
Section 2: Critical evaluation of Agile
Table-1 below provides a summary of the strengths and weaknesses (objections) of Agile (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 and a defined scope. |
| 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.
|
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-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; Cunningham, 2017, Lechler & Yang, 2017)
Key points presented by Table-1 would include:
- Agile works best with dedicated teams who are trained with clients who can dedicate time to be a part of the Agile team.
- Agile development must be automated.
- Integrated testing must be built into the processes and engineer training.
- Governance of risk, documentation, requirements project (sprint) reviews; 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
The question posed in the introduction was: ‘Is Agile a better way to manage projects, than traditional methods?’ The strengths and weaknesses of Agile leads to the answer. Quite likely most firms could use a hybrid Agile methodology which would mitigate risks of going all-in with Agile.
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 (Lechler & Yang, 2017). 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 cultural mindset important to professionalize project management practices (Orlowski, 2017). Enhanced communication, clearer requirements, better delivery, automated testing, stable production environments and more relevant code are usually the result of Agile (Dingsøyr T. et al., 2012).
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 (Sommer et al, 2014). There are many benefits to this approach including: improved communication, testing, documentation, and risk management (Sommer et al 2014.)
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 (Tan, 2017). It may be prudent to attempt a hybrid Agile methodology, before committing to a purer form of Agile.
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)
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. 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)
Orlowski, C et al (2017). Quantitative Assessment of the IT Agile Transformation. Procedia Engineering. Volume 182: pages 523-531.
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.
Tan, G. (2017). Why Domain Knowledge is Important in Project Management. Available at: http://project-skills.com/domain-knowledge-important-project-management/ (Accessed: 16/5/2017)