Part 3: Reflections about frameworks for agile and business agility
This is part 3 in a series of articles regarding why and how organizations should strive for Business Agility. In part 1 you can read about the rationale, in part 2 we go deeper in how to make it happen.
There are many opinions regarding agile frameworks. Someone think they are not agile at all, others believe it’s impossible to make it without them. Both may be wrong — and both may be right — at the same time. In this article I will discuss the use of frameworks in general, and why I think the true answer is “it depends”.
First of all — it’s important to understand what a framework is and what it’s not. There are lots of different frameworks for everything, there are good frameworks and there are bad frameworks — and even more likely — there are suitable frameworks and unsuitable frameworks — depending on the purpose.
Frameworks are supporting structures — something to build further on. Some provide guidelines on what to do or not to do, some provide methods or recipes on how to build further, others do not. But everyone has in common that someone — you or the organization or somebody else —need to fill in the blanks. And most have in common that there are lots of blanks to fill.
They are not universal solutions. Different frameworks have appeared from different companies, environments, and periods of time. Many are created by really smart people within great businesses, and many have transitional value to other business areas, but every one and each have one thing in common — they weren’t created for your company like it is right now. Your company is most likely different in either size, industry, market location, IT systems, or at least — you don’t have exactly the same people. Most — if not all — frameworks need tailoring to your organization. This requires deep understanding of the framework, but also the organization itself. Also — no framework is perfect. They were created by humans, and nevertheless how brilliant they were, humans make mistakes.
Frameworks can be great starting points, as they provide common language, guidance and perhaps some processes or directions for “how”. For many leaders, this seems like a blessing. If you find yourself in the middle of nowhere and you have no idea of where you are, any kind of map that seem to show where you are, is like a gift from heaven. But even landscapes change, and the map might not show you everything you need to know. The purpose of the map, might not be to give directions, it might not be in scale, it might not be correct (anymore). New paths can have come, paths can have moved or even disapperared. You can’t even be sure it’s showing the area in which you are.
Someone sees a framework as a holy grail — a silver bullet — the one and only solution for a specific problem. In most cases, it’s not even close. No framework works for all organizations, there is no “one size fits all” framework —neither for agility nor anything else. Implementing a framework is never the goal for itself — it always serves a greater purpose. It’s a tool for achieving something else. Therefore, reading framework implementation guides as the Holy Bible, makes no sense. “Religious” view on frameworks creates more harm than help — even though some frameworks explicitly say that it your deviating from the framework, you are not using the framework. I wouldn’t be concerned about that at all.
That said — when implementing a framework, it might be a good idea to do it “by the book” in the beginning, and making changes later on when you have experienced what worked and what didn’t. There are often good intentions behind “strange things” in frameworks, and experience might have proven it to work better than the more intuitive options. It’s also crucial to bear in mind that many frameworks does not only contain of procedures and activities, but also require you to think and reflect differently. This last part isn’t always that well described in the implementation guides. Listening to talks from the people who created it (not certification trainers), often helps understanding the mindset and underlying assumptions and intentions.
Most frameworks require practice and training. It’s not sufficient to send a book or take a certification course, and believe everyone will read and understand. Understanding the whys of every aspect of a framework might be difficult, but everyone involved should have a deep understanding of why this change is needed. Not taking this aspect serious, is a safe trip to failure. Studying change management frameworks (!) might actually be a good place to start before changing anything, just to understand the psychology of change. By studying, I don’t mean certification training, but understanding basic concepts of ADKAR, Kübler-Ross, Kotter or similar, will make it easier to implement change — including frameworks.
Most change management frameworks can be summarized to “will not” and “cannot”. Every change — even organizational changes — will be effective if and only if the people involved change themselves. There are reasons I won’t change, and there are reasons I can’t change. By assessing peoples’ “will not”s and “cannot”s, you will find every change management framework—they describe more or less the same thing, just in slightly different ways.
Using an agile mindset makes implementation of frameworks easier and more doable. By taking small parts of a framework and adding piece by piece, you can get better and faster results than having a big project. Sufficiently small time framing is a good way to make this successful. Change management will be easier, as every change is smaller, and particularly in the beginning — making every small change a “pilot” or “test” that can be reversed, makes it less dangerous to try. Last but not least — step by step implementation only requires you to understand what you are doing right now and the direction you are going in, and gives you both value to the business as well as more learning while going forward. The larger the change, the more knowledge and understanding you have to gain ahead of the change.
The tricky part is how to split the framework in manageable pieces, and how to choose which piece to go on with. What order each piece is put in, does really matter. Most Value First is a great principle, and enterprise value should be an important criterion. This is where external consultants might be very useful, as they probably have more experience from a larger variety of companies, and have probably seen what has returned value in other places. But you can’t leave such a job to consultants only — as earlier mentioned, change come from within — and it’s only the people and organization itself that are capable of actually changing. They possess the invaluable understanding of the enterprise that is required.
The important thing here, is to acknowledge that some changes won’t work. Some might even go in the wrong direction. Every failure, however, is a matter of learning and reflection. Again — by using an agile mindset — this reflection about how you work, what worked and what could be improved, should be done regularly. In the beginning, it’s about figuring out what part of the framework will be the next, later on it’s about evaluating what parts of the framework could be even better, and by trying and failing, go step by step into a better future.
Not all frameworks are agile by nature, but most can be tailored to be — or at least those parts you need. When time goes by, you will most likely find out that many frameworks have interesting parts, but not everything suits your organization. Having confidence to just select what suits you and ignore the rest, is good. Being able to tweak and adjust is also good. You might not say that you follow a framework or is “compliant”, but again — that’s not the goal. Implementing a framework, and then leave it because you have “outgrown it” requires a great deal of courage. Purposely going from “compliant” to “non-compliant” could scare almost any leader. But again — compliance to a framework is not the goal. The important thing is that whatever you do, it works for your organization.
Agility and adaptability is more about changing the way you think than it’s about changing the way you act. The inner drive to continuously improve can and should be trained, and many small nudges are really effective in the long run. Like scoring goals makes you want to score even more, each successful change feeds this drive — also the small ones. Of course, any quick wins that are identified should be taken, but those are usually quite rare, especially when you have been traveling for a while. The journey towards agility is never ending, there will always be improvements and things that can be done better, easier, faster etc.
Building this culture of continuous improvement, along with sufficient authority to actually improve, is an absolute requirement of business agility. That requires everyone involved to think differently, including leaders. Leaders that embrace this way of thinking, will be more successful than those who don’t — no matter what frameworks that are being used — if any.
Published first time on Sept 17 2021 on Medium.com.