How to Understand Your Agile Maturity
A simple way of evaluating your level of agility
A simple way of evaluating your level of agility
Around five decades ago, Gordon Moore observed that transistors inside a microchip doubled every year and a half. This observation remained true for a long time, and consequently, Moore's law was created. Yet, looking at our frenetic digitalization pace, technology is advancing faster than ever, bringing more challenges to benefit from it.
One of the biggest challenges I observe is using technology to make our lives better instead of creating something just for the sake of it.
Despite the incredible tech growth, many teams still work the same way people worked 50 years ago; this bugs me.
I am not dogmatic. I don't think companies must implement an Agile framework by the book. I don't even care which framework companies use. However, if they want to be Agile, some key aspects must be present; otherwise, teams will be like rats on a treadmill, and delivering REAL value becomes a missed opportunity.
I've been part of a couple of Agile transformations, and honestly, it was dramatically painful to move from an output orientation to an outcome focus. I often asked wrong questions; instead of striving for clarity on the next step, I want to benefit from sound Agile practices. A clear understanding of the status quo helped me advance on agility.
You don’t get to the top of the mountain in a couple of steps; it takes time to get there. Most times, all we need to know is where we are and take next step.
How to Evaluate Your Agile Maturity
During my journey, I observed many teams struggling with Agile. No matter what they tried to do, it was never enough. I could feel the frustration in all layers. Developers were unhappy with the tech debt piling up, stakeholders were pissed off as their wishes didn't make it to the roadmap, and Product Owners were disappointed by descending to backlog managers.
The scenario I mentioned may sound familiar to you, but you don't have to worry about it; you have a way out of it. As with any house renovation, it first has to worsen before getting better. First, you need to ensure you understand your house structure, and then, you can define what to break and then transform it.
I see two crucial aspects for any Agile transformation: empowerment and learning speed. They may sound simple, but don't underestimate the complexity of living them properly. The following matrix reflects the four types of teams I've found while implementing any Agile framework.
Now, let me share the characteristics you will find with each team. That will help you understand your scenario and take action to advance with Agile.
Feature Factory Teams
Like almost everything in life, when we embrace a new endeavor, it's easier to use as much as possible of what we already know. All Agile implementations I know started the same way: a waterfall in shorter cycles. And I am not blaming this scenario but facing it as part of the journey to becoming Agile.
The trouble happens when we cannot leave old habits in the past and create new ones.
Unfortunately, almost all Agile implementations I've observed didn't go beyond the terrifying feature factory trap. I've been there, done that, got several t-shirts, and honestly, it's one of the most depressing ways of working. Here are the most common traits of feature factories:
Roadmaps are entirely prescriptive. Solutions are well defined a deadline is set in stone. Funny enough, the responsible team is out of such discussions.
The Product Backlog is like a Christmas Wish list of 6-year-old kids, it has everything they want and nothing they need, yet you cannot remove any wishes; otherwise, they will cry rivers.
Product Owners cannot make decisions beyond how to make the solution available on time. Taking requirements, writing e-mails, and handling crises consume most of the day.
What's the outcome? Nobody cares about it because the only used metric is story points per Sprint.
Without empowerment and outcome orientation, Agile teams will be like warriors fighting with tied hands
Dreamless Teams
Like people from my hometown in Brazil say, "Sometimes you have the cheese and the knife in your hands; you just need to cut it." This is what I witness with some Agile teams. After living for months or years in a feature factory trap, something changes (e.g., an agile-minded CEO assumed the position), and they become empowered. Still, unfortunately, they don't know how to benefit from it.
A team without a purpose becomes a dreamless team. Despite being empowered to make decisions, they still have an output orientation and don't pay attention to the outcome generated by their work. You can observe the following with dreamless teams:
The responsible teams collaborate with top management to establish roadmaps. Unfortunately, they still focus on features instead of results.
Stakeholders trust the team and empower them to make decisions; they don't micro-manage anyone. Although they may be pushy, they listen to reason and commit to agreements.
Measuring the outcome is still underrated because the team still has an output orientation. Teams celebrate when a new feature goes live instead of when they've collected evidence the feature got the job done.
Unlike the feature factory trap, a dreamless team can easily transcend with agility. All they need is to move from output to outcome. Solving problems instead of implementing tasks should be the change.
“If you have a strong purpose in life, you don’t have to be pushed. Your passion will drive you there.”
― Roy T. Bennett, The Light in the Heart
Frustrated Teams
Picture the following, after a stressful Sprint; you released the new module for your car-sharing app. For the next two weeks, every day, you monitored your dashboards, talked to users, and exchanged with your team members. Then you learned users got excited about the new feature but couldn't benefit from it because it was unclear for them, so they stopped using it.
You see potential with the new feature, but users won't engage until you solve some hurdles. Still, you are enthusiastic about it and decide to talk to your boss. Once you approach her, the conversation goes like that:
You: "I've got good news for you. We are on the right track, our new feature resonates with our users, and they are excited about it. But to profit from its potential, we need some changes."
Boss: "Hum. So actually, you are bringing me bad news. We've already invested all the time we had for this feature. Now we must move on and implement the next roadmap item."
You: "That's what I wanted to talk to you. I understand the roadmap agreement, but we've got clear potential for this feature, and if we don't address the users' feedback, they won't use it. I would rather talk to management than ignore our users."
Boss: "Well. You know how things work. Our management board only talks about the roadmap once a quarter, and they don't accept skipping anything. Once in, it must get done. Maybe you can try bringing that to future interaction."
You: "It's frustrating. I have evidence, and users are active now, but they will forget about it if we wait for another quarter. Once again, we are missing the mark."
Does this scenario ring a bell for you? This is common when Agile implementations happen bottom-up while top management still perceives Agile frameworks as processes for more output. Although the team focuses on learning from honest feedback, they are powerless because they cannot do what makes sense but have followed directions from those with no contact with end-users.
Game-changers Teams
Transformation.
Disruption.
Innovation.
These are standard results of empowered and outcome-oriented teams. They create the new, embrace the unknown, change the game, disrupt entire industries. They don't do Agile; they are Agile.
Trust me; I am not exaggerating. Agile boils down to empowerment and measuring the results. Once Agile is the culture instead of a process, teams have the chance to inspect and adapt genuinely. Ultimately, they will find appropriate ways of solving end-users real problems.
The real challenge is embracing the unknown because it hurts to accept our ignorance.
Final Thoughts
Succeeding with Agile requires patience. The problem is that companies feel pressured by investors, shareholders, competitors, etc. And once they bow to the pressure, they want to find better ways of getting results faster; that's when things get ugly.
With Agile, the more you hurry, the more you mess up.
It's easy to blame Scrum, Kanban, or whatever framework companies use. But it's hard to stop and evaluate the Agile maturity and define what to do next to move further. Without reflection, progress is impossible.
Did you like this post? What about becoming a Medium member to benefit from unlimed reading? By doing that, you support writers like me and thousands of others 😊