Agile: Asking the Right Questions
How can we become (more) agile? Many of my conversations begin with this question. So someone wants to work differently, wants to become agile or more agile. The expectation is mostly to be taught new and better methods to do their job in a better way. But this question of how to do agile almost always doesn’t go deep enough. That’s why I usually answer it with a few clarifying questions. Which problem should the desired agile methods actually solve? What do you want to achieve? Why do you want to work agile? And finally, what is the subject, the product, on which you want to work agile? But one after the other.
Why: The Motivation
He who has a why to live for can bear almost any how.
Friedrich Nietzsche (abbreviated by Viktor Frankl)
Unfortunately, it is often not clear which goals should be achieved with those shiny agile methods. At least not to those who come to me with their questions. They have received the assignment from a higher authority and are now trying their best. This cannot be blamed on them, but on their principals. There is a good reason why Netflix’s Culture Statement states: Context over Control. But that is actually another topic …
The leader’s job at every level is to set clear context so that others have the right information to make generally great decisions.
Sometimes it turns out during the clarification of the motivation that there is only this one: “Others are doing it as well”. Of course, you can do that, but you shouldn’t. Sooner or later the discussion will lead to the insight that somehow people should work faster and more efficiently. The agile methods are seen as a kind of concentrated feed for the employees in order to increase performance. At this point I usually explain this great picture of Henrik Kniberg:
This illustration shows that the essence of agility is short feedback cycles. At short intervals, usable product increments are delivered and the findings from the actual use of these intermediate products then influence the next steps (this is why the picture in the lower sequence shows a convertible and not a limousine, because on the way it was learned that the customer loves fresh air). Agility really accelerates … learning!
These short learning cycles are useful and necessary whenever the goal is unclear and the path to it uncertain. The right motivation for agile work therefore always has something to do with uncertainty and complexity and thus the desire for more flexibility and adaptability. If a known and planned result is to be reached only more efficiently, agile methods are the wrong tool no matter how many others are doing it. The most efficient way to design a convertible is certainly not to use a skateboard, a scooter, a bicycle and a motorcycle as intermediate solutions.
That’s where the discussion might end. Most of the time, however, I continue it because certainty is deceptive. Perhaps it is clear here and now that and how a convertible should be built. However, it is by no means foreseeable what will happen on the way and certainly not whether in the end (and this is usually years in the future) the customer still wants a convertible and if so, if he really wants the planned one. And maybe the motorcycle or the bicycle would have been sufficient. This uncertainty, which is mostly denied in a plan-driven approach, usually gives nevertheless a great motivation to become more agile.
What: The Product
Now that the why is sufficiently clear, the question arises on what we should work in an agile way. In the worst case this is the work of a committee or something similar. Don’t get me wrong. I welcome the fact that decision-makers are exposing themselves to agile methods and want to try them out for themselves, but a committee is not a team working on a joint product. It’s a group that makes decisions together. The members do something together 5% of their time, namely making decisions, and 95% of their time they do their actual work in their respective silos.
So let’s skip the agilization of the committees (in the course of a larger transformation, the goal would be to eliminate them anyway and make decisions again where the information is, namely with the teams) and turn to the case that a group of people jointly produces something meaningful for the organization (even better, of course, for the customer!). This could be software, but it could also be brand communication or audit reports.
In our functionally divided organizations, however, it is usually the case that the desire for more agility arises only in a small section of the entire value chain. There might be, for instance, the team that develops software for electronic control units that wants to become more agile and worries about scaling and coordination. So far, so good.
If one then looks at the path from the requirement to verifying the software on the electronic control unit in the vehicle, it becomes evident that this team is only a small part of a much longer chain of handovers (and this functional division into specialist functions is well justified in some ways … at least it had some justification an benefits in the past). The idea first becomes a concept, which then goes to an architect and then is verified by a data modeling expert. Then, the software is created by this development team from the previously approved concept. However, it’s far from being finished. First the software has to be deployed onto the control unit and then this unit has to be built into a vehicle and only then the feedback loop is closed and learning happens. Klaus Leopold uses this beautiful and unfortunately not so unrealistic picture to illustrate this problem:
So the much more interesting question at this point is how this feedback cycle can be shortened end-to-end and thus learning can be accelerated, because that is all that matters in terms of agility. The already halfway agile development team is definitely not the bottleneck. Instead, agile and interdisciplinary teamwork is required across the boundaries of silos along the entire value chain. However, this is not intended and is not always welcomed by the respective lords of the individual silos. Therefore, with the why and what it usually starts to get really interesting, the how is always just the second step.
A prudent question is one-half of wisdom.
Francis Bacon
Originally published at https://fuehrung-erfahren.de on September 10, 2019.
