Part 2: Inspection—Transparency—Adaptation—Repeat
This is part 2 in a series of articles regarding why and how organizations should strive for Business Agility. In part 1 you can read about the rationale — why an organization should want to become more agile. In this article we will go deeper in how to make it happen. This is one of many ways, and will of course not provide all details. But it will take an adaptive approach — and following it will in it self give an introduction to a common agile framework, and hopefully inspire to go further on the journey.
Inspection — Assessment
If we revisit the elements that enable agility, we can modify Mr. Harbott ‘s extended diagram (from the article) to look more like a maturity model. I have added the technology dimension, as I mean this is an important aspect when talking about agility.
Luckily, most enterprises are not entirely at the red side! To assess how far your organization has come, Mr. Harbott also provides an maturity assessment, that provides maturity in five levels:
The full version — I have not asked for permission to include it in this article — also contains descriptions for more dimensions within each enabler — obviously not including technology. You can download the assessment free at 6enablers.com (Free Resources).
Of course it would be very unwise to change everyone at once, but it is also important to perform such a change holistically — and ensure that the entire organization is more or less in balance. My hypothesis, is that it’s more important for an organization to be more or less on the same level — than striving to come very far in a few areas, but lagging behind in others.
Step 1 for any organization, should therefore be to quickly assess itself to identify what enablers that is not on par with the others, and might be good candidates to start with. Find some low-hanging fruits. Obviously, it’s easier to start with a small, stable team than a huge department where people come and go. Large organizations would most likely want to assess smaller parts of the organization separately, and aggregating the results afterwards, or only assess certain parts of the organization that based on a gut feeling are likely candidates to start with. It’s better to start small and extend later on, than starting to big with a thorough assessment that you won’t be able to finish.
This might sound very unscientific, but in fact it is very, very difficult to quantify this objectively, and the gut feeling should not be underestimated. The important thing is to start, and keep progression going so you can start learning.
In parallel with step 1, it might be a good idea to gain decent knowledge about an enterprise architecture framework like TOGAF or Zachman, or even both. By decent, I don’t mean sending the entire organization to a certification course. The entire organization don’t need a deep understanding of the methodology, even though there might be good things to pick there as well for some. Frameworks are a good way to get a common language, to avoid confusion. They can also provide visual explanations of contexts and connections, making it easier to discuss these matters throughout the organization, but this too is needed only by a minority. The really important thing however, is the understanding of what enterprise architecture is, and why business agility is a key to survival. To understand that an agile enterprise will change all components of the perceived enterprise architecture dramatically — but most people will consider it an improvement.
It’s important though, to be aware that there will be forces fighting towards such transformation. The stronger hierarchical an organization is, the more challenging it might be, as position in the organization chart usually is a result of hard work, and not everyone would like a flattening of the organization, that usually comes as a result of more agile maturity.
For any change, it will be much easier to understand both success and failure if you have an understanding of the psychology behind change. Change management tools can be very helpful to deal with resistance, as it can explain psychological mechanisms. There are multiple theories and frameworks to address this as well — Kübler-Ross, Kotter, ADKAR, McKinsey 7S, 5As and many more. Again, it’s not important which framework — they all contain the same major elements, but some are providing more practical tools, and some are giving a more theoretical psychological understanding. Choose one — and stick to it as long as it works.
Step 2 would be to assess a few of the low-hanging fruits more thoroughly, and find a good starting point — or the other way around. There are several things to consider, but again — it’s more important to start somewhere and start learning than not start because you are searching for the optimal point. One of the most important factors that should be assessed in this step, is the culture of the organization/department. There are several methods for this, I’m most familiar with the OCAI-method. The important thing, however, is not how you do it, but that you do it. Everything you do to understand your organization better, will provide you with insight that will make it easier to understand how to implement change in your organization. And being able to adapt to change is all this is about.
What next?
The following steps are more difficult — as they depend on the results of the assessment, and naturally the actual part of the organization you are starting with. The actual changes has to be deduced from the insight about the organization assessed, and there is no certain right/wrong answers of where to starte. There are however some key points that are relevant to all parts, and some relevant methodology that can be explained briefly.
Agile frameworks or Business Agility frameworks might be a good way of getting further on, depending on which part of the organization that is selected. It’s important to remember that although many agile frameworks were created for software development, they have very good effect in other parts of the organization as well. While doing the first steps with assessment, you most likely have gained a decent understanding of the organization. As frameworks are different both in structure and complexity, it’s best to learn a little bit about all, and pick the one that seems best suited for your existing organization. Some are meant for changing only a certain parts of the organization, even though they might impact everything — like Beyond Budgeting is a great tool for economy governance in an agile organization — that deserves an article of it own. Others fit for larger organizations with strong, existing hierarchies and strict processes — like SAFe. Others again are good for organizations using e.g. Scrum successfully in single teams, but now need to coordinate this — like LeSS or Nexus.
There are many choices, and even though you should learn about them all to do the right choice, it might also be good to search advise from a consultant that have experience with multiple frameworks. And from my experience as an enterprise architect — it’s wise to see the frameworks holistically in the context of your enterprise architecture. Because it’s a system, everything will be affected, both the employees feeling of it, as well as the external perception.
It will never be possible to understand in it’s entirety how changes will affect other parts of the enterprise architecture, but being able to collect as much relevant data as possible and visualize it automatically, will make it easier to gather insight to make better decisions. Remember, technology and IT systems are also a part of the enterprise architecture, and mastering them will give an advantage also in a agile transformation.
Anyhow, frameworks are exactly that — frameworks. — and you should adapt and fill in the frames yourself, to suit your purpose. When you are new and unfamiliar with them, it might be a good idea to stick with them, as you might not have better alternatives. When you get to know them, however, don’t be afraid to bend and adapt. It’s not a defeat to adapt frameworks — they don’t describe the correct solution for your business — in best they provide some kind of description of good practice that others have found to work for them. That doesn’t mean it will work for you — at least not exactly as described.
With some experience however, they might be even better as inspiration — they can give you ideas that can be adjusted and tweaked, and combining elements from different frameworks can give magnificent results. Remember, the important thing is not what you call the way you work, but that it works. If you can’t explain why you are doing something, other than a framework stated so, then it might be completely redundant in your business.
Start small with a pilot
Start small, and select a small part to start with — preferably something that is easy to see the value of, is easy to measure and won’t be a controversial change, and therefore is likely to succeed. The tricky part might be to find something where you are able to measure success. If it’s possible to establish continous monitoring, it’s great, but not an requirement at this stage. You might not have a good baseline measurement initially, and if it’s not possible to establish this, it might be wise to choose something else. You could be using qualitative measurements like interviews, but it can be quite time consuming, and could steal momentum from getting started.
Keep the pilot short enough, two or three months are generally a good idea. This gives room for quite a lot of change, however it’s not too long so it won’t be impossible to reverse, and it still gives some pressure to delivering some results.
Split the pilot in 7–10 equal timeboxes of 5–10 working days, where you start with planning the coming timebox — what changes are we able to do in a week or two, and inspect results in the end. The planning should include some kind of measure of success — how do we know we are on the right way, and when do we know we have succeeded? The inspection could be done with some leadership stakeholders, to include them in the work. Most likely, some of them have funded this pilot — and should be interested in how you are going.
Before starting a new timebox, reflect with the team and motivate suggestions to change how they work and colaborate together. Are there any new people that should be “moved” into the pilot? Are there any speed bumps in how we work — decisions that others do, that should be done within the team? Do we have the tools we need to work the way we want? This should not be planning of the next timebox, only a group reflection session of how the team actually work.
Afterwards, start a new timebox with a new planning session and repeat. It’s not required to keep the start on Monday and and end on Friday — actually there could be advantages with not doing that — as this gives the possibility to start a new round straight after finalizing the previous, and the team reflections fresher in mind.
Some of you might recognize this as a simplified version of Scrum — a common agile framework both in software development — as well as increasing popularity other places. I find Scrum suited for a lot of things, including becoming more agile. It gives a structure that can be a success criterion for many less mature organizations, as it “forces” repetition and activities that help internalizing behavior and mindset. It’s also really easy to understand on a high level — both for participants and executives, so even if it might be radically different, it’s not that scary. And because of the simple, but effective structure, it’s fairly easy to use it to provide results within quite short time.
However, it’s really important to see frameworks as starting points for the next step — not a final destination! Whether it’s Scrum, SAFe, Spotify Model, AgileShift, LeSS, Nexus or whatever, they are created to make it easier for an organization to start their agile journey and scale up agile initiatives to the entire organization, but implementing a framework does not make the organization agile, even if it does all the activities and has restructured completely to fit the framework!
By nature, a tryout comes to an end, and somebody must decide whether this should be made permanent or reversed. By permanent, I mean continue evolving, of course. As time goes by, the practice probably will spread to other parts in the organization. Sharing (transparency) is a good thing, and you would like everyone to learn from each other. But not everything works the same way everywhere, and there will come new matters that nobody has faced before, and many organizations struggle with scaling agile methods to the entire organization.
A completely agile enterprise?
Even if it sounds great with a completely agile enterprise, it might not be realistic. As everything else in the world — an enterprise will always remain imperfect, and all organizations have some non-agile boundaries like governments, financial and legal authorities, they might work with other companies that don’t use agile methods. Some parts of the organization might have more resistance, and executive leadership does not want to force change to hard. Other parts might work very well as is — and the need of becoming more agile isn’t that obvious. So at a certain point it comes to an end — at least for a while.
There is no certain truth for every organization, beware of the desire to scale agile with implementing frameworks. You will have a better chance to descale the organization to do agile, than the opposite. Try to keep it simple — small autonomous teams having their own mission in a greater context — working as independent units close to a small number of other autonomous teams, are more likely to perform well than larger units with strong dependencies to others. It’s also easier to implement changes on small units than larger units.
In fact, for those who know software development, this is exactly the same we try to do in computer systems. Microservices, with small autonomous functions, standard interfaces, but loosely coupled with other functions. Strict definitions of the output of the functions gives us ability to implement change whatever we want inside one function — even the entire programming language — without disrupting anything outside. After all, many architectural principles are general — even between disciplines of architecture.
Success factors
There are some matters that are important though:
- True leadership support — from the very top. The CEO is a major contributor to organizational culture and visionary work. Without CEO obsession for this to work, it won’t — at least not in scale. Change leadership towards the CEO might be a key point!
- Intention based leadership — where the overall goal is well described and communicated, both on long term and short term context — is more likely to work. Make sure the workers understand the how their work contributes to the vision and mission.
- How the delivery is done, is decided by the team. Standardize the output from teams — but not the way of creating the output. True autonomous teams are able and allowed to create output in the best possible way — within the predefined boundaries. They need to have all the competence and authority to take decisions that concern them. Also regarding money.
- Trust your workers and share information whenever possible. It makes it possible for the best people to raise the hand and contribute with their competence and experience. Trust is something a leader gives, the employees should not need to deserve it. Flat structures makes transparency easier, and lower the threshold for suggesting improvements and even contradictions.
- Praise loyalty, but discourage obedience. Loyal workers do whatever is the best for the mission, obedient workers do whatever is the best for the task — even though it’s not the best for the overall mission.
For many leaders, this can seem quite scary, and I suppose that is a major reason why not more companies are embracing this. Agile transformation actually means everyone — including leaders on all levels — have to change their way of acting. It’s always easier to want others to change, than do it yourself. But true leaders will understand that this is important, and their role is changing. From being the “expert” who knows what to do, to the “servant” who asks questions and removes obstacles. As Richard Branson said:
“If you look after your staff, they’ll look after your customers. It’s that simple.”
What if the pilot fails?
If the pilot period is finished and it’s decided not to continue, a thorough review should be done. This should be similar to retrospective sessions after each timebox — however it won’t be a next period. I would recommend an interview based evaluation of the participants regarding coaching and motivation. There are many possible reasons — however it’s likely that they haven’t seen as good results as wanted, and probably should have got more coaching during the pilot — or maybe better coaching. Sadly, not everyone working with agile methods are great. Lack of leadership support might be another reason. Anyway, the important thing is to search for the good things, the things that actually worked, and learn from the things that didn’t work — why they didn’t work. Preferably — don’t give up, but try again! Perhaps with somebody else, or working harder to ensure the top leader is working with you.
Agile coaching
For many organizations, it might be a very good idea to hire an experienced agile coach to assist the teams becoming more agile. An agile coach is not a member of any team, nor a leader, but is trained in coaching both teams and leaders to become more agile. Many organizations hesitate about this, because the coach does not contribute directly to revenue. However, this is considered a good investment — and for many organizations a critical success factor for reinforcement in their agile transformation.
Whether this should be employed or hired as a consultant depends on where you are and who you are able to get, but it’s generally a good idea to get someone from the outside, as they can bring very useful perspective and experience into the organization. Hiring a new internal employee will be cheaper in the long term, and agile transformation is definitely long term — probably forever. It’s more difficult, however, to get experience with multiple frameworks and companies unless you get a consultant. The best might be to hire an ex-consultant internally — if you are able to.
Depending on size of the company, you might need more than one coach. In my opinion, inside knowledge about the company is more important than having multiple experts on frameworks and methodology, so even if the first coach very well could be recruited externally, the others could and probably should be trained from internal employees.
Most businesses don’t really have a choice, even if they haven’t noticed. They need to be more adaptable and agile to survive the competition. However, it’s not enough to do agile activities, reorganize and get some certifications. The entire organization has to change, from the people on the ground to the top. Processes, systems and organizational culture have to change. Even though change is difficult, most people who have been through it, prefer to work in an agile environment, with strong autonomy, collaboration and outcome orientation. Nobody says it’s easy, but it’s worth it. It’s simply a better place to work.
There are multiple aspects of an enterprise that can enable agility, and the enterprise should strive to mature within all of these, more or less in parallel. Frameworks and methodologies can provide guidance — but they don’t make any enterprise agile. This is more thoroughly discussed in part 3 of this series.
Being agile and Business Agility is all about mindset — how everyone in the organization think, and act when not thinking.
Published first time August 9, 2021.