Agile organisation: when does agile working make sense?

Agility is a company's ability to recognise changing external and internal influences early and adapt to them. Two conditions must be met: the organisation accepts and copes with change, and it uses it to its own advantage. This does not mean that it has to change itself with every change. A structure that changes constantly is not an organisation. What is sought is a structure that allows situational adjustments without neglecting the core business.

The understanding common today comes from project work in software development. Classic project work treats change as a risk to be managed and avoided wherever possible. Agile project work accepts change as an integral part of the project and sees it as an opportunity. The yardstick for the result differs accordingly. In the classic approach, what counts is how far the initially defined specification was implemented. In the agile approach, what counts is the usefulness of the finished product for the customer.

A shared assignment and clear priorities provide orientation. Nevertheless, it may be open which specific solution is suitable and how it should be developed. In this situation, short learning loops create the opportunity to test assumptions. If requirements and approach are already well known, standardised processes may be appropriate for the task.

In classic working, requirements and approach are known. Change requests create unplanned effort, the customer is little involved, and clearly defined processes allow efficient handling. Hierarchies are clear, communication and decisions are governed in a standardised way. In agile working, the requirements are not clearly defined, and the approach is worked out step by step. Changes are planned in, and the customer is closely involved. Teams organise themselves with a high degree of personal responsibility and decide through short, informal coordination.

Agility means openness about the path, not openness about the goal. The why and the what are clear and shared. Only the how is not fully determined in advance. Without goals, priorities and guard rails, agile working does not become flexible but arbitrary. For the organisation as a whole, therefore, it is not a question of either-or. The choice is made for each situation.

At the centre is a feedback loop of build, measure and learn. An early product must be functional enough for customers to actually try it out. Their reactions provide information for the next decision. A concept that is merely presented can yield different insights from real use. The form of test must therefore fit the assumption being examined.

The minimum viable product is the first minimally functional version of a product. It is more than a prototype because it already contains the most important functions. It is often misunderstood. Developers then add functions bit by bit until the product is complete. They test only internally, rarely make changes and, when they do, make them on a large scale. Essentially, they are preparing a major market launch and putting all their resources on one card.

Methods and techniques require corresponding competences. These in turn must be supported by forms of organisation, leadership structures and decision routines. Culture shapes how uncertainty and new information are dealt with. A team needs, for example, a task it can work on and a framework in which it is allowed to draw consequences from feedback.

Self-organisation requires clarity about responsibility and coordination. Overarching questions about markets, resources and the interplay with the core business remain. In the transformis understanding, adaptability therefore also shows in building, changing or dissolving suitable structures as the situation requires. Choosing a framework is one part of this work.

In ambidexterity and agility, three levels can be distinguished: organisation, competences, and methods and techniques. Culture forms their common foundation. Leadership structures and communication and decision routines must enable the chosen working style. Knowledge, attitude and skills as well as methods such as Scrum or design thinking build on this.

Agile ways of working have proved themselves above all in start-ups that have grown up with them. In companies with structures that have developed over generations, an unaccompanied introduction rarely leads to success. Often the methods have no effect, create additional work and weaken willingness to change. Poorly integrated agile ways of working can even destabilise an organisation and block decision-making processes.

One reason is the scope of the frameworks. Scrum focuses on a single product and the associated team. It does not cover developments in the company's environment, people management or budget planning. Scaling approaches such as LeSS or SAFe go somewhat further, but mainly govern the work of several teams on one product. Moreover, self-organisation cannot be extended to the entire organisation. Deliberate engagement with the relevant environments remains a task for leadership. Agile frameworks do not dissolve it.

Faster coordination alone does not create a better organisation. For a specific task, it is examined how uncertain the requirements are, which decisions a team can make itself and where it depends on other units. An iterative approach can make sense if a solution has to be learned through feedback and testing. Other forms may be needed for stable, regulated or highly interdependent processes.

Leadership must clarify mandate, resources and interfaces so that a team does not merely get new names for meetings. A trial should show on an actual work task whether responsiveness, quality and cooperation improve. No general promise of success for the entire organisation can be derived from a single pilot project.