In many business cases - and in life too - 'custom' is what you want, because it takes your situation into account, without generalizing. But in making changes, that might be exactly the problem. Discover more on why a custom Agile framework isn't what you need, and our advice, in this blog!
In the blog on Big Bang Agile Transformations, I mentioned that companies hire management consultancy firms to help them transition to an Agile way of working. These companies sometimes propose to build a custom Agile framework based on the client's needs.
This process takes a while. First, one or multiple consultants are assigned to analyze and document the current processes. Next, they start drawing a new framework based on these processes, but in a more Agile way.
The problem with custom Agile frameworks
The danger I see in this way of working is that you create a new framework based on old habits. You undermine the success of your transformation from the start by building upon your current processes. You're not challenged to think out of the box when confronted with the problems that occur with a fresh start.
Our advice
I advise you to look at some existing frameworks first. The most known one is SAFe, but there are others:
- LeSS (Large Scale Scrum)
- Nexus
- S@S (Scrum at Scale)
- DA (Disciplined Agile)
- ...
They might not seem like a match because they feel too general and not specific enough to your organizational context. But that is the point: they challenge you to rethink the solutions to your problems when you start with them.
After a while, you will notice that you tweaked those frameworks to solve some specific problems. And that's okay, because you did so to solve problems that were not present in the framework. Not because they were prescribed from day one.
Finally, you can often take advantage of the community behind the framework. You can ask questions to people that have gone through the same journey. They also provide more freedom because you are not stuck to that sole company that once wrote your custom framework.
Our (custom) conclusion
Resist the urge to have a custom framework developed by a third party. The result is not a framework but a methodology that describes how different domains should work together from A to Z.
It's a consolidated version of how you previously worked, dressed up with Agile buzzwords.
You will not be surprised that such methodologies don't profoundly change the way you work and thus do not deliver the transformation you hoped for.
Learn how to work with existing frameworks or any other question? Let's talk!