Success Fail

Why Agile fails.

Before we talk about how and why agile fails, let’s talk about what Agile promises. Agile and it’s supporters make promises. These are:

  • Visibility
  • Quality
  • Adaptability
  • Reduced risk

Visibility

Agile promotes visibility by merging responsible business units into one team. The team is mandated to deliver the maximum amount of business value by following a general set of guidelines. All team members are responsible for delivering the value in collective ownership model. For example, this enables sales will know early when there is a problem fixing a certain bug. Also, marketing will know why a particular feature request will take 6 months. The cross-functional visibility allows better understanding of the cost/feature ratio.

Quality

Teams are tasked with delivering an agreed upon number of stories at the end of each iteration. The stories must be complete at the end of the iteration. This means “defect free” to the best ability of the team. The technical side of Agile asks for Continuous Integration servers, Unit Testing, QA oversight, and other processes to ensure the code quality is kept high. The commitment to code quality keeps customer satisfaction high and costs low. This is often cited as a major need for an Agile implementation.

Adaptability

Agile accepts that change is inevitable. Agile team members are encouraged to embrace change as opportunity for improved user satisfaction and market competitiveness. Developers are especially encouraged, as change allows them to seek new ways to solve new problems.

Reduced Risk

Agile businesses reduce risk by better forecasting of budget and product delivery. An agile company has a better chance of delivering a product which matches the customer needs. Technical risk are mitigated by finding out why doesn’t work early and continually improving the technology and surrounding processes.

This all sounds great. Your company would be crazy to not adopt Agile practices. Recently, there has been a backlash against agile management practices. This backlash is caused directly by the failure of an Agile implementation. The ruthless truth, it sometimes fails. I’ve worked with both successful and failed Agile teams. Also, I’ve implemented Agile both successfully and unsuccessfully. In the spirit of collective ownership, I own part of that failure. If it’s so great, why do Agile implementations fail? Here’s what I’ve seen.

Why Agile Fails

Weak business adoption

Yes. This is #1. Agile is a business mindset. Often, business leaders (C-suite and middle management) view Agile as “something for the IT department”. However, business members need training and coaching just like everyone else. This is a major problem for C-level executives and owner/founders. Their mindset might not be malleable to changing their behavior. Without adoption at the top-level, business leaders become Agile saboteurs. Agile is for the business. We strive to deliver the best possible product which meets the needs of our customers. Business leaders need to adopt and modify their practices to support the goal. The practices are the same for everyone else; work in iterations, work transparently, set goals, commit to your goals, etc…

Here are a few key identifiers of when business leaders need help with adoption:

  • Lack of input on product features
  • Lack of understanding on product functionality
  • Weak knowledge of product backlog
  • Poor knowledge of product roadmap
  • Changing iteration goals
  • Lack of participation in ceremonies (stand-ups, planning, retrospective)
  • Distracted during ceremonies (using text, email, etc.)

All of the issues above point to your business leaders needing coaching.

Poor corporate culture

This is everything for which the CEO or founder is directly responsible. Agile needs a specific culture or a top-level mandate for cultural change. Corporate culture has a direct effect on the success of Agile teams. Some the major issues which are cultural in nature are:

  • Punctuality
  • Delaying meetings
  • Excuse making
  • Distractions during meetings
  • Finger pointing
  • Isolationism

These cultural issues point to a larger problem. They prevent adoption of the four Agile promises.

 The cultural push back

Agile is still on its early learning curve for most organizations. The technical practices are well-known, easy to adopt, and show success. Code quality keeps getting better resulting in higher customer satisfaction. However, the business and cultural practices are fighting back. The greater transparency, collective ownership, and goal setting principles are breaking down the isolation walls of middle and senior management. Now, the business leaders are being:

  • Asked to account for their time
  • Challenged on their decisions
  • Challenged to justify their directives

This is a good thing! Employees are working together. They’re looking at the greater picture and thinking about the customers and the business. They’re looking for you to be a leader not just a boss.

I suggest that C-level executive and owner/founders evaluate themselves. The traits which are most amenable to Agile adoption are:

  • Book reading… blogs don’t count! 🙂
  • Humility
  • Delegation
  • Excellent time management
  • Passion for excellence

The future of Agile

As an Agile coach, I see two ways forward:

  • Only take engagements with a high-chance of success
  • Treat Agile as a technical practice

Corporate Assessment

It’s easy to do a one-day assessment of an organization. Develop an honest and full report on the success-likelihood of Agile for their organization. I’m currently suggesting that all companies I work with to go through this process. A report which says “No” is much cheaper and less painful than a failed implementation. I detail who is likely to obstruct the process and why. I also suggest ways to address the problem.

Agile as a technical practice

An organization or team can benefit from the technical practices of Agile even if the answer is “No” from a corporate assessment. Engaging with a client and defining the parameters of the Agile implementation can return a measurable benefit to the organization. This won’t help with visibility or reduced risk, but it will result in happier customers and developers.

Final Thoughts

Agile coaches need to communicate Agile as a spectrum. We need to convey the concept Agile as a continuum on which a particular company may only get to 10% Agile. We need to speak of Agile not as a business transformation process (although it can be!) but rather as an option to solve pain. How much Agile-surgery a company can tolerate depends on the leadership of the company.

When we start thinking of Agile this way we don’t measure our success in terms of “Is the company Agile?” Rather, we measure our success in terms of how much pain did we reduce and how much happier are the people. That what the first Agile principle is all about. We value “Individuals and interactions over processes and tools”.

Wm. Barrett Simms
Follow Me
Latest posts by Wm. Barrett Simms (see all)