The 7 Oops of agility - Chapter 6
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 sixth part of my blog series on agile change. In seven chapters, I will 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 6: Honeymoon effects
We are all very excited about the agile approach!
What do you want to do to keep that enthusiasm going?
We are sure that we will infect the others as well. Then agility will spread virally throughout the company!
The much-cited VUKA world brings with it intensified challenges: for example, the challenge of reacting quickly to changing situations; or the challenge of surprising the market with innovative offers. These challenges are, of course, anything but new. What is new, however, is the extent to which many organizations are struggling with them - and how much they are struggling to find appropriate solutions.
Too slow, too cumbersome, too boring is often the finding when it comes to entrepreneurial performance in the digital age. Agile, lean, innovative is the antidote offered by agile experts. No wonder that these methods are in vogue - after all, the promises of happiness from Scrum, Kanban & Co are all too tempting.
Nor should we be surprised that managers expect these promises to be fulfilled quickly. After all, agility literally promises speed. Crafty training providers are raising expectations to unimaginable heights: With agile, the core message goes, you'll be floating on cloud nine entrepreneurially! It can easily happen that you fall head over heels in love.
When agility is so attractive to so many, the decision to combine the existing organization with the agile approach is easy. Sometimes the introduction is staged as a real dream wedding: as an enthusiastic event (keyword: fireworks), with trend-setting board speeches (keyword: future viability) and a thoroughly calculated change plan (keyword: Big Design Upfront). It is only natural that the first changes then feel like the purest honeymoon.
The awakening comes as soon as the daily work routine reality hits back. Starting an agile transformation is not the great art. But sticking with this transformation is. After a few months at the latest, the last pink clouds have disappeared. All of a sudden, nothing is as sexy as it was on the honeymoon, and sometimes even tough confrontations are on the agenda. Some people ask how they can achieve entrepreneurial agility if they stick to the existing structures; if teams and roles are redefined but the value-generating processes remain bumpy; if there is no cross-departmental coordination and hierarchical relationships are not questioned.
For some, these notorious honeymoon effects mean that high ambitions quickly evaporate. For others, the effort is undeniable, but the collective energy for change gradually wanes. The third parties, in turn, increase the pressure to implement: Ho-jerk actions follow ("tomorrow we will be a high performing team"), fast-boiling courses ("in two days you will be an xxx-master!") and superficial efforts ("we're going all out now, we'll deal with the impediments later"). In addition, there are those who switch back to the old operating mode if the worst comes to the worst ("This is so business-critical now, agile working is much too risky"). And then, of course, there is also the gradual regression to the old conditions, because nobody seriously cares about continuous improvement...
How can such honeymoon effects be avoided? The will to improve is something that few people can deny. But as we all know, wanting is not enough to bring about sustainable change; it also takes ability - otherwise, according to the old management motto, it would be called change bulge and not change art. But what does it take for such skill? Which competencies are necessary?
What exactly does agility mean? Does it even fit our current situation? Does it help to solve our problems? And how exactly can we tell that the overall situation is improving? Don't neglect such examination questions! Especially at the beginning of a possible agilization initiative, you should take enough time for a prudent situation analysis - and explore the current strengths and problem areas from a variety of perspectives. Only this joint exploration creates the basis for sounding out the benefits and costs of the envisaged change. Agile weddings do not happen under all circumstances.
Even the most energetic introduction is not enough: it is about a powerful continuation, about a continuous learning and relearning, about successive potential development, in short: about evolution. At the risk of repeating myself: agile development takes time, it doesn't happen at the push of a button or overnight. It also does not follow a sophisticated transformation plan. In a way, the agile approach rather seeks its own path, meandering through the organization, hitting different blockages, maybe even a downright dam wall, before finding new ways to flow on again. Design the change process accordingly agile, don't commit too much at once, but ensure continuous learning!
Understanding agility adequately is an important prerequisite for realizing the desired improvement. But understanding alone is not enough - agile practice is the order of the day. Avoid half-hearted action. Instead, rely on disciplined practice that is continuously exposed to feedback from colleagues, from customers, and not least from measurements. This means continuous training and coaching at all levels. It's all about building something like agile fitness, endurance running not individual sprints.
Finally, you have to keep an eye on the notorious knowing-doing gap: You know how agile works, but you still can't implement it; you firmly believe in working agile, but critical observers are convinced of the opposite; you see yourself on the best way to make your business more agile, but the numbers tell a different story. This may be due to the people or the interactions, which remain formal-bureaucratic instead of congenially moving. More often, however, it is due to the framework conditions, especially consistent focus (rather than dispersal), distribution of decision-making authority (rather than centralization), and effective coordination (rather than unaddressed dependencies). Put the ongoing work on the system accordingly at the top of your agenda - the agile change flow will thank you for it, just like the work in the system!
And here's to the other oops: