Why agile projects fail: 3 ways to break the cycle

Maybe you’ve been through an agile project that looked like this: Design, build, test, deploy, and then blame other internal teams when the agile project fails. Here’s how to do better
406 readers like this.
IT metrics

Agile is everywhere: More than 97 percent of companies that develop software have some form of agile framework in their delivery cycle, according to the CollabNet VersionOne State of Agile report. Most agile implementations, however, are not successful. Eighty-three percent of organizations have less than high levels of agile competency, which indicates that there’s a lot of room for improvement if businesses want to unlock agile’s promised value.

3 reasons agile projects fail

During the past decade and a half, I’ve met leaders from more than 15 large and small companies across industries as they implemented agile capabilities. In nearly every case, three barriers to a successful implementation stood out:

  • Many businesses previously tried to adopt agile and failed at some point – some more than once.
  • Each organization set out to establish agile methodologies without providing teams with a clear understanding of why.
  • After a failed agile implementation, stakeholders walked away thinking the initiative was a wasted effort and cringed when they heard the word “agile.”

If this sounds like your experience, you’re not alone. Agile implementation attempts are part of the reason failure rates on IT projects are so staggeringly high. Failed implementations typically play out like this: Teams are socialized internally so that the goal is to adopt agile, roles are rebranded, Gantt charts split work into two-week iterations, and daily standup-status meetings are slowed by micromanagement. The organization now follows a software development cycle consisting of “design, build, test, deploy, and then blame other internal teams when the project fails.”

A failed agile implementation creates the illusion of change while maintaining the status quo and causes fallout in the form of over-processing, additional hand-offs, more coordination meetings, and unnecessary lateral motion within the organization. It all amounts to waste, so it’s no wonder teams are left feeling like they squandered their time.

[ Read also: Agile vs. DevOps: What’s the difference? ]

How to rethink agile projects

Agile isn’t a business objective; the transformation it enables is. To break free from a cycle of failed agile implementations, you need to re-align your perception of agile. Through assessment, testing, and optimization, you can guide your organization through a successful transformation aligned with agile ways of working. Here’s how to get started.

1. Assess

Agile is a change to the overall structure, not a business objective that can be added on.

As human behavior follows organizational structure, executives must view their organization as a system and assess what it will take to achieve their system optimization goals. Fundamentally, agile is a change to the overall structure, not a business objective that can be added on to the existing structure. The best way to achieve this is to identify the current challenges preventing your organization from shifting to a better way of working. There are two ways to achieve this:

  • Map your company’s value stream to see the full cycle of what’s involved in developing new software.
  • Identify variables preventing change and create a systems model that shows how different organizational systems interact.

2. Test

An effective agile transformation creates change from the inside out and builds the muscle memory and behavior for continuous change through short-term experiments. What makes an organization truly agile isn’t the adoption of a superficial process; rather, it’s the ability to learn and change your structure through experimentation. Before you begin testing organizational changes, create an agile charter so all involved stakeholders understand how the project will be validated and when it is considered complete.

3. Optimize

Organizations that have gone through successful systemic change will tell you that it was chaotic and that sometimes the team thought about giving up. Just like a person on a fitness plan or a diet, you’ll have good days and bad days throughout the journey.

Look for areas with too many processes, handoffs, and approval gates.

If you refocus your efforts on changing structure and behavior, you can create new habits that empower your organization to effortlessly pivot and persevere. Using your system assessment, examine how to reduce waste. Look for areas with too many processes, handoffs, and approval gates. Each of these is an opportunity to redefine the organizational structure and impact employee behavior.

View agile as a process, not an outcome

Software product development isn’t a manufacturing line where one person assembles a piece of the unfinished product and hands it over to the next person in a predictable, repeatable process.

As a result, businesses that want to become agile must adapt the way they transform and view it as a process, not an outcome. By supporting experimentation and creating a feedback loop, organizations can organically produce effective structures that yield higher quality products and greater ROI from software development initiatives.

[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook:  Teaching an elephant to dance. ]

Guillermo De Anda Quevedo has more than 15 years of experience in the technology industry with a focus on enabling companies to meet their full potential for software delivery in a lean and agile way.

Comments

Your Agile project fails because Agile is designed for projects whose goal it is to come up with a GUI of some sort. If you are not doing that, Agile is worthless - and, if you are, Agile will be of a limited usefulness.

The truth is that Agile is more a matter of faith than anything else.