UltraVista Inc

Exploring Agile Projects Failure

The Agile methodology as a popular framework for software development and project management, emphasizing its flexibility, iterative process, and emphasis on collaboration. Agile methodology is important for several reasons, particularly in the context of software development and project management, as we have explained in this article. Here are some key points that highlight its significance:

• Flexibility and Adaptability: Agile allows teams to respond to changes quickly. Unlike traditional methods, which often require a rigid plan, Agile embraces change even late in the development process. This is crucial in a fast-paced environment where requirements can evolve.
• Customer Satisfaction: Agile focuses on delivering small, incremental updates to the product, which means customers can see progress and provide feedback regularly. This ensures that the final product is more aligned with customer needs and expectations.
• Improved Quality: By breaking down the project into manageable units, Agile enables teams to focus on high-quality development, testing, and collaboration. Regular reviews and iterations help in identifying and fixing issues early, leading to a more stable and reliable product.
• Faster Time-to-Market: Agile’s iterative approach means that a basic version of the product can be released quickly. This allows businesses to start reaping the benefits early and also gather user feedback to improve subsequent iterations.
• Enhanced Collaboration and Communication: Agile promotes a collaborative culture where cross-functional teams work closely together. Daily stand-ups, sprint planning, and retrospectives ensure that everyone is on the same page, which enhances teamwork and communication.
• Risk Management: By delivering in smaller increments, Agile reduces the risk of major failures. Issues can be identified and addressed early, minimizing the impact on the overall project.
• Continuous Improvement: Agile encourages regular reflection and adaptation. Teams regularly assess their performance and processes, making necessary adjustments to improve efficiency and effectiveness.
• Empowerment and Motivation: Agile empowers team members by giving them more autonomy and responsibility. This can lead to higher job satisfaction and motivation, as team members feel more invested in the project’s success.
• Transparency: Agile practices such as daily stand-ups, sprint reviews, and visible progress tracking (e.g., Kanban boards) provide transparency. Stakeholders can easily see the status of the project, which builds trust and facilitates better decision-making.
• Scalability: Agile can be scaled to fit projects of various sizes and complexities. Frameworks like SAFe (Scaled Agile Framework) and LeSS (Large Scale Scrum) allow large organizations to implement Agile practices across multiple teams and departments.

Agile methodology is important because it enhances flexibility, improves quality, ensures customer satisfaction, and fosters a collaborative and transparent work environment. These benefits make Agile particularly well-suited for dynamic and complex projects where requirements and solutions evolve through collaborative effort.

Despite its advantages, Agile has faced challenges when implemented in large enterprises, especially in Canada. The failure rates of Agile projects in these environments have raised concerns. This blog has addressed these concerns in several occasions, here, here, and here.

So are going to explore why Agile projects fail, particularly in large enterprises, focusing on organizational factors, resistance to change, and implementation missteps. We will also present specific examples from Canadian companies and explore relevant statistics on Agile project failures. We are going to adopts a multidisciplinary lens to explore these questions, offering insights into malpractices of some major Canadian project failures.

Overview of Agile in Large Enterprises

Agile Methodology: In this overview of Agile methodology, we are going to highlight its key principles, practices, and frameworks, including principles such as adaptability, collaboration, and customer feedback, with emphases on Agile frameworks like Scrum, Kanban, and Lean.

The core principles of Agile methodology are based on the "Agile Manifesto" (as explained in details) here, which outlines four core values and twelve principles. These emphasize:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Agile methodology is iterative and incremental, with a work (backlog) divided into small, manageable chunks called iterations or sprints, typically lasting 1-4 weeks. It is very collaborative, because cross-functional teams work closely together, fostering communication and teamwork. And adaptive, as based on the Agile principle "welcome changing requirements, even late in development", Agile embraces change, allowing teams to pivot quickly based on new requirements or feedback. It is also customer-centric and transparent, since relies on regular feedback from customers and stakeholders, and the progress is visible to all stakeholders.

The most popular Agile Frameworks are:

• Scrum: The most widely used Agile framework, focusing on sprints, roles (Product Owner, Scrum Master, Development Team), and ceremonies (as explained here).
• Kanban: A visual workflow management method that emphasizes continuous delivery and limiting work in progress (WIP).
• Extreme Programming (XP): Focuses on engineering practices like test-driven development (TDD), pair programming, and continuous integration.
• Lean Agile: Combines Agile principles with Lean manufacturing concepts to eliminate waste and deliver value efficiently.
• SAFe (Scaled Agile Framework): A framework for scaling Agile practices across large organizations.
• Disciplined Agile (DA): A Project Management Institute (PMI) toolkit that provides guidance for tailoring Agile practices to specific team or organizational needs.

Agile in Large Enterprises: We should discuss the appeal of Agile for large organizations — speed, flexibility, and customer-centric focus, in spite of the complexity that large enterprises face when adopting Agile at scale.

After Agile Manifesto was released in 2001, managers and developers become eager to taste and experience what was the whole fuss about, and they started experimenting with Agile and Scrum on a small-scale project, and experiencing first successes.

Side Bar: The motivation for me to embrace Agile had do to with the necessity and large number of projects I managed for the small consulting organization, and the huge amount of project documentation the development teams had to produce. We adopted Agile/Scrum because it considers a lot of documentation as “waste” that needs to be eradicated in order to streamline the development lifecycle, which gave developers much more time to explore new and emerging Internet technologies.

Based on the initial successes, organizations started placing more and more projects in the Agile mill, eventually fermenting every single initiative as "Agile". And Agile became a silver bullet for solving any organizational headache ("we are doing Agile"). That is when Agile gurus and methodologists (Dean Leffingwell, creator of Scaled Agile Framework (SAFe), Scott Ambler and Mark Lines, creators of Disciplined Agile), came up with "Organizational Agile" methodologies, Agile tools that can make organization’s work more effectively and that can provide straightforward guidance for identifying potential improvements that are likely to work in the context that organization faces, enabling teams to reduce the number of failed experiments and increase the rate of overall improvement.

Though beautiful on the paper, SAFe and DA implementations at the organizational level require a lot of time, energy and a lot of money. While SAFe and DA have many devotees (others say fanatics) who believe these methodologies provide a structured and scalable approach to Agile that can be beneficial for large organizations, it also receives a significant share of criticism. Some say that with its long-term planning practices, excessive bureaucracy and an inefficient hierarchical structure, these methodologies resemble more Waterfall approach than to Agile. Others complain about their proscriptive structures, being overly complex, lack of flexibility, cultural shift, and very strong focus on certification program.

Side Bar: Although I am Certified Scrum Master (CSM) and SAFe 5.1 Advanced Scrum Master (ASM), the closest I have ever come close to excellent organizational methodology was back in 1998-2000 years, when General Electric (GE) made a significant quality push with Six-Sigma methodology. It was under genius conducting of Jack Welsh as the driving force behind this implementation, acting as a figurehead for the rest of the company to rally behind (leading by example), that GE initiated complete overhaul of all its fundamental operations. I principally embraced the Six-Sigma approach, and the project I was managing, the "369 Motor Management Relay" was awarded as the Six-Sigma product of the year in GE Industrial Systems business, in a very steep competition. Good old times.

Common Causes of Agile Project Failures

Agile As Magic Bullet: Enterprise managers like to use the word "Agile" as a buzz word. One can't blame them for being easily seduced. Their clients or supervisors may have heard about the marvels of agility and how some really flashy tech companies have made big bucks by going Agile. So, they would like to sell them a bag of Agile. I have been amazed with the amount of naivety of some people, and seduction based on building Agile consciousness using the incremental and iterative approach. Very often when clients don't know what they want, and they are seduced into thinking that Agile is answer to their troubles, they are easily sold on Agile, and that is one of the common causes for failures.

Organizational Resistance to Change: Many large enterprises have established hierarchical systems and rigid processes that conflict with Agile's flat, collaborative model. Based on hierarchical and legacy inertia they hire project managers, but in reality, they need Scrum Masters. Fear of drastic changes that have been proposed as Agile, very often scare those who would benefit from the changes most. Even management buy-in is very often a challenge and cause of failure, because someone has used to be "the boss" doesn't like the tendency to relinquish control and embrace Agile's decentralized decision-making, can lead to failure. Management doesn't like to empower the team to make their own decisions, but often hide their true intentions by engaging truly non-Agile entities like PMO to "help" the decision process. Though developers know what application development frameworks and programming languages work best for them, very often these tools got selected by PMO or Enterprise Architecture groups, so the principle that "The best architectures, requirements, and designs emerge from self-organizing teams" simply doesn't apply.

Lack of Agile Experience: Insufficient training and skills very often leads to projects failure. Since Agile requires teams to have specialized knowledge, without proper training, organizations may not be able to execute Agile practices effectively. Training labor force enterprise-wide costs a lot of money, so management often cuts corners, or invest more in cross-functional individuals (heroes) who claim Agile mastery and that they can work magics within an organization. As bad that is, overlooking the need for experienced Agile coaches and Scrum Masters is even works. As said earlier, they hire project managers, but in reality, they need Scrum Masters to advance the Agile coaching, since inadequate coaching and leadership at the team level can hinder progress. I also find Agile methodology rigidness and inflexibility cause of the failure, requiring dedication and organic corporate change as "being Agile". In my long experience, even when half of the Agile development team has Agile experience, the other half can learn while during the Daily Scrum, Spring Retrospective and being relentlessly coached by Scrum Master.

Scaling Agile Challenges: Complexity of organization scaling for Agile might also trigger project failure. Agile is often implemented at a small scale with great success but faces significant obstacles when scaling up to larger teams, multiple departments or large organizations. Frameworks like SAFe (Scaled Agile Framework) are often mishandled or misinterpreted.

Misalignment Between Agile Teams and Business Units: IT organizations are shifting the focus from projects to products. Agile teams often focus on technical requirements while business units focus on broader strategic goals. Misalignment can occur, leading to wasted effort. It is better to spend time focusing on evolutionary product discovery instead of locking in requirements. Agile teams should explore business feedback by deploying early and often to make sure stakeholder priorities are in line with the user’s and inspect adapt from there. Otherwise, the waste and bloat that can happen when business units lose focus from just getting the Minimal Viable Product (MVP) out the door and then evolving the product from there, as explained here.

Statistics of Agile Failures in Large Enterprises and Canadian Insight

General Statistics: Let's start with general statistics that provide statistics on Agile failure rates in general. According to studies from large project management authorities’ sources, like the Standish Group, Garner or PMI, approximately 50-70% of Agile projects fail to meet their goals in large enterprises. Research shows that, in developed nations, such as Germany, Iceland and Norway, projects account for about 30% of economic activity. Projects that span multiple teams, business units, geographies, and organizations are inherently complex. Add in volatility, uncertainty, and ambiguity — related to turbulent industry dynamics and markets, unproven technologies, and stakeholders who can’t make up their minds — and they become even more challenging. In the corporate world, enterprise resource planning (ERP) projects stand out in terms of complexity.

“Gartner, an information technology research firm, estimated that 55% to 75% of all ERP projects fail to meet their objectives.”

"Study finds 268% higher failure rates for Agile software projects (theregister.com)".

"Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027."

Gartner Data & Analytics Summit 2024, May 13-15 in London, U.K

No one wants to brag about his programs or projects failures, particularly no PMO, no project managers, no project leads, no Scrum Masters, no SAFe Release Train Engineer (RTE). Though failure is part and parcel of life, resistance to failure in this circle is very strong. Driven by people's ego, failed part of the Agile project suddenly becomes phase on project with new life as Phase II, or Alpha prototype with Beta spinoff, or any other variant of prolonged project life and budget. Hence, it is very hard to obtain accurate data about Agile projects failures. Still, some of them were too large to escape the dutiful eyes of auditors.

• The Wrong Project: A classic business example was the acquisition of Autonomy for $11 billion by Hewlett Packard in 2011. At the time, HP CEO Léo Apotheker was looking for a big, transformative acquisition to solidify his standing — and his ego. The project was controversial from the start, as was valuing Autonomy at 79% over its market price, but it won approval from shareholders. Gaining support for execution from all stakeholders was more challenging, however, and just one year later, HP had to write off $8.8 billion. Though not typical Agile initiative, it remains as one of the strongest lessons to learn for those willing to learn out of other people's failures, and not their own.
• Unrealistic Assumptions and Constrains - Flawed Engineering and Design Decisions: When aircraft manufacturer Boeing wanted to compete with Airbus’s A320 Neo, already two years into development, the company accelerated its Boeing 737 Max development in Agile fashion ("doing more with less", "right sizing") by cutting the project time in half. Worse, it also tried to save money by cutting many corners including safety features. One of the most significant factors contributing to the failure of the 737 Max was the flawed design of the Maneuvering Characteristics Augmentation System (MCAS) system. Boeing engineers decided to rely on a single AOA sensor to provide input to the MCAS, despite the known risks of sensor failure. The tragic outcome was two fatal crashes resulting in 346 deaths, more than $20 billion in crisis-associated costs, and immeasurable reputational damage. Eventually in November 2024, Boeing was about laying off more than 2,500 workers in the U.S. states of Washington, Oregon, South Carolina and Missouri, as part of the debt-heavy U.S. plane maker’s plan to cut 17,000 jobs, or 10% of its global workforce.
• Lack of The Agile Leadership: An organization’s managers, executives, and other leaders are responsible for the adoption, success, and ongoing improvement of Agile development and the competencies that lead to business agility. They have the authority to change and continuously improve the systems that govern how work is performed. And if they don't, it leads to failure. Good example was the initial launch of Healthcare.gov, the online portal for U.S. President Barack Obama’s Affordable Care Act. When the website went live on October 1, 2013, it was largely frozen, and the problems took another two months to fix. Reporting indicated that a lack of clear Agile methodology and tech-savvy leadership on the project was one of the key reasons for this initial failure.
• Lack of Agile Experience: In 2005, Surrey (UK) Police Force made the decision to embark on an Agile project to replace their existing crime, intelligence and custody suite. The project was ambitious in terms of its goals, but the police believed the public would benefit from the good of the new system, which was required by this time with their legacy system rapidly becoming obsolete. But it was not to be. By 2007, scope creep had turned the project into an all-encompassing suite of ICT tools for the police force. Having already suffered from mismanagement and miscommunication between the provider and the police, which was not a good sign. By 2013, after more than 6 months of deliberation, the project was abandoned (with the developers needing to be paid out in full) at a cost of £15m. When the project began, the police had zero experience with Agile development methodology. This combined with scope creep early on in the project lead to complete blow outs of timelines. When finally, the project reverted to a known Waterfall methodology it was discovered there were significant issues related to integrating all modules.
• Lack of Maturity of Agile Practices - Communication: An old case but a good one, the tale of a multi-region and multi-vendor Agile project that failed in the eyes of one of the engineers on the project. Why was the project deemed a failure? The project took 3 times as long as anticipated and came in a whopping 5 times over budget. It was ambitious to begin with. Teams from Canada provided by one vendor, and the US and parts of Europe by another, to come together for a yearlong project with monthly Agile sprints. The 4 Scrum teams were a mix of co-located and remote staff. One of the team's Scrum Masters was a remote role, with on-site presence around once a month. Communications between teams, and particularly between vendors was fractured and non-time sensitive. Standups were not compliant to Agile practices. On top of that, the non-co-located Scrum master was not effective in their role. The client didn’t have the same expectations of the Agile software development process as Vendor A. In short, their Agile practices lacked maturity.

Case Studies of Agile Failures in Canada

While specific "major Canadian agile project failures" aren't widely publicized, some notable Canadian projects that experienced significant challenges and delays, often attributed to poor project management practices including improper Agile implementation.

• Lack of Agile Experience: Ottawa Light Rail Transit (LRT) is typical example what happens with Agile transit initiatives. This project faced significant cost overruns, schedule delays, and service quality issues, with criticism directed towards poor planning and management of complex system integration, often linked to inadequate Agile application.
• Unrealistic Requirements Constraints: Similar to the Ottawa LRT, the Montreal's Réseau express metropolitan (REM) also encountered major cost overruns and service disruptions, with concerns raised about the project's Agile approach not effectively managing complex dependencies and changing requirements.
• Lack of Agile Experience: Government of Canada Evaluation of Acquisition Project Management (Agile Acquisition, Innovation and GBA Plus) report, though not pointing to an exact failure, had alarming findings in understanding what is Agile methodology. "While a definition has been developed by Public Service and Procurement Canada (PSPC) and endorsed by the TBS, there is no common understanding and agreement on the definition of agility in relation to acquisition amongst the Defense Team. The Defense Team’s current guidance and documentation lack specific advice, methodologies or examples to promote agility and innovation in acquisition, and there is no agile-specific training offered. It is not clear how or when to apply agility and innovation in acquisition. Additional internal and external barriers to agility and innovation were found, such as a culture of risk aversion, staffing shortfalls, requirements around acquisition from both DND and external stakeholders, lessons learned are not timely and elements of agility and innovation are not tracked. Canada’s allies were found to have strategic commitments to agile acquisition, documentation and specific training."
• Lack of Strategic Direction: Ontario e-Health scandal a $1B waste: auditor. Ontario Auditor General Jim McCarter released his investigation into the Agile development of eHealth agency. His report says the board of directors at eHealth Ontario felt it had little power over CEO Sarah Kramer because she had been hired by chair Alan Hudson "with the support of the premier." That, gave Kramer the impression she had approval to ignore normal procurement procedures. The e-Health agency doled out millions of dollars in contracts without any apparent attempt to open the deals to outside bidders within the first four months of its creation in September 2008. Consultants were contracted by eHealth at up to $2,750 a day. They then billed taxpayers for out-of-pocket expenses that included $1.65 for a cup of tea and $3.99 for cookies. CEO Sarah Kramer billed thousands of dollars for limousine rides, including one $400 trip from Toronto to London, Ont., before she resigned from her $380,000-a-year job in June. She was given a $317,000 severance package and received a $114,000 bonus after just 10 months on the job. In conclusion, too much power in too few hands.
• Agile Planning Failure: F-35 planes not suitable for British Columbian terrain use case is typical example for lack of degree of Agile planning’ a predictor and ‘quality of the vision/goals,’ ‘project complexity,’ and ‘expertise’ moderators of project success. The Canadian Federal Government’s plans to purchase one model of search and rescue airplanes for the entire country is unsuitable and will endanger lives. The story noted that that the proposed F-35 airplanes are not suited for British Columbia’s terrain which requires the planes to “fly lower and slower and turn more sharply.” This project has already been called into question for allegedly rigging the request for proposals to favor larger aircraft. Political Scientist Michael Byers noted that this favoritism is rooted in the desire for these planes to pull “double duty for the Canadian military overseas. Even worse, a highly classified report issued by the Director, Operational Test and Evaluation to assess the initial operational capabilities of the F-35 revealed that the 25-ton F-35 stealth warplane has become the very problem it was supposed to solve. Though the manufacturer is keeping details of the problems under wraps, in April 2012, with the release of a highly critical Auditor General of Canada report on the failures of the F-35 program, the Canadian procurement was labelled a national "scandal" and "fiasco" by the media.

Video: It shows the moment when US Air Force's F-35 Fighter jet crashed In Alaska

• Lack of Leadership Buy-In: Government of Ontario’s Digital Transformation and Ontario Digital Service (ODS) failure is typical example of Ontario Public Service (OPS) management to buy-in into this Agile initiative. Though ODS may have had its flaws, it was one of the few areas within OPS actually delivering good digital products in house and advancing digital maturity across government in a meaningful way. It is a common understanding that ODS was being killed off entirely through a series of bad management decisions over the years. The Associate DMs of Service Ontario and GovTechON deplored ODS for always calling out and exposing their incompetence and utter disregard of taxpayer dollars. ODS' continued existence threatened their own credibility so they did everything in their power to prevent it from ever succeeding. In conclusion, again, too much power in too few hands.

There are more examples of Agile projects failures in large organizations, where Resistance to change, insufficient training, misalignment between Agile teams and business objectives, combined with lack of proper Agile knowledge and organizational inertia contributed to initial failures. Examples of several Canadian banks attempting to adopt Agile in the early 2010s to enhance its digital transformation and streamline operations, or of couple of Canadian major telecommunications companies attempting to implement Agile practices in their IT departments.

Strategies for Reducing Agile Project Failures

To avoid Agile pitfalls, forward-thinking companies should hire experienced executives and project management professionals who understand the macro challenges they will face. Companies should not hesitate to create of develop executive positions such as chief project officer (or RTE) to oversee the entire programs and projects ecosystem. This role is especially important in market completive and innovative organizations with ever increasing project work over the years. I have listed some significant strategies for reducing Agile project failures below.

• Proper Training and Coaching: Companies must pay attention to importance of training employees and hiring experienced Scrum Masters or Agile coaches to ensure correct implementation. Bringing in Agile experts helps to set realistic expectations, quicken the necessary resistance and chaos phase and align the team by providing best practices, tips and tools and on-going trainings, it takes an experienced Agile expert to navigate the Agile digital transformation well.
• Executive Buy-In and Support: Leadership involvement is crucial for Agile success. Without full commitment from upper management, Agile is more likely to fail. Instead of blaming others, leadership should lead the change by example, establish lifelong learning processes, inspire, unite and empower and decentralize decision-making. In addition, organizations should commit to strict governance by appointing auditors, sponsors and managers to facilitate decision making early in the project lifecycle. This is especially important for government and politically intense organizations with complex and controversial projects. Such leaders can guide open discussions of sensitive topics and investigate trade-off decisions, reducing the risk of project-killing conflicts.
• Scaled Agile Frameworks (SAFe): I would also suggest using established frameworks like SAFe to help scale Agile practices effectively in larger enterprises. SAFE has good quality practices that help organizations to remain market relevant, it helps to have a clear understanding of the product plan and increased production. The SAFE brings other benefits, like transparency, short time to market, alignment, and high customer engagement, helping large organization to remain visible in the ever-changing marketplace and achieve their competitive advantage.
• Continuous Feedback and Adaptation: Agile teams need to remain flexible and constantly adapt based on feedback to ensure projects stay on track.

In summary, the main reasons why Agile projects fail in large enterprises point to organizational resistance, lack of expertise, and scaling challenges. It is very important to go thru Agile adaptation with the need for continuous learning and adaptation when implementing Agile in large organizations. I would conclude with a call for Canadian enterprises to invest in comprehensive training, executive buy-in, and adopting proper frameworks to ensure the successful implementation of Agile.

References:

• “Agile Estimating and Planning” by Mike Cohn
• “The Lean Startup” by Eric Ries
• Articles/Reports: Standish Group CHAOS Report, PMI’s Pulse of the Profession, Agile in the Enterprise: Challenges and Success Factors (Journal articles on Agile implementation in large organizations)
• Case Studies: Agile failure case studies in Canadian companies from business news outlets like The Globe and Mail or Financial Post.