Why Agile Isn’t a Silver Bullet


One of our many biases as human beings is to, every now and then, confuse the means (the approach; what we need to get somewhere) with the ends (the destination; where we want to go). This seems to be happening more and more often with agile.

If you look at the slide decks by some of the world’s biggest consulting firms, you’d think that agility is the solution to all problems. A true silver bullet that can enable companies to become innovative, resilient, and adaptive, learning lessons quicker than before and gaining a competitive edge.

If you watch some of the more recent talks on agile or read some of the books that came out this year, you’d be left with more or less the same impression. But the question is…

Is agile really the silver bullet that so many folks are making it out to be?

Agile isn’t a silver bullet for the challenges and problems that the leaders, teams, and individuals working within an organization need to address and solve. It’s a mindset and approach that they can use to do so in a way that allows them to learn lessons fast and respond to change better.

In this post, I’m going to share with you why I think that way.

It’s time we stopped confusing agile with something that it clearly isn’t. And start using it as the mindset and approach that it is to focus on the work that matters most, solve the problems with the biggest impact, and learn from the feedback and insights that we get along the way.

With or Without Agile, You Need a Solid Strategy

Leaders and professionals at all levels should see agile as an approach and set of frameworks that helps them to welcome change at any stage in a product’s development or project’s progression. As an outcome, they become more resilient by taking decisions and can correct course more frequently compared to when using a waterfall approach.

The challenge is that you can work in the most agile way possible, but still be working on the wrong thing. Agile can help your organization and team become efficient (do the things right), but how effective (doing the right things) you are will ultimately depend on your strategy.

In his 2011 book “Good Strategy/Bad Strategy: The Difference and Why It Matters,” strategist and professor Richard P. Rumelt explains why strategy at most organizations doesn’t work—and what their leaders should do to fix that.

Good strategy, Rumelt writes, consists of three elements:

  1. An objective and clear diagnosis of the situation;
  2. A guiding policy for how to navigate the situation in an optimal way;
  3. A set of coherent actions for how to get from the current to the desired state.

Bad strategy, on the other hand, is characterized by fluff, failure to name and address the challenge, and mistaking goal-setting for strategy-making.

In an approach that closely resembles agile’s iterative and incremental way of working, Rumelt suggests that companies should create hypotheses and test them out in the real world and use them as learnings and insights to set their long-term strategy.

You Still Need to Make Good Decisions

If you take an agile approach to organizational leadership, product development, and program/project management, you’ll need to make more decisions than using a traditional and waterfall approach—and do so more frequently.

In other words, agile doesn’t eliminate the need for good decisions at all levels in an organization; it increases it. At the same time:

  • Most sponsors in agile organizations make poor capital allocation decisions;
  • Most agile leaders are detached and disengaged from their agile teams, instead of protecting them from distractions and removing organizational roadblocks for them;
  • Most Product Owners in Scrum and Customers in Extreme Programming (XP) make bad prioritization calls and keep changing their minds mid-goal;
  • Most Developers don’t have discipline and forget that it’s up to them to achieve and sustain the technical excellence whose lack they’re complaining about.

Any company can start an agile journey and go through an agile transformation. Just like any team or individual can read the Agile Manifesto and adopt Scrum or Extreme Programming (XP). 

But it’s in how the people in that company or team use agile and the tools that it gives them that will ultimately make or break their success. And that’s the compounded sum of the decisions that they choose to make (and those they choose to avoid making) over the course of time.

It Won’t Stop You From Reverting Your Old Ways

I was recently reading Bain & Co’s latest book on agile leadership, “Doing Agile Right: Transformation Without Chaos.”

One of the things I really enjoyed about this book was how honest and upfront authors Darrell K. Rigby, Sarah Elk, and Steve Berez are about what causes most agile transformations to fail.

In most organizations, Rigby, Elk, and Berez write, the leadership teams plan agile transformations for their staff and structures—but not necessarily for themselves. They set up a Project Management Office (PMO) to drive the transformation with project plans, Gantt charts, and stoplight reporting systems.

Unfortunately, this approach and the metrics to monitor it are aimed less at helping the organization adopt agility and more at convincing investors, boards of directors, leadership teams, middle managers, and staff that the transformation is progressing “exactly as planned.”

Agile is a mindset. If your organization—and its leaders, teams, and staff—keep reverting to top-down and command-control ways of working, its adoption of agility won’t yield the same outcomes as it otherwise would. The biggest detractor for any organization’s agile journey is the people working for it who are thinking and acting in waterfall ways.

Leaders Need to Participate More Than They Initially Think

Here’s a scenario that many readers of this blog will find familiar.

You’re a member of a newly-formed Scrum Team. You could just as well be the Product Owner, Scrum Master, or Developer; that’s completely irrelevant for the purpose of this example.

In the first few sprints, there’s great interest in your team’s progress and your product’s development from the key stakeholders in the organization. This translates into a big number of stakeholders attending and participating, through questions and feedback, in your Sprint Reviews.

As time progresses, stakeholder participation in your Scrum Team’s Sprint Review events slowly starts to degrade. Until it reaches a point in which the Sprint Review events are attended only by the Product Owner, Scrum Master, and Developers in the team. Plus/minus the occasional colleague from another Scrum Team or semi-interested stakeholder.

At the same time, the Product Owner starts to receive ad-hoc and out-of-context requests for effort estimates and target/delivery dates on existing, future, and potential features from the team’s sponsors, leaders, clients, and/or users. Clearly, something broke along the way. Heated emails and political pressure replaced the honest conversations from the first few Sprint Reviews.

Stakeholder engagement is a topic that our agile community all too often neglects. Yet it’s just as mission-critical for the success of a Scrum Team to deliver value for its customer as it is to keep its stakeholders engaged and participating.

The problem is that, in many organizations, sponsors, leaders, and stakeholders were never taught how to be good stakeholders of an agile team—and their role and responsibilities are when it comes to giving their feedback, removing organizational hurdles for the team, and protecting them from distractions with the ultimate goal to achieve a sustainable pace of delivery.

Process Discipline and Technical Excellence Remain a Must

“Now that we’re agile, we can do anything we want and forget about following processes and creating documentation, right?” Sounds naïve, exaggerated, and counterproductive, but that’s the reality of how many professionals perceive agile.

Agile is an approach to building products and managing projects by working in short cycles and shipping in small chunks. Yes, the Agile Manifesto says that agilists value individuals and interactions over processes and tools; and working software over comprehensive documentation.

But there’s nothing in the manifesto that negates the need for process discipline and technical excellence. On the contrary:

  • The second principle of the Agile Manifesto says, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
  • And the ninth principle clearly states, “Continuous attention to technical excellence and good design enhances agility.”

An agile organization—and its leaders, teams, as well as their individual members—have the collective accountability to keep what works and change what doesn’t. They remain vigilant to not use processes as a substitute for interactions and not create comprehensive documentation as a substitute for delivering working software.

But interactions are chaotic without processes and working software is incomprehensive without documentation. The only way to make agile repeatable (not a one-hit wonder) and reproducible (everyone in the organization, and not one team, can adopt and apply the same ways of working) is through process discipline and technical excellence.

The balance, then, is in coming to your own definition of “just enough.”

The Bottom Line

No, agile isn’t a magic pill that helps you to solve all problems and challenges. It’s simply a mindset and an approach that allows you to approach them in a more iterative, meaning in short cycles, and incremental, meaning one at a time and sliced into small chunks, way.

With or without agile, an organization needs good strategy, decisive leaders, people skilled at making trade-offs—along with the participation, discipline, and excellence it takes to survive and thrive in today’s highly competitive marketplace.

Agile is the means to an end. Know where you want to go, thinking and acting in an agile way, and you, your team, and your organization will ultimately get there.

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.