7 Reasons Why Agile fails

It’s not difficult to recognize the signs of an agile approach headed towards failure. Here, we examine a number of the indications that your team is doing agile incorrectly. We also present a strong remedy for each of the problems. Finally, we’ll take a good look at how testing automation relates to agile.

Perhaps surprisingly, the problem with the approach to agile in many organizations lies not with agile itself. The problem rests with Agile, the methodology. Many practitioners insist that Agile isn't a methodology. To treat agile as a methodology is to confuse process with philosophy and culture. The result, often, is a return back to conventional development processes that were seen as lacking relevance in our brave new world of modern software development.

Why Agile isn’t fixing your problems

Most organizations are slow, broken, and bureaucratic. Employees, stakeholders, executives, and customers are unhappy with the product or service. Agile is brought in to save the day. It’s the magical cure that will solve all development and delivery problems. The competitive thinking goes something like this: Since “everyone is doing it”, shouldn’t we also?

The truth is that most agile transformations only materialize a few, if any, of the promises made at the beginning. Consultants are often brought in to repair such failures. Some of those consultants have the wrong ideas about agile. The good ones discover that too many organizations attempt to adopt agile nearly upside down. Consequently, the new processes are found to be in direct opposition to agile principles.

#1: Agile isn’t a rigid end-state, it’s a way of being

The agile manifesto tell its adherents to value “individual and interactions” above “processes and tools”. However, agile has come to represent a circus of tooling vendors and consultant selling frameworks they want to implement as a static methodology.

All too often, agile becomes the new standard methodology. The lamentable result is that attention moves firmly over to enforcing the new “best practices”. Maturity models are built to measure team compliance with the new methodology.  

One thing is sure. Jumping through all the agile hoops—while ignoring the core principles—does not lead to effective agility. 

Often, the question arises, “What shape does the organization take when the transformation is complete?” This is the wrong question, entirely. If your team establishes a goal of seeking a new, inflexible end-state, then you're way off the mark from achieving agility.  

The point of agile is to develop and maintain agility in the pursuit of building quality products. To keep pace in a rapidly changing world, a software or IT organization must be ready to change continuously. Product teams need to be agile in all respects. Successful organizations are capable of high degrees of flexibility. Such companies go well beyond the mere practices of agile. Taking the best input from everyone in the company, the leaders are continuously seeking ways to make adjustments—all the time.

#2: Agile doesn’t fix problems, it illuminates them

It’s wayward to think of agile as a solution to problems. Not directly, anyway. The application of agile principles can shine a bright light on the root-cause problems of the organization. However, the aim of agile is not necessarily to provide a fix.

The primary intent of agile is to help teams get faster. Trouble is, the increase in momentum will add pressure to the delivery pipeline. This pressure will expose the leaky pipes that need repair. And yet, frustration arises because too many of the leaks are inaccessible—deep in the core of the organization. Even executive with extensive experience may be unable to fix those buggers.

Commonly, things that need fixing include resource allocation, decision making, prioritization, policy enforcement, and organizational structure. Pursuing many such changes simultaneously might cause an earthquake. Consequently, such initiatives are often quite risky to the reputation of most any leader in the organization. 

Kanban, scrum, and other agile methods can bring agility to pockets of the company. However, these smaller efforts eventually level off—with only modest benefits. Many stall out when they encounter constraints in the organization. The challenge here is not the people or lack of skill sets. Rather, the inhibitors can be found among legacy practices, structures, and policies. Culture can be especially troublesome, as it tends to reinforce old patterns and mindsets. If these remain in place, agility will probably not reach very far.

#3: Don’t “do agile”. Be agile.

Agile is mostly a state of mind. It begins with the right attitude. If your company is emphasizing “doing agile” instead of being agile, you’re on the wrong foot right from the start.

Being agile is a shift in mentality on how to approach software development. Specific techniques and rituals are secondary. A team becomes agile by embracing and employing the philosophy given in the Agile Manifesto. By doing so, a team should have no trouble “doing agile” quite naturally and avoid agile failures.

If you would become agile, then it is essential to read the manifesto carefully. Each word is carefully chosen. Think about the implications for your team: drop useless meetings, administration, and paperwork. Focus primarily on code that works and fast feedback cycles. Self-examine, self-organize, and self-optimize. This is how you can initiate an effective revolution. And, remember that the specific practices of how to achieve the aims of the manifesto are still evolving. 

Think carefully for a moment: any notion of a “standard” agile process is quite contradictory. That’s because agile means continuous adaptation and improvement. If your team follows a one-size-fits-all agile “process” that is a mandate for all teams, then you’re doing it all wrong. 

Conceptually, the remedy is simple. Remember that the primary goal is to deliver working software, not follow a recipe. No single recipe will always work for every project or team. Therefore, insist on agile principles, But, let each team craft their own practices and take ownership in adjusting and improving those practices.

#4: Writing tasks, not agile stories

The agile story template frames a feature in terms of the benefits for a type of user. This is a clear reminder that the goal is to deliver functional software to a person that expects specific benefits from its use. If most “stories” really boil down to tasks, then you might as well admit that the development process has a task-focus—not delivery-focus. Agile encourages creating value, not “doing stuff”. It's vital for the development team to connect with users, since user-less software is, well useless.

The remedy here is balance. Though there will always be some task-like items to complete. However, a story should have a size that permits it to reach completion in a single iteration. A story that is 75% done is useless. Recall Yoda’s maxim, “Do or do not, there is no partial credit.” A story may be so complex that it cannot be done in one iteration, and yet doesn’t divide well into substories. If so, then play that story over multiple iterations.

#5: Avoiding story iteration

Maybe your team is decomposing large stories into smaller stories merely so they can be done in a single sprint. If so, then—you guess is correct—you’re doing it wrong. This practice often results in a set of task-slant “stories” that lack cohesion. It’s far better to stick it out with the larger, natural story. Let it play out over multiple sprints. Attack the story from one end, but start with the smallest skeleton of functionality that will enable the larger capability. Then, layer in more elements and behaviors in each subsequent sprint until you reach completion on the entire story. The story can remain intact and the user is likely to gain the full benefit of the original intent.

#6: Manual testing only

Testing is vital to the production of working software. If you haven't done any test automation, you are sorely missing out on significant gains in accuracy and efficiency. Minimalist test-specification techniques, such as behavior-driven development (BDD), are excellent accompaniments to agile stories.

Test automation is a highly efficient and reliable means for verifying that frequent code changes will work by design and won’t break existing code. With a robust platform such as Functionize, the team can readily apply test automation to other layers in the test pyramid. This includes unit tests, integration tests, cross-browser tests, interface-contract tests, and UATs.

#7: Lack of a strong test management strategy

QA management must also become agile, and lead the testers accordingly. Test automation can also bring about more effective defect management and central QA collaboration. When a team implements it well, automatic application testing can play a very important role in agile environments. Testers must also become agile. They must readily adapt to the agility of the other team members. Exploratory tests, regression tests, load tests, unit tests, and manual tests will remain essential to any successful deliverable. However, many of these tests are automatable. The others will need to be done in less time.

Functionize, the high-agility test automation platform

A very sensible way to adopt agile software testing methodologies is with the implementation of robust test management tools. To be effective, this solution must integrate well with story management software that the developers use. Testers can know everything that the developers know, and conversely. Equally important, the test management strategy must include some degree of automation. A strong agile test management solution such as Functionize enables test-case creation and execution. Functionize seamlessly integrates with your existing CI/CD process and significantly reduces time-to-market by minimizing the effort to manage your testing infrastructure.