If you’ve been working for a bigger organization that ran an agile transformation in the past years, be it in Fintech, Telecom or other, you are probably hearing about agile hybrid or hybrid agile these days.
Everybody seems tired of SAFe PI planning and heavy preparations every quarter and at the same time those other dreams of the simple scrum team did not materialize.
Basically, organizations have not collected the benefits they expected with their agile transformations, and as you can imagine, they try and find new questions and turn to something new, like what they now call agile hybrid.
Now, does it mean agile is dead? It’s the return of waterfall? Is hybrid agile the same as Scrumban?
In this post I’ll give you an insight on what is this agile hybrid, why It’s in everybody’s mind, and how it can affect your work if you are used to agile roles such as those found in Scrum. And I’ll tell you why agile hybrid is a good thing.
if you’d rather watch a video, off you go!
What is agile hybrid?
The way I like to define agile hybrid is with a scale tipping between waterfall and agile. So you can be on a spectrum.
So for example, you might be still collecting all your requirements and doing heavy architecture docs in a more “waterfall” way, with all those approvals and only after feeding that work to be developed to an agile team. So the development team works in agile, running sprints, having a highly volatile backlog based on what’s been considered mature enough for development.
Then it’s possible the deployment to production phase is still back to waterfall with many gates and approvals. Or, it’s possible that they use DevOps, tipping even more favorably on the agile side of the scale.
So it’s agile! In some parts… but while they use User Stories and story points and sprints and kanban boards, they still use their Gantt charts and do budget projections and rely heavily on certain timelines. While teams get to self-organize, the top part, program and portfolio, is still somewhat rigid and less agile than you’d expect.
This is actually not new, what is new is the nomenclature. But adopting, let’s say, a “percentage of agility” has been an approach organizations have been doing for more than a decade now.
How about framework-neutral agile?
So this is the moment where I invite you to consider a new name, as sometimes agile hybrid makes it all sound weird and half good.
Now what I prefer is entering the world of framework-neutral agile. Basically, it’s agile regardless of frameworks and it’s about integrating practices based on their utility and your capacity for change. You seek adaptability for your business practices or for your teams ways of working, one element at a time.
For example, you could decide that as a team you want to use a kanban board to be more transparent on the nature of the work. and decide to create a real kanban board with the stages of your team process for development. You change nothing else, just that. Kanban was the set of practices and principles you will adopt for now in certain parts of your work. Everything else remains the same. For a while.
Pssst! If Kanban is something you want to try slowly and safely, have a few blog posts and a free resource for you to download. Start here if that’s what you are interested in.
Back to your team where you just adopt the simplest parts of kanban. If you do that, I guaranteed that now, because you use that board you will all start asking yourselves a few different questions. And that’s when new behaviors will start to emerge.
The point is, you don’t have to choose between scrum or kanban or Scrumban. You don’t have to follow SAFe to the letter. You are entering the world of framework-neutral agile. You have a problem to solve and you look for proven effective practices and adopt those. Then your internal processes and ways of thinking will have to shift to accommodate that.
A few more colorful examples could be:
QUALITY
A team that notices that they spend too much time doing necessary quality tests and decide to go for test automation and maybe even some pipeline and deployment automation and other DevOps practice, so that their quality can shift left, maybe even using TDD, which brings testing to the beginning stages of their development. They are not DevOps, or Scrum, or whatever you want to call them. But they use practices from this realm.
METRICS
Another example could be a team who has a feeling a lot could be improved but have no idea where to start. Suppose they start collecting metrics about their development process. They could check efficiency of process and cycle time measures for starters. They could start having satisfaction surveys to collect information on the team positivity every month. They are measuring to know, and since now they know how they perform, they’ll be able to choose where improve. Probably where the metrics show the least satisfactory number.
PRIORITIZATION
Maybe another department decide to have a single backlog that is shared across teams, centralizing the prioritization and requests and allowing for a bigger visibility and systemic ability to intervene. Great agile practices can be used here. Some people get inspiration from Nexus or Less. Regardless, your team is neither and yet it’s advancing in their ability to prioritize and remain transparent.
The lesson here is: In framework-neutral agile, what you do is assess your current ways of working and see what improvement feels could benefit you most. Then you go after practices that could help you with that. Then you iterate experimenting with them. LEARNING from the process, not blindly adopting frameworks just because everybody else seems to be doing it.
Is agile hybrid a good thing?
You’re probably now thinking: is this hybrid agile a good idea?
Won’t people “degenerate” agile practices to their lowest common denominator?
Sure, people can interpret hybrid agile, or framework-neutral agile as a means to stay in waterfall or in any other mechanics where they are comfortable and have been using for ages.
But I say framework-neutral agile is a great thing. Agile on a spectrum (or on that scale I showed you earlier) is totally fine. It’s what agile actually has been in its origin.
Why do I think it’s a good idea?
Because people get to experience the agility that they are ready to embrace. You can’t simply force things on people at a volume and speed they are not yet ready to receive. So what if they want to stay mostly on whatever they call waterfall? Even waterfall isn’t as clear cut as most people like to think.
There are practices that people do that are agile, like breaking the scope down into proper user stories. And then there are practices that resemble more waterfall, like a Gantt chart, which is actually showing inter-dependencies and timeline relationships.
The point being:
Change takes time to be desired and absorbed, and you should respect that, otherwise your change WILL FAIL.
You should neither change what works nor change MORE than what your culture and processes can tolerate. You have to go at a pace and iteratively to collect the benefits and achieve true long-term adhesion to new practices. It’s the slow and steady, the water liming the stone. And if you want to know more about the why on pacing change based on the appetite and tolerance for it, I have two previous posts on the topic of change, that you might like to take a look into: one about why agile change can fail, and one about ADKAR change model.
If you are still not convinced that framework-neutral agile is a good thing, here’s an analogy that has nothing to do with work:
Consider food and health. When people say that you are either agile or you are not, it’s like saying unless you have 100% clean diet, eating a bit more vegetables and drinking less alcohol every day has no impact on your overall long-term health. Which we know is false. And in fact, we know going all on certain diet changes in is not an option for everybody on everything.
So it’s the same for agile.
How will that affect you as a scrum master?
After all this, you are probably wondering How that will affect you as a scrum master?
Maybe a follow up question is, without a standard framework, do you still have a place for those roles like PO or scrum master, if people adopt only the practices that make sense for their level of agility and not a full framework?
And my answer is, yes, you do. Managing work effectiveness is still important. Prioritizing and deciding on value is still more than ever necessary. So, maybe nomenclature will change a bit, but most importantly your set of skills will broaden.
The two key benefits I see for you in your career are:
➡️ With a framework-neutral approach to agility, you will know several different practices for prioritization, team enablement, stakeholder collaboration. Sometimes these will not be specific agility practices like change management models, or design thinking. And you will understand why these practices exist, what problem they attempt to solve, when are they best suited, and how to adapt them to the reality of your organization.
➡️ You’ll be a more skilled communicator and negotiator, and grow so many of your soft skill and EQ, as there is so much to understand, personalize, and influence. If anything, the work is more exciting and less of a rinse and repeat, which, let’s face it, never worked much for people other than trainers anyway.
In conclusion
Agile hybrid as a word, is just another buzzword that you don’t need to stress about. As a concept, what’s behind it is positive, especially if you reframe it as framework-neutral agile.
Agile Hybrid allows you a lot of latitude as a coach to help people and organizations where they need it most. It definitely opens the door for teams and whole departments to co-design the next steps with you, using their intelligence and your specific knowledge. It’s a win-win, you move forward with affinity, and the chances of continuous improvement are bigger,
And I hope you use this to your advantage, especially because that means you don’t need specific titles to raise your hand and lead change in your teams and departments.
If you are interested in growing your change, leadership and agile skills, other than the blog and videos, consider joining the newsletter Agile Circle. It’s totally free, and you’ll receive insights in your inbox, be invited to events and workshops in our community of practice, The LAB of All Things Agile, and get first word in discounts for our paid programs and coaching.
