The hype is over, but agility isn’t

There is significantly less talk of agility today than there was a few years ago. Instead, topics such as artificial intelligence, automation and new technological possibilities are shaping many discussions about the future of work. One could almost get the impression that agility is a thing of the past.

However, public attention and professional relevance are not the same thing. Organisations must continue to identify changes early on, make decisions in the face of uncertainty, process feedback and adapt their actions. These challenges have not gone away. In many areas, they are actually increasing.

So perhaps it is not agility that has disappeared, but rather the hype surrounding it. After years of frameworks, certifications, transformation programmes and grand promises, the debate has quietened down. This may be sobering, but it also presents an opportunity to distinguish helpful core principles from exaggerated expectations and mere labels.

The hype is over, but agility is not. That is precisely why it is worth taking a fresh look at the questions it originally set out to answer: How do organisations recognise that something needs to change? How do they learn from feedback? And who is actually authorised to act on new insights? Technological acceleration, in particular, does not replace these questions. It makes them all the more urgent.

The terminology changes, but the questions remain

If agility has not, in fact, disappeared, the question arises as to how this can be recognised. An answer is to be found not so much in the latest buzzwords as in the challenges that organisations continue to face.

Companies must respond to changing customer needs, make sense of new technologies and take decisions, even though developments cannot be reliably predicted. Strategies sometimes become obsolete more quickly, knowledge becomes outdated, and best practices do not automatically guarantee the desired outcome tomorrow. Organisations must therefore continually reassess whether their assumptions still hold true and whether their actions continue to achieve the intended effect.

The challenges that agility sought to address have therefore by no means disappeared. They are simply often discussed under different headings today. Organisations talk about adaptability, resilience, modern leadership, product focus, self-organisation or continuous improvement. Underlying this is still the aim to learn more quickly, to recognise the actual value of an idea at an early stage, to link decisions to existing knowledge, and to remain capable of taking action even when familiar solutions are no longer sufficient.

This is evident, for example, in the use of artificial intelligence. A company can make new tools available to its staff within a short space of time. However, whether this results in any actual benefit is only determined once the tools are put into practice. Which tasks are suitable? Where do errors or new risks arise? Which results need to be reviewed? And who decides whether an approach that initially seems promising should be pursued further, modified or discarded? The technology provides new possibilities, but no ready-made answers.

Perhaps the reduced visibility of ‘agility’ is therefore also a sign that the discussion is moving away from the eye-catching label. Short learning cycles, regular feedback, interdisciplinary collaboration and incremental adjustments are now part of day-to-day work in many organisations. These practices are not referred to as ‘agile’ everywhere. Nor do they need to be.

The terminology is changing, but the organisational challenges remain. The fact that agility has nevertheless lost much of its former appeal is not solely down to the hype having died down. It is also due to what became of it during that hype.

What should remain and what can be discarded

The fact that other issues are now taking centre stage explains only part of the disillusionment surrounding agility. The agile movement itself bears a significant share of the blame. As attention grew, so did expectations, and in many places, helpful core principles gave rise to a sweeping promise: organisations should become faster, more innovative, more customer-focused and, at the same time, more efficient. Agility appeared to be the answer to almost every challenge.

The bigger this promise became, the easier it was to lose sight of the fact that agility does not provide a ready-made solution. It neither makes strategic decisions for organisations nor does it eliminate conflicting objectives, interdependencies or power issues. Nor does it guarantee better products. Agile working practices can help to make uncertainty visible, enable earlier learning and allow organisations to adapt their approach. Whether this leads to better results, however, depends on what organisations do with these insights.

The consequences of the hype

During the hype, agility was often equated with specific frameworks, roles and terminology. Anyone who introduced Scrum, held daily scrums and maintained backlogs could get the impression that they were already working in an agile way. Visible practices were relatively easy to adopt. It was more difficult to change decision-making processes, responsibilities and the relationship between leadership and teams.

This gave rise to an attractive misconception: agility seemed to be something that could be introduced without fundamentally questioning the organisation. New roles were created, training courses were offered and certificates were obtained. However, existing structures often remained untouched. Teams were expected to organise themselves, but still had to escalate key decisions to senior management. They were expected to take responsibility, yet were given little say in setting goals, priorities or framework conditions.

Expectations regarding transformation also grew. What had been a gradual change became a programme with a vision, a timetable and success stories. Organisations no longer simply wanted to work more agilely; they wanted to become as fully agile as possible. Consequently, what had been a capability that had to prove itself in dealing with specific challenges became a state that could be achieved and proclaimed.

This development fuelled a business based on simple answers. Frameworks provided guidance, certifications validated knowledge, and maturity levels promised comparability. All of this can be useful. It becomes problematic, however, when mastering a method is confused with the ability to act effectively in the face of uncertainty. A certificate says little about whether a person will listen in a difficult situation, challenge assumptions or delegate responsibility sensibly. The mere introduction of a framework does not prove that an organisation actually learns from feedback.

The hype has both popularised and narrowed the scope of agility. It has exposed many people to helpful ideas. At the same time, it has created the impression that agility can be bought, rolled out and demonstrated through visible practices. Where the hoped-for results failed to materialise, the resulting disappointment was subsequently directed against agility as a whole.

What can be discarded under the label

Not everything that has emerged in the name of agility deserves to be preserved. This includes, first and foremost, the notion that certain rituals are in themselves proof of adaptability. A daily scrum does not make a team capable of learning if problems are identified daily but never resolved. A review does not generate customer value if feedback is ignored. A retrospective does not improve collaboration if those involved agree on actions but are given no opportunity to implement them.

Roles, too, must not become an end in themselves. Product Owners, Scrum Masters or Agile Coaches can make important contributions. However, their value does not stem from the title, but from their impact. A role whose purpose no one can explain any longer should not be retained simply because it is provided for in a framework.

So-called ‘pseudo-autonomy’ must also be eliminated. Delegating responsibility to teams without giving them the necessary information, authority or resources is not self-organisation. It merely shifts the pressure. Those involved are expected to take responsibility for results, but cannot influence the conditions that are crucial to achieving them. Under the banner of agility, this does not lead to greater capacity for action, but rather to additional strain.

Meeting inflation is not, either, a sign of agile collaboration. Transparency and exchange are important, but every additional meeting format requires time and attention. When meetings take place primarily because they are scheduled, they lose their connection to the actual work. A helpful structure then becomes an additional form of bureaucracy.

Finally, we must move away from the notion that a single way of working must be suitable for every situation. Not every task is equally uncertain, complex or subject to change. Some things lend themselves well to advance planning, standardisation and reliable repetition. Agility is not demonstrated by applying the same practices everywhere, but by adapting the approach to the task at hand.

What should therefore remain are not all the roles, rituals and terms that emerged during the hype. What is worth preserving is the underlying principle of learning early on, distributing responsibility sensibly and translating new insights into changed behaviour. Frameworks can help with this, but they can neither replace nor guarantee this ability.

When agility breaks free from exaggerated promises and superficial facades, it does not leave behind an empty concept. On the contrary: only then does its true substance become apparent.

Agility exists beyond frameworks

If agility is not tied to specific roles, terms or rituals, we need a different answer to the question of what defines it. One possible working definition is:

Agility refers to an organisation’s ability to recognise changes at an early stage, learn from them and consistently adapt its actions accordingly.

This definition does not describe a state that an organisation reaches at some point and then maintains permanently. It describes a capability that must be proven time and again through concrete action. What matters is not whether an organisation describes itself as agile, but how it deals with new information, unexpected developments and conflicting requirements.

In this context, two questions can be distinguished:

• How does an organisation know that it should make a change?
• And who is actually authorised to act on this realisation?

Insights do not arise of their own accord

Organisations act on the basis of assumptions. They develop products in the expectation that these will solve a specific problem. They design processes in the hope that this will make collaboration easier or performance more reliable. They make strategic decisions based on a vision of how markets, technologies and needs will develop.

Such assumptions are necessary. They only become problematic when they are treated as certainties. True agility is therefore first and foremost demonstrated by making assumptions verifiable at an early stage. Instead of spending a long time working on a supposedly complete solution, organisations create opportunities to obtain feedback as early as possible. They observe how customers actually use a product or service, assess the impact of a change and compare their expectations with what happens in practice.

Customers are an important source of insights. Their behaviour, their feedback and even their rejection help to test assumptions. Customer focus therefore does not mean immediately implementing every wish that is expressed. What is crucial is to better understand which problem actually needs to be solved and whether the chosen approach contributes to this.

Mistakes and deviations also provide insights. They reveal where assumptions do not hold true, where information is lacking, or where conditions have a different effect than expected. An organisation capable of learning therefore does not attempt to avoid every deviation. It creates a framework in which problems become apparent at an early stage and can be assessed before their consequences become more serious.

However, feedback alone does not make an organisation agile. Reviews, key performance indicators, customer surveys or retrospectives can generate a wealth of insights. As long as these do not lead to change, they remain ineffective. The ability to learn is not demonstrated by how much an organisation knows, but by whether it is willing and able to adapt its actions on the basis of this knowledge.

Insights require scope for action

For new insights to take effect, decisions must be made – or at least influenced – where the necessary knowledge is available. People who work with a product, a process or with customers on a daily basis often identify problems at an early stage. This knowledge is of little use if every response has to go through lengthy approval processes or if fundamental decisions have already been taken elsewhere.

True agility therefore combines responsibility with scope for action. Teams expected to take responsibility for results need access to relevant information, clear decision-making scope and the ability to adjust priorities or approaches. Responsibility without authority does not foster self-organisation. It results in people being expected to take responsibility for outcomes over which they have little influence.

This does not mean that every team should make decisions independently or set all the framework conditions themselves. Organisations need shared goals, strategic direction and clear boundaries. It is precisely this clarity that can enable decentralised decision-making. When teams know what outcome is being sought and what conditions must be met, they can act autonomously within this framework.

Nor does this mean that planning loses its value. Plans provide direction, coordinate dependencies and make expectations clear. Agility does not require us to abandon planning. It requires the freedom to change a plan when new insights show that it no longer leads to the desired outcome. Anyone who sticks to a decision even though its assumptions have been disproved is not acting consistently, but is ignoring available knowledge.

Frameworks can support organisations in this regard. They provide structures for collaboration, transparency and regular feedback. However, their usefulness depends on whether they are suited to the situation at hand and actually help with learning and decision-making. Frameworks should serve the work; the work should not serve the framework.

Scrum without agility, agility without Scrum

A team can use Scrum, fill all the designated roles and reliably meet its deadlines. During reviews, the team regularly receives indications that key assumptions are incorrect. Nevertheless, the original scope remains unchanged because priorities have already been decided and deviations are regarded as a lack of reliability. The team is using an agile framework. However, its ability to draw conclusions from insights remains limited.

Another team works without Scrum. It releases a simple version of its product early on, monitors its usage and talks regularly with customers. Insights inform subsequent decisions. The team discards ideas if they do not provide any discernible benefit and adjusts its planning as soon as new information suggests this is sensible. The label is missing, but the agility is not.

This comparison is neither an argument against Scrum nor in favour of working without clear structures. It merely shows that a framework and the ability to adapt are not the same thing. Scrum can support agility. However, it cannot guarantee it any more than doing without Scrum automatically leads to better collaboration.

Agility thrives where organisations recognise relevant changes, make their assumptions testable and translate the insights gained into decisions. To do this, they need both the ability to learn and the freedom to act. If the first prerequisite is missing, an organisation remains blind to necessary changes. If the second is missing, it may recognise the need for action but is unable to respond to it.

This distinction helps us to assess working methods more accurately, without judging them solely on the basis of roles, terminology or frameworks. Yet there is a danger here too: a helpful guide can quickly turn into a new claim to superiority.

Figure: Where lived agility becomes recognisable

Agile arrogance hinders collaboration

It rears its head when a helpful distinction between working methods turns into a judgement on people. Those who see themselves as ‘agile’ are quick to regard others as backward, inflexible or unwilling to learn. A professional stance then gives rise to a sense of superiority.

This attitude is particularly problematic because it contradicts what agility is actually meant to promote. Anyone who wants to learn must be prepared to question their own perspective. Anyone seeking to improve collaboration should take others’ experiences seriously, even if they do not fit into their own model. And anyone making decisions under uncertainty cannot at the same time pretend that they already know the only correct course of action.

Agile arrogance does not only manifest itself in overt disparagement. It can also manifest itself subtly: in terminology that excludes others, in the assumption that resistance is merely a sign of a lack of understanding, or in the notion that people simply need to be convinced of the correct way of working. Criticism of agile practices is then not seen as a possible indication of real problems, but as evidence that the person voicing the criticism has not yet progressed far enough.

On the other hand, such an attitude can foster feelings of inferiority. Those confronted with new terminology, roles and methods may begin to doubt their own experience or consider themselves less up to date. An experienced manager may then start to withhold their knowledge because their perspective is supposedly no longer compatible with the new working world. A specialist may not voice any concerns, even though they recognise the risks, because they do not want to be seen as a hindrance. As a result, an organisation loses precisely the experience it needs to make sound decisions.

This creates a dangerous imbalance: some act with methodological confidence, whilst others withdraw despite their valuable experience. Collaboration then no longer takes place on an equal footing. Instead of combining different areas of expertise, one is valued highly whilst the other is devalued.

This problem is particularly evident at the interface between subject matter expertise and methodological knowledge. People who are proficient in a framework do not automatically know more about a product, a market or a specific work context. Conversely, people with many years’ experience are not automatically inflexible simply because they view new methods critically. Both forms of knowledge can make valuable contributions, provided they are not pitted against one another.

Criticism therefore deserves attention from the outset. Someone who rejects a new approach may be defending the status quo or seeking to avoid change on principle. However, that person may just as easily be pointing out interdependencies, risks or experiences that have been overlooked in the analysis so far. An organisation capable of learning seeks to understand this distinction, rather than hastily dismissing every objection as resistance.

This does not mean considering every working method to be equally good or every criticism to be justified. Organisations are entitled to evaluate practices, make decisions and modify unsuitable approaches. What is crucial is whether they distinguish between assessing a working method and disparaging the people involved. A method may be of little help in a particular situation without its advocates being backward-looking. An agile practice can be sensible without its application conferring moral or professional superiority.

Nor, therefore, should the working definition developed in the previous chapter become a new seal of approval. It is intended to help us look more closely: Are assumptions being tested? Do findings lead to changes? Do responsibility and scope for action align? These questions open up a discussion; they do not end it.

Agility in practice is therefore also evident in how we deal with dissent. It does not require a division between the progressive and the backward-looking, but rather a form of collaboration in which different experiences are made visible and remain open to scrutiny. Anyone who understands agility as an invitation to learn must begin by treating their own convictions as assumptions.

This willingness becomes all the more important the faster new technologies and ways of working find their way into organisations. The current approach to artificial intelligence, in particular, shows how easily enthusiasm, feeling overwhelmed and new claims of superiority can arise side by side.

Artificial intelligence does not render agility obsolete

Artificial intelligence is currently at the heart of many discussions about work, productivity and the future of organisations. New tools are emerging in rapid succession; tasks can be automated and information generated more quickly. This can easily give the impression that technological capability is becoming the decisive prerequisite for adaptability.

However, the availability of new tools does not in itself answer the question of how organisations should make sensible use of them. They must recognise which applications actually deliver benefits, what risks arise and which tasks are best left to humans. They must be able to assess results, evaluate experiences and adapt their approach if expectations are not met. It is precisely here that the skills central to agility are once again evident.

The use of artificial intelligence often begins with assumptions. A company may, for example, expect a new tool to speed up processes, improve quality or reduce the workload on staff. However, it is rarely possible to fully assess in advance whether these expectations will be met. Only through actual use does it become clear where a system is helpful, what errors occur and what new dependencies arise.

That is why it is not enough simply to introduce artificial intelligence as quickly as possible. Organisations need opportunities to gain experience, review results and learn from mistakes. Small, clearly defined use cases can be more helpful in this regard than comprehensive programmes with grand promises. They reveal early on where actual benefits arise and where technical capabilities have been overestimated.

Here, too, insight alone is not enough. Staff may quickly realise that a tool delivers unreliable results, creates additional monitoring work or is unsuitable for a particular task. If they are nevertheless not allowed to change the approach, this knowledge remains ineffective. The ability to learn also requires room for manoeuvre when using artificial intelligence.

This once again raises the question of responsibility. Organisations must determine which results are to be reviewed, who takes responsibility for erroneous or problematic suggestions, and under what conditions an application may be modified, restricted or discontinued. Such decisions cannot be delegated to the technology. Organisations must themselves determine how they deal with uncertainty, quality and potential consequences.

Artificial intelligence can further exacerbate existing imbalances. People with a high level of technical confidence may project a new sense of superiority, whilst others may hold back on sharing their experience because they feel less familiar with the new tools. Yet technical knowledge is only one perspective. Professional experience, contextual knowledge, judgement and an understanding of the implications for customers and staff remain just as important.

This is precisely why the use of artificial intelligence requires collaboration that brings together different areas of expertise. Technical possibilities must be linked to professional requirements, organisational conditions and responsible decision-making. Those who merely ask what is technically possible are missing the point. Nor is it sufficient to reject new tools out of a fundamental scepticism.

Agility does not provide a ready-made answer to this. However, it does offer a helpful approach: making assumptions explicit, gaining experience at an early stage, taking feedback seriously and adapting decisions in line with new insights. The faster technological possibilities change, the more important this ability becomes.

Artificial intelligence therefore does not replace agility. Rather, it highlights why organisations must continue to learn, clarify responsibilities and adapt their actions. The tools are new. The fundamental challenges are not.

Agility thrives when organisations learn

Agility loses its value when it is confined to terms, roles or visible practices. Its significance only becomes apparent when organisations are prepared to challenge assumptions, learn from feedback and actually change the way they operate.

It is not enough simply to demand a capacity for learning. Organisations must enable it. People need access to relevant information, opportunities for early feedback and the necessary scope for action to draw conclusions from new insights. Those who delegate responsibility without enabling decision-making do not foster agility. Those who highlight mistakes but penalise every deviation do not promote learning. And those who seek feedback without opening up the next steps for discussion are merely clinging to a ritual.

Agility does not require a specific method or a one-size-fits-all answer to every situation. Nor does it require a blanket rejection of planning, experience or tried-and-tested structures. What matters is whether an approach is suited to the task at hand and can be adapted when new insights suggest it should be.

This requires a collaborative approach in which different perspectives are not categorised as ‘modern’ or ‘outdated’. Methodological knowledge, specialist expertise and experience must complement one another. Criticism must neither be automatically regarded as resistance nor accepted uncritically. It must be treated as a potential contribution to learning.

This ability remains central, particularly at a time when new technologies are raising high expectations and accelerating change. Organisations do not become adaptable simply by using modern tools. They become so when they monitor the impact of these tools, clarify responsibilities and are prepared to adjust their decisions.

Public attention has shifted, and exaggerated promises have damaged trust in agility. Nevertheless, the organisational challenges associated with it persist. Organisations must recognise when their previous assumptions no longer hold water, translate insights into decisions, and create conditions under which people can act collectively even without ready-made answers.

Agility is embodied in the way organisations deal with these challenges. Not as a state they have achieved. Not as a label they apply to themselves. And not as a framework that guarantees their adaptability.

The hype is over, but agility is not.

Notes (some in German):

The idea for this post stems from two posts and a guest post on the t2informatik blog:

Stefan Roock: Der Begriff “agil” ist vielerorts verbrannt und das war unvermeidbar.
Jurgen Appelo: Agile Is Not Dying; It’s Dissolving.
Oliver Fels: Do you believe in agility?

Here you’ll find a series of posts by Heiko Bartlog that’s well worth reading: Agility? We tried it! Does not work!

And here you’ll find some further information on:

How does Scrum work?
How can you focus on the Sprint Goal during the Daily Scrum?
What types of Retrospectives are there?
What tips can help with the Sprint Review?
And what are the phases of the hype cycle?

Would you like to support Michael Schenkel or discuss agility in organisations? Then share this post on social media or within your organisation.

Michael Schenkel has published more posts on the t2informatik blog, including: