[:de]Agility has long since shed its label of a trending topic in the workplace. Nowadays, it's not just agile pioneers who are embracing this way of working and culture: Agile transformation is being promoted or at least considered in a wide variety of industries and types of companies. This often raises the question: Where do I start – behavior or thinking? Or to put it another way: What came first in successfully agile organizations – the agile mindset or the agile methods?
At KI.M, we support various clients in different phases of agile transformation – including helping them to first consider agility within their own company. In this blog post, our colleague Zita Cornelius delves deeper into what can be the starting point for a successful agile transformation, thus illuminating the "chicken and egg problem" of agility.
Zita, what is your answer to the chicken-and-egg question of agility: Do you need the agile mindset or agile methods first?
Wow, an intriguing and not easily answerable question. It's a hotly debated topic even among so-called experts. But I can make one statement: One thing leads to the other. So, as a company, I should definitely consider both aspects.
And what exactly could the start of the agile transformation look like if I, as a company, should always consider both facets?
First and foremost, as a company, I should ask myself why I want to adopt an agile approach. Agility isn't inherently better, and it certainly isn't suitable for every type of work. Nor should it be introduced as an end in itself; rather, there should be an obstacle or a need that makes agile working necessary—for example, shortening time to market or responding to short-term changes in requirements and the environment.
And what about the reason why a company simply wants to try out agility?
In principle, the openness to trying out agility in the company is a very good thing. However, as a company, I should consider the consequences beforehand and weigh whether the experiment with agility is worth taking the risks of a lack of strategy and potential failure. Thinking one-dimensionally: Those who struggle with agile working may become dissatisfied and work more slowly as a result of the experiment. Those who support it may not be ready to go back afterward. It's better to have a clear goal that is being pursued with the agile transformation.
Now I have clarified my why as a company – what now?
Now I would anticipate the consequences of the why or what for in behavior. Agility, for example, also means the commitment to creating added value with everything I do. Sounds like that's something you can generally expect from work. In reality, however, many things happen because outdated processes are the way they are or because hierarchies have decided otherwise. Let's take a medium-sized company that is considering converting its fleet to e-mobility. It's conceivable that this idea would be quickly dismissed because the administrative effort involved in leasing contracts, installing charging stations, etc., would be too much. A decision would therefore be made (against) it, even though the conversion would have offered significantly more added value (ecological footprint, government subsidies, etc.). Agility would have meant more work or the use of internal resources here – this is a new way of thinking and evaluating options that first needs to be established.
So we first have to change our thinking?
Well, thinking can't simply be changed. One might also ask whether it's a bit overreaching to try to change people's thinking. The approach of introducing methods that slowly introduce people to a new working world is more promising. However, I would anticipate the consequences this will have on the behavior of managers and employees. It helps if the so-called decision-makers of the transformation can estimate in advance how long their journey will take and what hurdles they will have to overcome. Of course, this will only become apparent in concrete terms during the process.
How can I, as a decision-maker, roughly estimate this?
I need to determine the status quo: What leadership culture do we have? What values do we have, and how are they lived? What are our processes and reporting lines like? What is the state of our customer base and our wider environment? This can be determined, for example, through observation and surveys – methods we have been using at KI.M since 1999. I can then compare my current picture with a desired picture. If I now decide to implement the transformation, I can create tasks that I must master in the change process.
Probably a very long list…
Yes, probably. But above all, a dynamic one. That means that I'll always notice things along the way that I need to add to. Personally, I'm a pragmatist and would recommend to most of my clients to start with low-threshold methods that don't yet shout "agility!" Low-threshold doesn't mean low effort—I'm thinking of topics like feedback or meeting culture. Specifically, I could, for example, hold a kick-off event for transparent communication of the transformation with all managers and employees, announcing two phases, the first of which might include a new meeting culture.
Please briefly explain your suggestion regarding meeting culture.
Meetings should be held more frequently, but in a much more condensed format. All the people and responsibilities needed for quick decisions should always be present, with each individual contributing value. Furthermore, everyone should take away a self-selected work package from the meeting. This usually results in enough changes for me to observe how advanced the mindset has become within the method. Are employees proactively taking responsibility? Does everyone maintain a focus on results?
So I observe and then evaluate whether it needs more getting used to or whether I can move on to the next task?
Yes, exactly, something like that. I reflect on the first step and see whether the workforce is ready for further changes or whether additional measures such as training are needed. For example, we've had very positive experiences with the model of first conducting a basic training session (one to two days, virtual or in-person) and then offering an agenda-free exchange session a few weeks later (Learn & Lunch or peer-to-peer case consultation) in which participants share their experiences and receive input from the others as well as from us as trainers or coaches.
In summary, it sounds like I should tackle the agile methods first.
They can definitely uncover and overcome discrepancies between individual and agile mindsets. At this point, I'd like to reiterate my initial statement: "One leads to the other." Without an agile mindset, agile working will be nowhere near able to realize all of its full benefits. Important for the question "What comes first?" are my goals and, with them, the actual-target discrepancy and the resource allocation I'm willing to accept. It's similar to hiking: Several paths lead to the summit, and I have to decide for myself where to start, how long it will take, and how much I want to sweat.
And on this hike, companies sometimes need a mountain guide…
Exactly! At KI.M, for example, we support this change process holistically – from implementation and the necessary diagnostics to staff development. Often, this change process also creates support needs that are directly related to agile working – for example, team development or training on self-organization and resilience. When using support measures, I think it's important that the participants themselves decide to participate and register, so that the agile pull principle is directly implemented here as well, and the change and training process doesn't counteract agile working.
We could probably talk about agility for hours at this point. Thank you in advance for sharing your perspective on the question "Which came first—agile mindset or agile methods?" Zita!
With pleasure! My colleagues and I welcome all customers who join us on this journey. After all, agile working is now established enough to learn from the successes and failures of others – so we're happy to share our experience here.
[:]
English 
German 