PrintIt’s no secret agile projects can fail, but do you know the reasons for agile failure and how to avoid them? I could tell you why I think they fail. Instead, let me share what nearly 4,000 of your colleagues said were the eight reasons why agile projects fail and what you can do about it.

#1 Lack of Experience with Agile Methods

According to the annual State of Agile™ survey, 44% of the respondents to the survey said they blamed the failure of agile projects on a lack of experience with agile methods.

Indeed, agile is first about how you think, but it also impacts what you do and how you do it. Teams that are deficient in the ability to apply basic agile practices tend to run into trouble. Investing in solid foundational training in agile techniques, and competent coaching as to their proper application, is money well spent.

#2 Company Philosophy or Culture at Odds with Core Agile Values

A total of 42% of the respondents said company philosophy or culture at odds with core agile values was the leading cause of failed agile projects. In fact, it was interesting to note that two of the top five reasons that caused agile failures revolve around the organization’s culture – company philosophy or culture at odds with core values and a lack of support for cultural transition (#5).

We know that agile is first about “how you think,” and then about “what you do.” If your organization’s culture is either ignorant of or outright hostile to agile principles and values, the prospect of success beyond isolated pockets of agile teams are slim. Understanding that agile impacts organizational values and facilitating that transformation is the first step to having a broader adoption of agile, and more success with agile as a means to successful delivery.

#3 Lack of Management Support

Some 38% of the respondents to the survey pointed to a lack of management support as the cause of failed agile projects.

This most typically pertains to “middle management.” In a poorly planned agile transformation, it’s not unusual for there to be great enthusiasm for agile at the team level and general support of agile at the executive level, leaving the project and program managers, functional “resource” managers, etc., in the middle of a messy “change sandwich.” Without strong executive guidance, this management layer can feel isolated and then simply dig in to survive. During an agile transformation, executive leaders need to model the behavior they want their management team to display, live the values they want them to adopt, and help them understand how they fit into the changing organization.

#4 External Pressure to Follow Traditional Waterfall Processes

Another 37% of respondents answered that they found external pressure to follow traditional waterfall processes impeding their projects’ success.

This is especially common in large enterprises, where there are agile teams and traditional waterfall teams working under the umbrella of the same portfolio. In such cases, the agile endeavors are usually being grafted into the existing traditional portfolio and project management (PPM) methodology, as opposed to the PPM methodology transforming to an agile approach. This doesn’t mean that agile can’t succeed, but it does mean that agile will need to coexist with (and to some extent, within) the traditional methodology. As I point out in the Get What you Want From Your Enterprise Agile Transformation white paper, two ways to facilitate that coexistence are to involve people from outside of the agile part of the organization in your planning, reviews, and retrospectives, and also to agree on mutual organizational interfaces for the exchange of information.

#5 Lack of Support for Cultural Transition

The survey found that 36% of the respondents saw a lack of support for cultural transition as the reason agile projects fail.

This is closely related to #2 and #3 above, Organizational values and norms evolve over time, and as they become established, they stubbornly resist change. Senior leadership holds the most leverage in facilitating the transformation of an organization’s culture to one that embraces agile. Tangible, active involvement at the executive level is critical to cultural transformation.

#6 A Broader Organizational or Communications Problem

According to the annual State of Agile survey, 33% of the respondents said they found a broader organizational or communications problem causing agile projects to fail.

To reiterate what we’ve looked at in several of the preceding points, agile’s effectiveness beyond one-off teams here and there is dependent upon broader and deeper organizational buy-in to agile values and principles.

#7 Unwillingness of Team to Follow Agile

Unwillingness of the team to follow agile was the cause of failure for 33% of the respondents to the survey.

This tends to happen when the members of a team continue to identify themselves by function (Dev, QA, etc.). Team-level resistance can also happen when there is a team member with a “strong personality” who insists on retaining his/her position at the top of the pecking order. In both cases, it comes down to a perceived loss of identity or control. Executive leadership’s effective influence on the culture and the management team, thorough training, and capable team-level coaching are necessary to overcome these impediments.

#8 Insufficient training

Some 30% of the respondents to the survey said they blamed insufficient training for failed agile projects.

“Insufficient training” comes in three flavors:

1. Nobody received training;
2. Not everybody who needed training received it; or
3. Some/all received training, but the training wasn’t very good.

Skimping on training isn’t a good idea, and never leads to a successful agile organization. Make sure that everyone involved in your agile efforts receives rock-solid training. Do it early. “Everyone,” by the way, includes your executive leadership.

Conclusion

If you’re struggling with any of these barriers to agile success, this survey proves that you aren’t alone. The theme that underlies these impediments is that they can be traced back to cultural issues in the organization. In order to have significant and lasting agile success, there’s no getting around the need for strong executive leadership, solid training, and capable coaching.

Approximately 6% of respondents said “not applicable/don’t know.”

And 7.5% of the respondents told us that none of their agile projects could be considered “unsuccessful.” Which is great news.

So how are your agile projects doing? Are they succeeding or failing?

This is the second article in a series of blog posts on the annual State of Agile survey. You can read the first article on “Top 10 Tips for Measuring Agile Success” here.

728x90-red-demo

Join the Discussion

    • David Wright

      What is the exposure to an Agile project of losing its Product Manager? I have one anecdotal experience of successful team using agile, and the team lead (scrum master?) crediting it to the combination of skilled team members and their very knowledgeable Product Manager from the related business unit. However, when the Product Manager moved on to another position, and another less knowledgeable person took on the role, the team’s success rate dropped like a stone. The team lead was working with the new PM to try to get them to be more effective, but it was taking a lot of time.

      • Lee Cunningham

        Hi David. It sounds like the original product manager in this case was acting in the product owner or “customer” role — really involved with the team and very attuned to how the product worked and what needed to be built. In my view, that role is the Achilles’ heel of Agile success: a really good one, as you’ve experienced, makes things click, and a not-so-capable one can suck the life out of the team. So yes, the situation you describe is a risk.

        In order to guard against that risk, I think it is imperative that those in that role are properly selected and trained, and that the organization supports them, just as it supports its other team members. Where that isn’t the case, the consistency from one product owner to the next is a roll of the dice.

    • Tom Hart

      Training is essential when implementing an agile process. It’s better to spend the extra time and funds ensuring that employees are proficient than running into issues over the course of the process.

      • Patrick Sinks

        I couldn’t agree more Tom. The lack of up front investment in proper training will definitely impact any Agile transformation and cost more in the long run.

    • Anjali Mogre

      The results of survey looks quite logical. Can ‘technology’ be a factor in making the Agile project success or failure? For example, it works in Java / dotnet environment , but typically does not work in ERP / PLM type of implementation projects?
      I am looking for some examples where Agile has succeeded or failed in PLM team center environment

      • Lee Cunningham

        Great question, and I’d say that the root issue has more to do complexity than a specific technology. In other words, a single cross-functional team using Java is going to move a lot quicker than 10 teams using Java working collectively on a large project. For the type of endeavor you mention (implementing a system of systems or modules), the sticking point has been figuring out how agile can be applied where capabilities that are truly valuable to the ultimate customer take more than a single iteration to develop, and depend on the work of several teams. This can be especially challenging when the technologies are mixed. We work with many organizations that are applying agile in just such a situation.

        Success in the face of such complexity requires thinking in terms of the whole system, and not just the team. This means that, yes, agile teams are delivering user stories frequently, but their work is integrated into a higher-level, aggregate solution. That solution is also released incrementally, so delivery of value to the customer is not an all-or-nothing proposition. Many folks (myself included) incurred a lot of bumps and bruises over the years trying to figure out exactly how to make that work. It’s still hard to do, but fortunately, we have gotten a lot better at it. You may find some helpful insights in SAFe.

        Now, as to success stories specific to Teamcenter, a good place to ask about those might be a Teamcenter user group.

    66 + = 76