When Agile Development Goes Wrong: Common Pitfalls in Agile Software Implementations

    Agile software failure disputes

    Various software development methodologies have been created to accommodate the needs of different projects and organizational cultures. Traditional software development methods, often known as predictive, or “waterfall” methods, typically require the creation of detailed requirements and design documentation before constructing, testing, and delivering software. 1

    In recent decades, the software industry has embraced more flexible approaches to software development. These approaches, known as adaptive or “Agile” methods, encourage the development and testing of software in rapid iterations, prioritize the creation of working software over detailed design documentation, and employ regular cycles of customer collaboration and feedback. 2

    Agile software projects, while often more effective than waterfall implementations, can still experience delays, cost overruns, and product quality issues. 3 Indeed, many of the factors that beset traditional software implementations can impede Agile projects. 

    Poor customer involvement, lack of executive support, and deviating from appropriate technical practices can harm any software project, no matter the methodology.

    In supporting software litigation in software failure disputes, DisputeSoft has investigated dozens of software implementations in which the project participants used, or intended to use, Agile development techniques. Despite the parties’ hopes, project outcomes were unsatisfactory and legal action ensued.

    A number of unfortunate patterns can be discerned from these disputes.  This article outlines several common themes in unsuccessful Agile implementations.

    Overview of Agile Development

    The term “Agile” refers to a broad set of software development principles. Arising due to dissatisfaction with traditional development methods, these principles form the basis for multiple software development methodologies, including Scrum, Adaptive Software Development (“ASD”), and Extreme Programming (“XP”). 4

    While these methods have differences, they all emphasize frequent delivery of working software, collaborating closely with customers, and self-organization of development teams. 5 Unlike traditional “waterfall” development, Agile methods de-emphasize rigid project planning and the creation of comprehensive requirements and design documentation. 6

    Agile Practices and Pitfalls

    Active stakeholder engagement, though desirable in most software implementations, is critical in Agile projects. The Agile philosophy promotes rapid software development for stakeholders to incrementally review the product and provide feedback. 7

    In the process, customers may suggest changes to existing software or request new functionality. Such requests may be added to a backlog of potential work, thus providing the basis for future development efforts.

    The effectiveness of this process depends on stakeholders’ willingness to provide regular feedback. In practice, stakeholders are sometimes unable or unwilling to consistently review and comment on delivered software. 8

    Poor stakeholder involvement reduces the likelihood that the delivered product will satisfy customer needs. Further, lack of customer participation can limit the development team’s ability to gain stakeholder acceptance for the delivered product.

    Accordingly, many Agile methods promote the involvement of a designated customer representative. Known as a “Product Owner” in some methodologies, this individual is typically responsible for prioritizing software development work and reconciling competing stakeholder requests. 9

    To be effective in this role, the Product Owner should thoroughly understand the customer’s existing business processes and desired workflow improvements. Stakeholders must also be willing to respect the Product Owner’s decisions. 10

    Ineffective product ownership is a common thread in many unsuccessful Agile implementations. In some cases, the Product Owner may not understand the customer’s workflows well enough to effectively prioritize the development effort. 11

    Others may lack the authority or political influence to enforce product decisions. Due to the difficulty and stress of the role, Product Owners can be vulnerable to burnout and excessive turnover. 12

    In addition to active customer involvement, it is important for Agile software providers to adhere to certain technical practices. For example, Agile methods encourage software to be deployed in frequent, small releases. 13

    As this practice can incentivize developers to sacrifice design and source code quality, Agile developers are encouraged to conduct frequent refactoring of existing source code to reduce so-called “technical debt.” 14 Given the rapidity of change in Agile, successful teams usually employ automated regression test techniques to ensure that modifications do not damage existing functionality. 15

    In unsuccessful Agile implementations software developers frequently deviate from the above practices. Developers may not release software often enough, precluding timely customer feedback. 16

    In an effort to prioritize completion of new functionality, developers may not address design and code quality deficiencies in existing software. 17 Also, developers may neglect to create adequate unit tests for new functionality or implement automated regression testing, allowing defects to permeate the software. 18

    Conclusion

    Despite their many advantages, Agile software development methodologies do not guarantee project success. Insufficient stakeholder participation, inconsistent customer expectations, and failure to adhere to appropriate technical practices can sabotage any software development effort.

    When analyzing software project failures, software experts should be aware of the special benefits and challenges inherent in Agile implementations. DisputeSoft’s experts have extensive experience analyzing Agile software development projects across a multitude of industries.

    About DisputeSoft

    DisputeSoft has served as trusted software failure experts on over 425 software project failure and IT failure disputes both at the pre-litigation and actual litigation stages. DisputeSoft’s proven software experts and trade secret experts deliver the most educated independent, objective and defensible analysis, opinions and testimony in any complex software disputes, software copyright infringement cases or intellectual property disputes. 

    Contact us for free consultation to see how we can help enlighten and improve your case. 

    1.  Institute of Electrical and Electronics Engineers Computer Society, A Guide to the Software Engineering Body of Knowledge (3d ed. 2014) at 7-5. ↩︎
    2.  Id. at 8-5. ↩︎
    3. Capers Jones, Software Methodologies: A Quantitative Guide (2018) at xii. ↩︎
    4. Jim Highsmith, History: The Agile Manifesto, AgileManifesto.org (2001), https://agilemanifesto.org/history.html. ↩︎
    5.  Principles Behind the Agile Manifesto, AgileManifesto.org, https://agilemanifesto.org/principles.html (last visited Aug. 16, 2023). ↩︎
    6.  Manifesto for Agile Software Development, AgileManifesto.org (2001), https://agilemanifesto.org/. ↩︎
    7.  Id. ↩︎
    8.  Gloria J. Miller, Agile Problems, Challenges, & Failures (PMI Global Congress, 2013), https://www.pmi.org/learning/library/agile-problems-challenges-failures-5869. ↩︎
    9.  Ken Schwaber and Jeff Sutherland, Scrum Guide, ScrumGuides.org (2020), https://scrumguides.org/scrum-guide.html#product-owner. ↩︎
    10.  Id. ↩︎
    11. Matt Stephens and Doug Rosenberg, Extreme Programming Refactored: The Case Against XP (2003) at 122. ↩︎
    12.  Id. at 125-126. ↩︎
    13. Manifesto for Agile Software Development, AgileManifesto.org (2001), https://agilemanifesto.org/. ↩︎
    14. Matt Stephens and Doug Rosenberg, Extreme Programming Refactored: The Case Against XP (2003) at 12. ↩︎
    15.  Id. at 8, 349. ↩︎
    16.  Id. at 69-70. ↩︎
    17. Id. at 66-67. ↩︎
    18. Id. at 66. ↩︎