The 7 Oops of agility - Chapter 7
Which paths lead to more agility? What do companies stumble over again 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 seventh and final part of my blog series on agile change. Once again, 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 prevention and first aid measures I've described useful.
Chapter 7: Agile is good for everyone
What have you tried so far to solve your problem?
Nothing that really helped us.
And what would have to happen for that to change?
Well, the whole thing just needs to be a lot more agile....
Being there is everything, is that Olympic thought with which I opened my blog series on agile change. I'll close with a motto that not coincidentally sounds like an echo: agile is good for everyone! So does agile work as a universal miracle cure after all? As a kind of broad-spectrum tonic against any organizational ailment? As a magic potion administered by agile Miraculixes?
Like other management buzzwords, the term agile works a bit like a inkblot test, where each observer can project their own ideas onto a shapeless inkblot. Accordingly, the definitions that come to one's ears in practice vary: for a medium-sized automotive supplier, agile is an important working method that increases the quality of projects; for an infrastructure company, it is above all a mindset that promotes a completely new way of thinking; for a software company, agility functions as a toolbox from which the appropriate tool can be taken according to the situation; for a large insurance company, on the other hand, it means a profound paradigm shift that changes the entire business philosophy.
What's the problem there, I can literally hear you ask. After all, the companies mentioned are extremely diverse, the world is more colourful than ever and the demands of customers and employees are correspondingly varied. The problem, of course, is not the diversity per se, but the different strategies that are built on the respective basic understanding. What exactly is to be improved? How does agility help? What is the focus of improvement? The organizational development answers range from individual training (agile as mindset) to strengthening cross-functional cooperation (Chapter 4)to resource optimization (agile as flexibility).
Not only are the strategies very different, but so are the results they achieve. Agility can train the ability to perceive (better customer orientation), increase employee satisfaction (better work culture), increase productivity (better development results) or expand the attractiveness of the employer (better image). So apparently agile is good for a lot if not everything after all. So do we need nothing else to meet the current challenges? Is agility synonymous with successful change management in the 21st century?
Not different, but surprisingly uniform seems to me the view that agility brings something completely new with it - something that many companies now want to have. This fits in with the pressure to innovate that hardly any company can escape these days. It is easy to overlook the fact that companies have always had to demonstrate a certain degree of agility in order to operate successfully in a market that has been volatile, uncertain, complex and ambiguous since before yesterday. It may well be that they don't call their approach agile - but customer proximity, regular feedback, strategic clarity and rapid implementation have long been essential success factors.
So what can you do without reinventing the wheel? To expand your agile potential in a targeted manner? And achieve the best possible effect in the process?
A solid understanding of the term is a good start. Agile, nimble, mobile, the dictionary tells us about the literal meaning of agile. So literally, the word has nothing to do with flexibility or innovation, nor culture or mindset. So beware of what the Heath brothers called semantic stretch. Otherwise, you run the risk of agile sharing the fate of many once-powerful terms: to become a hip, albeit fuzzily used, increasingly inflationary, and correspondingly meaningless buzzword that makes more and more people roll their eyes.
Also be careful not to mix completely different levels of abstraction. In a sense, as Niklas Modig's and Pär Ahlström's example of lean shows, fruit in general (agile as a philosophy, set of values or culture), core fruit in the narrower sense (agile as a method, process or framework) and green apples in particular (agile as standup, retrospective or iterative planning). Make sure you have the necessary clarity about what exactly you have in mind and how you link the different levels in a meaningful way!
Both the inflation and abstraction traps underscore the need to look closely: What exactly do you want to improve? Who needs to get moving to achieve it? And how exactly will you know that you are moving forward as desired in doing so? In other words, it's all about strategic focus, which of course - so much agility must then be - should be continually reviewed and adjusted as necessary. Resist the temptation to copy and paste solutions that have proven successful in other contexts into your company. And also beware of standardized agilization maps - the likelihood that these will fit your company landscape exactly is quite unrealistic. Instead, deal with your concrete situation, sharpen your perception, identify specific leverage points and define observation and measurement criteria to keep the desired improvement on track!
Don't overlook the fact that, despite all the strategic focus, there is always the psychological aspect. Agile is all about people - after all, individuals and interactions are at the heart of the agile manifesto. Nevertheless, agile is not good for everyone: neither for all customers nor for all employees or stakeholders. As the old change management adage goes, it is never possible to win everyone over. Don't turn your agile transformation into forced happiness, but also resist the temptation to please everyone. After all, that would almost inevitably lead to, as explained in Chapter 5 on "Living Beautifully", conflict avoidance and an excessive willingness to compromise. Instead, define clear expectations and the framework within which those expectations are to be met. In the end, this will help each and every individual the most in finding her or his personal answers to the key change questions: Do I need to become more agile? Do I understand the business imperative? Do I want to? Am I ready to embark on the adventure of agility? Can I do it? Do I have all the skills it takes?
Last but not least, agile is not necessarily good for all business areas. Instead, the mapping developed by Simon Wardley shows us how we can meaningfully distinguish between different areas of application. The map that emerges represents the current situation according to two dimensions: first, the value that a particular product or service has for the customer; and second, the maturity of the respective product or service. Depending on whether we are talking about completely new ideas, tailor-made services, standardised products or mass-produced goods, agility has very different benefits. To put it simply: wherever companies are dealing with high complexity and uncertainty, agility is highly beneficial; whereas wherever they are dealing with operational efficiency, agility offers rather little. Invest the energy to gather some bright minds and work out a differentiated map - the collective overview will thank you for it, as will a clear strategic direction that keeps the necessary facts in mind instead of blindly plunging into agile change.
And here's to the other oops: