The 7 Oops of agility - Chapter 2
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 second 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 describe useful.
Chapter 2: The means justify the end
The most important thing for us is that the agile approach works.
How can you tell it's working?
When the iterative procedure runs smoothly, all Scrum Masters and Product Owners fill their assigned roles and the agile management takes hold. After all, we have invested a lot of money in appropriate training!
I see another source of various mishaps in the widespread confusion of means and ends.
Although officially it is about improving throughput or time-to-market, the introduction of agile approaches gradually mutates into a goal itself. All of a sudden, it's all about deploying the right training and consulting, acquiring agile certifications, inventing new meetings, setting up sharing guilds, and the like. None of this is fundamentally wrong -- except that sometimes the why of change gets lost in the shuffle of change management.
Instead of using Scrum, Kanban & Co to make their own customers more satisfied and to open up new market opportunities, companies focus on implementing them in specific organizational units (preferably in software development).
Where the focus is on the agilization of individual units, however, the much-cited big picture is easily pushed into the background. In order to make the company more agile, however - as Klaus Leopold has clearly shown - you must not only focus on individual teams or work areas. Rather, the main issue is how these areas are connected to form a value stream that leads from an initial idea to a satisfied customer. At the same time, we need to consider the various interdependencies and the corresponding need for coordination.
Certainly, successfully strengthening business agility requires prudent introduction events, profound training, targeted coaching and so on. This inevitably takes a lot of attention. However, this should not lead to losing sight of the goal: What are we actually trying to achieve? Who are we doing it for? Why do we need more agility for this? And how can we tell that we are making progress?
It gets rather bizarre when the obvious question about the concrete benefit - what does agility bring us? - is answered by the number of training measures carried out. As in the case of an international service company that measures its agile maturity by the number of certified employees. Counting agile teams or the "successful" agilization of IT is admittedly not much better.
And here are a few pointers for all you roadside assistance and prevention enthusiasts:
In order for agility not to shrink to an end in itself (see Upps chapter 1 "The Olympic Idea"), it requires a thorough examination of the classic W-questions: Where exactly do we have a serious business problem that we need to work on? How do agile approaches help us work through it? How do we want to proceed? And how do we know that we are making the desired progress?
It is in the nature of the agile thing that these questions are not answered only once in the beginning. Instead of setting the current answers in stone (keyword: project plan), they need to be reviewed and adjusted at meaningful intervals. Although this sometimes leads to unpleasant insights (also called learnings by brave people), it is indispensable if the market is to take centre stage.
If the goal is not focused on agilization but on better results for the customer, the question of meaningful measurement criteria inevitably arises. How can we tell that the customer is more satisfied? How do we get relevant feedback? What do we do to make this feedback actionable? And what measures do we take to ensure that we not only measure, but also learn?
At the latest when you use focused measurements, you are thrown back on the question of what you actually need to agilize in order to achieve the desired goals. Experience shows that strengthening your business agility requires more than just agilizing individual units. If you want to shorten the much vaunted time-to-market, for example, you need to optimize not teams or departments, but their interaction. However, this ultimately forces you to work on business processes and not with the organizational structure (roles, teams, project groups, departments, etc.).
And here's to the other oops: