The best form of collaboration takes place in agile teams – something many companies are convinced of. The concept of agility is sometimes used to describe an attitude, sometimes the agile methods that are helpful for work. It is useful to know what you are talking about – not least to assess what you want.
Whenever new ways of working are introduced in companies, they are – if there is any doubt – referred to as agile. In the meantime, many agility-related buzzwords have emerged whose meaning is often not clearly defined. It is easy to get lost between the meaning of flat hierarchies and decentralized organizations, grassroots movements and Scrum™ teams, or holocratic models and self-organization.
It is generally believed that the driving force behind the use of agile methods is the increasingly complex world of work. This is primarily due to digitalization and the associated shorter innovation cycles for products. As a result, markets are changing rapidly. This, in turn, leads to changes in customer requirements at even shorter notice. One term for this faster change process is VUCA (volatility, uncertainty, complexity, ambiguity) – even though the acronym is neither new nor offers helpful options for action.
Agile methods should help overcome new challenges
Companies that use agile methods are hoping, above all, for greater adaptability to an increasingly complex world. They want to present results to customers faster and respond to changes in product requirements at short notice.
At an employee level, companies are hoping to promote an agile mindset. This includes, in particular, appreciative interaction between employees at eye level. Additionally, agile forms of work can be used to address employees’ demands that are also changing (e.g. for flexible working models, meaningful work, etc.). In very simplified terms, one could say that agile teams should work together better, more efficiently, and more happily.
Why the use of agile methods is popular
So it’s hardly surprising that in times of digital change and information overload agile methods are highly praised. For management and business consultants, it is quite customary to call for agility – not least because the introduction of agile process structures has opened up an extremely lucrative business field for consultants and coaches.
Agile structures are praised because they offer a means of dealing with complexity. They are supposed to promote creativity and the will to shape things, make processes faster and more efficient, and make interaction more appreciative and at eye level.
But what does agility actually mean?
Nevertheless, problems often arise during the introduction of agile processes. One challenge in their implementation is the interpretation of the term agility. Organizations use it in many different ways, with statements ranging from “doing away with hierarchy” to “we now work flexibly”. The mere fact that this term has been expanded into a fundamental principle of collaboration makes it non-specific. This, in turn, makes for different and sometimes contradictory definitions. A specific, agile form of collaboration cannot be transferred to an entire organization as a new guiding principle. What remains are abstract principles such as courage, focus, passion, or personal responsibility.
So regardless of the actual concept, the term’s lack of clarity creates a problem for companies and employees. If it is unclear what people are actually talking about, there can be no clarity on how agility is to be implemented in concrete terms.
Three basic principles of agile methods
At an informality level, agility is to be found in every organization – and has been for a long time. Grassroots movements serve as a prime example. As early as the 1960s, attempts were made to give this phenomenon a name. Terms such as “adhocracy”, “synthetic organization” or “horizontal system” were used. As a term, “agility” has been in circulation since 2001. The “agile manifesto” was intended to define guidelines for agile software development.
Here again, there is no precise definition. But in essence, it is about the ability to operate profitably in a competitive environment characterized by constant, unpredictable and changing customer demands. The agile methods that make this possible are generally based on three common features:
- Dissolution of strict boundaries between silos
- Reduction in hierarchical structures
- Iterative thinking in projects
Even though the significance of a regulated process and the testing of interim results are becoming more important, agile methods mainly help to achieve a results-oriented way of working. The goal of agile teams is to achieve predefined goals as fast as possible. An incremental approach allows short-term results to be delivered quickly, tested on the market, and then adjusted. Thus, it is possible to respond to market changes in good time. Such situational flexibility is lacking in classic, long-term waterfall projects.
Structured interaction – an important tool in agile methods
Despite all the advantages listed above, working in agile teams is not a panacea. Its use only makes sense if there are specific challenges you expect to overcome through agility. In some cases, project management by the classic waterfall method is still advisable. Series production is one such case. Here, customer requirements are clear from the start and employees have, in advance, a precise picture of their concrete tasks. The greater the number of unknown variables, the more likely it is that the use of agile methods will help in dealing with the situation in question.
Agile methods are mainly used to condense interaction in order to converse in a more structured manner and, ideally, to achieve results more quickly. The number of interactions grows and content also becomes comparable. The structure of conversations becomes a factor. For example, if the same key figures are discussed in every regular meeting, daily or weekly meetings moderated in a structured way or shop-floor boards can be used to achieve comparability. Such measures are easy to implement because not much changes for the participants and there is a clear and easily replicable structure.
The more uncertain the project, the more contact areas you need
This is particularly important if the product requirements are not yet clear, a change in the project scope is likely, or the market situation is changing quickly and the response has to be at least as fast. In short, the more unknown variables there are, the more likely it is that agile design elements will help in dealing with the respective situation.
What should be considered when introducing agile methods?
But how do you successfully switch to agile working methods? In order to decide on a suitable tool, it is advisable to break down agile models into their individual parts and extract the design elements that are useful for the respective team or individual project. It is important to ask yourself the right questions en route. You need to be aware of what specifically needs to change and what reference problem lies behind the pain.
Once you have answered this question, you can consider which agile method best fits the problem. For example, Scrum™, Kanban or design thinking – or elements thereof – are commonly used. Blindly adopting a method in its entirety from a textbook will not work. Rather, the key is to select individual elements that are useful in the individual context. In practice, this usually results in hybrid project models that combine the advantages of the different approaches. At the same time, pure cherry-picking and too wild a mix of methods should be avoided.
An iterative approach should be taken in implementing agile methods
It is a good idea to initially introduce the system in a small group. A team will then test out the new form of collaboration and compare it with the change that was originally hoped for. If the results are positive, entire departments can, if required, adopt the design principle. This iterative approach is especially important because every solution to a problem uncovers new problems. If you tackle these consequential problems in a small group, you will have a better chance of dealing with them.
Right from the start, you should flag the implementation as contingent. In doing so, you will have to reckon with resistance, since consequential problems can arise for the employees in question. Any resistance to implementation should be taken seriously. This is the only way to understand the rationales behind it and how they can be incorporated.
A danger: dismantling structures leads to disorientation
The boundaries between silos and departments will often be dismantled for agile ways of working. Interdisciplinary project teams or temporary groups will be formed. Everyone should be able to work with everyone else. However, the newly formed, results-oriented units will, in turn, develop their own identities through their project reference – identities that are not always compatible with the rest of the organization. Instead of an awareness of the whole, the awareness in the interdisciplinary teams will now be of their common intersections.
Dismantling hierarchical structures can also lead to consequential problems. Flat hierarchies or self-organization can mitigate information loss because there are fewer places in the organizational structure where the flow of information is filtered. At the same time, however, power struggles will intensify because the question of who is allowed to decide what and how and when has to be renegotiated each and every time.
To work properly agile methods need problems
Anyone who hopes to reduce the complexity of collaboration through agile teams will soon discover that complexity simply shifts to other areas and contexts of action. Purpose-related programs replace conditional programs. Employees are only given the goal of a specific task, but they determine how to get there themselves. Although this leads to more self-determination, it will often make collaboration more complex since new role clarifications are required in order to retain the capability to act.
In other words, you should be clear about which design elements you want to use and what the consequences of the respective implementation will be. Agile methods will prove helpful if there are concrete problems that can be solved by using them. Otherwise, working in agile teams is just painting-by-numbers and can quickly lead to new conflicts in a team.
