Over the past year, we’ve written multiple articles about the various models around today for companies looking to implement an agile way of working – or more specifically in some cases, frameworks that explain how to move from a single-team agile process to a scaled approach with multiple teams in the organization working together in a scaled agile manner.
Each framework has its strengths: many try to define and shape concepts that increase the flexibility in planning, with new concepts that allow us to differentiate between short-term and long-term horizons and how both intersect. They give us something to hold on to when we try to discuss the complex subject of human collaboration. And in many ways, this leads frameworks to be a flavour or a nuance of others, with the very same concepts existing in parallel at the core of most agile frameworks.
Where frameworks do differ, is in the emphasis they place on being relatively free and open to implement, or on the opposite, how prescriptive they are. Some frameworks leave more room to interpretation, favor a bottom-up approach and allow for experimentation. Others define how you should implement their concepts, what rules to follow, what roles act in which processes and, quite possibly, how to tailor this prescription exactly to your needs.
A question we’ve often been asked lately is: what framework is right for me? It goes along with many variants of the question, such as: Which one should I pick? Is SAFe a better alternative to LeSS? Should I use the Spotify model? The answer to all these questions might very well be not to pick a framework at all.
Confronting the wild spread of agile frameworks, several thought leaders in the agile community have been driven to agnosticism, and with good reason: while the many frameworks do a lot of things really well, they can also take a lot of the attention away to what it is a business is doing in the first place: creating value for end clients. If you do desire to benefit from agile’s many perks, such as increasing responsiveness and accelerating time-to-market, take a famous Simon Sinek quote at hand and start with “Why?”. Why are you looking to implement these changes – what benefits do they bring to you and your business specifically? Why now, and why was this not done before?
Tackling these questions, you might find that while a cookie-cutter agile framework might sound like the silver-bullet solution, not all your business problems, it might not be what you, your company and your clients need. Try thinking for your own, instead of using a pre-built solution. It will be harder and lacks the appeal of a framework, but it might very well lead you to the results you seek.
The trick is to always keep your value chain at heart and take the foundations of your business into account before deciding to jump on the agile bandwagon. One of the key fundamentals of agile development is the agile manifesto, describing some key guidelines on which the methodology is based. Together, the values describe the perspective with which agile is to be considered. Like the original manifesto, don’t focus on implementing a framework by the letter, but start with the underlying ideas that are driving this change. It will make explaining your decisions to co-workers and employees a lot easier.
A humorous take on a failed framework implementation can be found below: