Sorry! ALL Agile Frameworks Will Suck Without a Value-Driven Mindset

I’m tired of discussing which Agile framework is more promising. I’ve gotten myself in more than my fair share of endless debates about Scrum, Kanban, LeSS, ShapeUp, and SAFe (undercover waterfall agent). It took me a while to realize such discussions are pointless. The question isn’t which is the best Agile framework, but why do you want to use any framework at all?

Do you know why companies want to be Agile? What do leaders want to achieve with that? Whenever I ask this question, I am surprised by the number of false expectations with Agile frameworks. Here are some of them:

• Increase output predictability
• Be faster than the competitors
• Deliver more in less time
• Clear visibility on output

These answers show a mismatch of expectations; they are unrelated to a value-driven mindset. Unfortunately in such situations, no matter the chosen Agile framework, the results will be pretty the same:

Teams continuously deliver features without knowing which problem they solve and why that matters. They will be locked in the build trap.

If your goal is to ship features faster, don’t even bother with Agile frameworks.

If you aim to increase predictability, Agile will disappoint you.

If you want to hold teams accountable for output, don’t try being Agile.

If you’re ready to embrace the unknown and continually reinvent how you work, then Agile is for you. But you must be ready for a challenging journey.

After years of failing with Agile frameworks, I learned which ingredients must be present to pave the way for creating value sooner. Let me share them with you.

1. Empowerment

In my experience, empowerment is fundamental to succeed with any Agile framework. In traditional methods, decision-making remains at the companies’ highest level. Top managers define who does what by when. Teams receive predefined solutions; the only remaining aspect is implementation. They often lack the why behind each solution, but leadership perceives that as normal as they expect teams to get things done instead of solving problems.

When it comes to Agile teams, empowerment means leadership will trust teams to solve meaningful problems and let them decide which direction to take. Top management sets where to land and doesn’t bother with how to get there; they empower teams to uncover ways to create value for the business and end-users.

The following image clearly illustrates the difference between feature teams and empowered teams.

Without true empowerment, teams won’t go beyond ordinary results.

2. Accountability

As uncle Ben famously said, “With great power comes great responsibility.” This happens with empowered teams; they should be accountable for outcome instead of output, which is a horse of a different color. The burden of delivering results is heavier than simply shipping feature after feature.

Typically, feature teams struggle to move from output to outcome. Accountability is critical to making this shift happen; when leadership holds teams accountable for output, empowerment becomes pointless, and teams don’t change how they work. Take Scrum as an example—you’d observe the following mutations:

• Bloated product backlog with unrelated items
• Highly detailed backlog items
• Sprints loaded with features and unclear or irrelevant goals
• Focus on precise estimates over learning
• Product Owners sign off on tasks from developers

I observed great results with teams that became accountable for achieving goals. In this case, they have no chance but to adapt to the way they work. Teams are forced to reinvent themselves and figure out what matters to end-users and how to create value. They use their empowerment to decide how to solve problems, experiment, learn, inspect, and adapt.

When teams understand output is a means to an end, delivering value becomes natural.

“Failure is not fatal, but failure to change might be.” –John Wooden

3. Courage

Agile requires being comfortable with the uncomfortable. As human beings, we want to feel secure and know what we’re stepping into. We dislike the unknown and may even feel threatened by it. That’s why we resist change and avoid it as much as possible. But Agile frameworks require courage to embrace the unknown—otherwise, how could teams uncover hidden opportunities to create meaningful solutions?

Many people think that Agile is about speed, doing more in less time, maximizing output, or something similar. Although the name suggests speed, it’s not exactly about output, but learning. For me, Agile is about reducing the learning time by embracing the unknown. However, we usually face too many anti-patterns, which makes it easy to fall into traps.

Take estimations as an example. How many methods do we have? Story Points, T-Shirt Size, #Noestimates, Ideal Working Days, and so on. Why do we have that? Because we long for predictability, we want to know where we’re stepping into. I’m not against estimations, but they can mislead many teams and contribute to a massive waste of time. Good Agile teams will focus on understanding enough about the problem so that they are ready to get their hands dirty.

ShapeUp has a unique approach to embracing the unknown: the Hill Chart. They don’t estimate; instead, they see two parts for any activity—figuring out what to do and getting it done. During the first part, the team uncovers what each activity entails; they accept the fact that they don’t know all the answers upfront and strive to get them cleared out. After that, they are on the top of the hill and know what to do to get it done.

Without courage, no Agile team can succeed. You’ve got to be brave and do what’s unnatural to you but required to uncover opportunities to create value.

“Working without a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier.” –Jason Fried, Rework

4 . Empiricism

Until teams are ready to work empirically, they will fail. The question is, what is empiricism? It’s the ability to create knowledge from experience. It sounds simple and logical, but putting it into practice isn’t straightforward. It goes against our nature of searching for predictability and avoiding risks. Let me elaborate.

When companies start a project, common questions would be:

• What’s the scope of it?
• How long does it take?
• Which team do we need?
• What are the risks?

These questions force teams to come up with answers they don’t have. At the beginning of any project, you don’t know enough to answer such questions, yet traditional project management will force you to come up with something. Empiricism is different; it encourages you to create the right experiences and learn from them. A better set of questions would be:

• Why does that matter?
• What do we know?
• What don’t we know?
• How can we uncover our unknowns?

Empiricism forces teams to embrace the unknown, creating the required learnings to solve problems mindfully.

“Intelligence is the ability to adapt to change.” –Stephen Hawking

Final Thoughts

No company can move from a traditional approach to an Agile one in a short time. It requires adapting their mental model, which takes significant time and humility. Yet, companies willing to do so will stand out.

Don’t waste time debating which Agile framework to use without developing a value-driven mindset. If you insist on doing that, it’d be like putting the cart before the horses. The result is a disaster. However, once you understand the necessary behaviors and are willing to adapt to them, you can be surprised by the astonishing results  that await you.

“In any given moment we have two options: to step forward into growth or to step back into safety.” –Abraham Maslow