The 7 Oops of agility
Which paths lead to more agility? What do companies stumble over time and again? And what do you have to watch out for so that the whole thing doesn't degenerate into a mishap? This is the first part of a small blog series on the topic of agile change. In seven chapters, I outline some characteristic phenomena that I experience again and again in my work with various companies. I'm happy if you recognize yourself in one or the other scenario - and I'm even happier if you find the preventive measures and first aids I've described useful.
Chapter 1: The olympic idea
You specialize in Agile Change, don't you?
Yeah, why?
We want to make our company more agile!
And what exactly are you trying to accomplish?
We cannot ignore the trend - agile is now on everyone's lips!
Being there is everything - that seems to be the motto for many an organization when it comes to agility. Who wants to be left behind when entrepreneurial agility is at stake? When Scrum, Kanban, Lean Startup or Design Thinking are already standard operating procedure at the competition? And even the big consulting firms are convinced that nothing will work without agile in the future anyway?
In practice, however, the Olympic idea achieves little. On the contrary:
Suddenly, it's more about being there than about using the agile approach in a targeted way. The urgency - à la just don't miss the agile train! - favors various tunnel effects and often leaves the "why?" question in the dark.
Strengthening corporate agility is often declared to be the order of the day. Instead of using an equally agile change management, however, people often rely on traditional project management: from detailed planning to strict controlling of the planned implementation steps to orientation on fixed milestones. Reflection on ongoing change experiences and continuous learning have little place here -- not to mention that they lead to the consistent redesign of the change process.
The attempt to define the measures for more agility as comprehensively as possible in advance (keyword: framework) also has the consequence that neither the specific strengths and problems of the various company areas are started with, nor is the concrete need for improvement distilled from them. In many cases, the organizational solution is fixed from the beginning.
Instead of adequately involving employees in the design of the agile path, programs are rolled out. In the course of the training and consulting measures that then take place are in danger of becoming extras. Moreover, those for whom one would "actually" like to become more agile are affected: the customers. Where are they meaningfully involved? Where do you get feedback from those who alone decide on the value of the products and services delivered? How do we ensure that this feedback impacts our next steps of change? And how do we measure whether our agilization efforts are bearing fruit at all if we leave the customer out of the equation?
In short: Where the plan rules, entrepreneurial intelligence easily falls by the wayside. However, agilization without the use of existing experience values, problem views and solution potentials is like participating in an Olympics for which one does not prepare.
To prevent various mishaps, we recommend:
Base the desired agilization on a clear business case - and review it regularly. The basic questions of agile change must be answered again and again: Why exactly do we need to change? What is the most important problem we need to solve now? How can we tell that we are getting closer to the desired solution? And how does an agile approach actually help us to do this?
Don't think of agile as a broad-spectrum tonic for all of your organization's problems. Instead, clarify where "agile" makes sense to use in the first place. After all, sometimes it's not about agility, but about efficiency. Or would you like the train drivers of a railway company that is sworn to agile to suddenly think about which route they are driving today or whether they don't want to take a break in between?
Find out where the company is already acting in an agile manner. It is often pretended that responsiveness and adaptability are completely new skills and not one of the basic qualifications of all companies that are successful in the market. Acknowledging the existing agile potential and successively expanding it is not only a sensible starting point for any improvement initiative, but also a question of the respect we owe the existing organization -- and thus also the employees who fill this organization with life.
Keep the big picture in mind. Wherever you want to strengthen your business agility, you should align the associated change with other improvement projects: What initiatives are already underway? How do these relate to the planned agilization? Where are there synergies? What undesirable side effects could occur? And where are there even obvious contradictions - as in the case where in the same organization more agility and a cost-cutting program with rigid control mechanisms were implemented at the same time?
Think carefully about how you will manage the journey towards greater agility: Who will be affected? Who should be actively involved? How can we break down our plan into meaningful stages? How do we ensure that we learn from the individual stages in order to continuously improve in the management of change as well?
And here's to the other oops: