We Failed Agile! Shame on Us!

A story about hope.

What happened to Agile? Or in other words, what did we do to Agile?

For decades, developers were trapped. Following requirements that resulted in features that customers didn’t use demotivated everyone, and a revolution was necessary.

At the beginning of the 2000s, we finally realized that we could not predict everything upfront. A plan would fool everyone and yield pointless results. It was time to break silos and boost collaboration, move from features to results, from plans to goals, from fragmented responsibilities to autonomous teams.

The Agile Manifesto was born, and a massive transformation started. We gained hope. What appeared impossible suddenly seemed possible. It was time to foster collaboration and create things that matter most.

We had hope for a brighter future. But something derailed us, and we screwed Agile up—shame on us.

Look around. It’s been more than two decades since the birth of the Agile Manifesto. What do you see? Think about it. 

Let me share what I see:

• Output over Outcome
• Opinions over Evidence
• Plans over Goals
• Control over Empowerment

I’m sorry, but I think we fell back to our outdated standard behaviors. We dislike the unknown, so we find security in plans. We fear failure, so we try to control each other instead of empowering them. Solutions easily elude our minds, and we ignore learning.

I understand Agile was about accelerating learning to enable us to create value sooner. It was about simplicity instead of complexity. But where are we now? What did we do to Agile?

Since the birth of the Agile Manifesto, many methods and frameworks have emerged. And we magically mutated all of them into another version of our old good friend, Waterfall. 

This article is about hope, not complaints. I don’t want to bash mistakes, but to illustrate what I’ve done and seen others do that diminishes agility. 

By the end of this story, I want to give you hope on where to step back and change your scenario into a more Agile one.

Descending User Story to Precise Requirements

Do you know why User Stories were born? They came to exist because software engineers couldn’t accept implementing features without understanding the user’s perspective. They wanted to ensure a conversation around the problem would happen and then be ready to create a solution that mattered to the user.

What happened to User Stories? It became the most used requirement format within Agile teams. Yet, it got distorted to its initial intent of fostering collaboration. What I see is quite ugly:

• Product Owners/Managers trying to write precise stories to ensure developers ask no questions about it
• Developers complain when stories are imprecise
• Nobody talks to real users, but no one gets tired of writing “User Stories”
• Extensive focus on writing and little space for collaboration

User Stories aimed to increase collaboration and build a shared understanding of a problem, but we transformed it into another way of representing requirements.

Transforming Story Points Into Predictability

In the past, teams used absolute time to estimate activities. You would generally see in multiples of four hours. A task would last from half a day to god knows how much. That proved to be senseless as software development is complex and unpredictable.

Story Points were created as an alternative to our initial approach. The idea of this method was to estimate complexity instead of time. I’ve been part of many teams where we just converted Story Points into absolute time because we couldn’t understand how to deal with complexity. Obviously, we got it all wrong.

Embracing the unknown is the core of Agile. We’ve got to get comfortable with the uncomfortable. Story Points are a beautiful method of understanding different perspectives and increasing the teams’ knowledge. Also, the more complex something is, the less we know. It’s a sign the team could benefit from a spike to research before getting hands-on.

It’s not about predictability; it’s about understanding.

Mutating Agile Frameworks into Waterfall Ones

Which is the best Agile framework? Let me tell you: It doesn’t really matter the framework you use. What matters most is the mindset you use to operate it.

What I commonly notice is companies using Agile frameworks with a fixed mindset. The result is obvious—it’s just another version of Waterfall, yet, the framework will get the blame. The following are some complaints I often hear:

• Scrum sucks! Sprints get in the way of creating useful software.
• Kanban is better than Scrum because we don’t waste time with pointless events.
• We cannot set Sprint Goals because we have too many important items to deliver next Sprint.
• Our Product Owners cannot make decisions alone. I don’t know why we need them.

Is the problem the framework or how companies use it? All of the examples above relate to poor implementation. 

It’s embarrassing to accept the truth. For example, I know that I often complained about Scrum, and I was the problem, not the framework. It’s easy to blame the framework. We become victims and feel fooled. And it’s hard to accept we’re the ones failing. 

Without a value-driven mindset, all Agile frameworks will lead you to the same place: Nowhere.

Watering Down Roles and Responsibilities

Before Agile, we had highly specialized roles—requirement engineer, delivery manager, software analyst, etc. Within the Agile Transformation, new roles were born: Agile Coach, Scrum Master, and Product Owner. The goal was to simplify and introduce end-to-end responsibility. This made sense, but our stubbornness didn’t allow us to embrace it.

The Scrum Master role was created to help organizations embrace Scrum and live up to the values behind the framework. What happened is that business leaders barely let Scrum Masters go beyond the Scrum team, limiting the role to work exclusively with the team. That’s not what companies needed, but it is what they wanted.

What about Product Owners? This title has become a joke in the market. Respected leaders such as Marty Cagan and Melissa Perri took a stand, asking people not to call themselves Product Owners. Is the role that bad? It was supposed to be the value maximizer helping teams create value faster, but it became the stakeholders’ puppets doing whatever they wanted. 

Why did that happen? I believe this happened because companies aren’t ready to truly empower professionals as Agile frameworks require.

Outdated Leadership Style

We decided to be Agile, but has anyone told top management about it? Unfortunately, I continue to observe many leaders defining who does what by when instead of setting goals and empowering people to achieve them.

Step back and look at how roadmaps are crafted and what they define. Most roadmaps are prescriptive plans (Waterfallish) and lack goals. As a result, teams are powerless to make decisions on how to solve problems. They can only decide how to implement solutions, even though that may not solve any problem.

Until top management can renounce command AND control, Agile has no chance of going beyond the status quo.

I understand leaders are under unbearable pressure from investors, the board, and everyone around them. The burden they carry is too heavy. That’s precisely the reason I believe they should share the responsibility with teams by trusting them with meaningful goals. 

Command and control style should be something left in the past. This style worked during the industrial revolution, but it won’t work in our digital era.

What’s the Future of Agility?

What I see right now is quite disappointing. We’ve mastered the art of transforming valuable techniques into pointless ones. Transforming Agile frameworks into Waterfall ones, that’s on us.

One thing that makes me sad and skeptical is a trend I noticed: More companies are moving towards SAFe, another Waterfall with the audacity to call itself Agile. Yet, it’s something related to our comfort zone. Clear process, precise roles and a lot of room for command and control.

I also observe many teams moving from Scrum to Scrumban or Kanban with the hope of untrapping themselves. I admire people who are trying to change. This is what we do need. But migrating the framework while keeping the same outdated mindset won’t get teams further.

In my opinion, we failed Agile because we’re not ready to embrace the unknown. We’re not brave enough to admit our limits and find comfort in blaming frameworks instead.

My hope lies with new leaders with the guts to challenge the status quo and foster a mindset change, one that enables creating value sooner. Only then will Agile have another chance.

Final Thoughts

Agile didn’t deliver on its promises. That’s what I hear many people saying. But I believe we failed Agile because we still lack the courage to renounce our outdated working style. 

We want a silver bullet. We want a framework that solves all of our problems. Something that ensures value is created in a steady space. We want shortcuts. That’s all we strive for. And that’s why we are where we are.

There’s no shortcut to being Agile.

If we want to have a chance of creating value faster than we’re used to, we better adapt our mindset. We’ve got to:

• Move from plans to embrace the unknown
• Move from command and control to empowerment
• Move from opinions to evidence
• Move from increasing predictability to accelerating learns 

We've got a choice to make. We can remain trapped with our status quo, or embrace a transformational journey and have better chances of standing out.