Agility Is Endangered! Help Save It!
When an agile framework becomes a process, you cannot expect more than mediocre results.
When an agile framework becomes a process, you cannot expect more than mediocre results.
Over the last years, a common question annoyed me, “Which is the best agile framework?” While it’s great that companies want to do agile, they forget to be agile. No agile framework is a silver bullet. Companies won’t get any good results until they are willing to reinvent how they work.
All agile frameworks will suck if companies are unwilling to change their mindset.
Why do companies often fail with agile? That’s simple to answer; when agile becomes a process, it’s just a replacement for the old implemented process.
It’s impossible to excel with any agile framework without going through a disruptive transformation. Here are some dramatic changes that must happen but unfortunately, they seldom happen:
Leadership sets the direction, while the product teams are trusted to define how to reach the goals.
Failure is celebrated, and it generates learning.
Learning and adapting is the way to go instead of falling into analysis paralysis.
No one receives the blame for giving an accurate estimation.
The focus is on generating impact instead of matching an arbitrary deadline.
I am afraid true agility is endangered because many companies are using agile frameworks as processes. To defeat this anti-pattern, we need more mavericks than rule followers. Help us save agility! Let’s fight the misconceptions!
Allow me to share the top three pitfalls that ensure agility falls short, and mediocre results are the only possible outcome. Then, hopefully, you can join me and help companies overcome these traps.
1. Roadmaps, the Most Deadly Agile Enemy
Which of the following items is more common to find in a roadmap?
Implement a referral program by the end of the next quarter.
Reduce customer acquisition cost by 20% by the end of next quarter.
Let me guess, most probably you choose the first item. Most companies I worked for would prefer that as well. The reason is simple; roadmaps often define features to implement with an arbitrary deadline. While that pleases top management, it impedes any agile team from being agile.
If you take Scrum as an example, when you look at the Scrum Guide, you get the following as its purpose:
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Teams are blocked from reaching Scrum's purpose when roadmaps define solutions to develop. As a result, they are unable to generate value through adaptive solutions. Unfortunately, companies tend to implement agile as an execution framework. Yet, Scrum Teams are powerless to inspect results and adapt solutions to what could deliver value.
If you want to benefit from real benefits Scrum can yield, you cannot bow to such anti-patterns. Instead, you’ve got to be bold and question whatever holds the team back from generating value. Challenging the top management on how they craft roadmaps may be scary, but working on something pointless should be even more frightening.
2. Mechanical Agility
Unfortunately, many places use agile frameworks as a process for delivering features. That’s a shallow and limited use of any agile framework. Yet, frameworks like Scrum will get the blame once the company fails to get to the promised land.
Let me share some signs of mechanical use of Scrum with you:
No Sprint Goal: the Product Owner is powerless to set goals because the only thing that matters is pleasing stakeholders. Commitment is done on feature level, and therefore, an overarching goal is absent
Silos: every team member is responsible for one specific part, e.g., back-end, front-end, UX, UI, and so on. Team members focus solely on getting their part done. Everyone is locked in their comfort zone, and no one is willing to abandon their post.
Lack of ownership: the team doesn’t feel accountable for something they haven’t defined. The Scrum Team becomes a machine, where the output is more features. Still, nobody cares about whether that makes sense or not.
No contact with real users: developers are locked into their bubble, they may talk to stakeholders, but contact with real users is out of their reach.
No emotion: everything is mechanical. Every team member may attend all events, but their participation is shallow, and nobody goes into conflict.
When you observe any of these characteristics, that’s a dysfunctional version of Scrum. Therefore, you cannot expect to deliver value fast until the dysfunctions are solved.
To know more about it, I’d recommend reading The Rise Of Zombie Scrum by Christiaan Verwijs. He points out really well, cause, consequences, and how to overcome the zombie Scrum.
In my opinion, we cannot blame a framework for our incapacity of delivering value. Scrum and any other frameworks are just a means to an end, where the end is to deliver value. Without an agile mindset and attitudes, all frameworks will lead to the same frustrations.
3. Absence of Empiricism
When I was in the university, many of my Professors used to say, “People with strong analytical skills will transcend in their career because the world longs for problem solvers.” Although I agree with that, I believe many people misunderstand the meaning of being a problem solver.
I observe quite often that everyone is talking about solutions that can change the world for the better. Yet, only a few people strive to understand the real problem and whether it’s worth solving it or not. I think the focus should be on asking more questions instead of providing more answers. John Cutler shared a thought recently that reflects this problem:
It would be odd for someone to say “bring me answers not questions.” We seem to value “good questions.” Yet somehow “bring me solutions not problems” is common. Why?
The obsession for solutions impedes us from being empirical. From the Scrum Guide, being empirical means: “Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.” Is this lived in the business world? From my experience, not as often as it should.
It’s rare when teams focus on defining the questions they don’t know and then search for alternatives to get the needed answers. Instead, a common practice is to start with solutions and find answers to why the solution makes sense.
Accepting our ignorance is the only way of being empirical. Until we accept we don’t have all answers upfront, we will fail to learn what is needed, and ultimately, we will endure bitter failures.
Final Thoughts
It breaks my heart when I observe agility being misused. I am passionate about being agile, and I perceive that as a liberation. I know what it is not to be agile because I worked with waterfall, and I know how it feels to be locked into a process in the past. Agile came as a solution to help teams unleash their true potential.
Now, companies are falling back to their old behavior. Executives want predictability and are unwilling to empower people. Still, bowing to the status quo won’t let anyone thrive; it’s our responsibility to combat the anti-patterns.
Agility is fascinating, but it won’t survive long enough if people are afraid of confronting the misconceptions. Don’t be scared of challenging anti-patterns; you should be scared of being locked into a trap that ensures mediocrity.
