Agility prevails. Countless articles are written and published on this topic. On Google you can find 144 million results for the keyword ‘Agile’.
This approach replaces many classic waterfall models, especially in software development. And it encompasses other areas of development as well as the entire company.
Accordingly, most companies and organizations are concerned with agility in one form or another.
However, such a transition is neither easy nor self-evident.
Agility as a necessity
For me, agility is not just hype, but a logical response to developments in the world in which we live.
The approach of agility in software development has also been in place for more than twenty years.
But the world is turning faster and faster, progress is advancing, development cycles are getting shorter and shorter, new technologies become obsolete within a very short time and have to be replaced by new, innovative concepts.
This modern world of today is also referred to and described as the VUCA world (volatile, uncertain, complex, ambiguous) or BANI world (brittle, anxious, non-linear, incomprehensible).
Additional drastic events such as the corona pandemic are changing the world and the behavior of customers even faster and more intensively.
Within weeks and months home office and video conferencing are suddenly used actively and widely, electronic shopping and cashless payment becomes as a standard, and the digitalization of the healthcare system awakened from its slumber.
However, companies also become more aware of the dependency of products, developments and productions on China, India, the USA and other distant countries and political systems and now see not only the advantages and opportunities but also the disadvantages and risks of outsourcing, just-in-time productions and longer, non-transparent supply chains, to name just a few.
The corona pandemic may be an exception, which accelerated changes massively and almost explosively.
But there are also countless other examples of crises and new challenges that require change.
Change is life - life is change - and that faster and faster.
And the greatest challenge with an immense impact on the environment, society and the economy is the environmental and climate crisis, which has only just begun and will probably occupy the next generations.
These are just a few examples that show how important it is for a company and, above all, its development departments to adapt quickly and effectively to the changing framework and market conditions.
Certain external influencing factors can be influenced, but most of them can neither be planned nor controlled, but must be recognized in good time and correctly and appropriately responded to.
This is part of the business and shouldn't be viewed as just negative. In addition to risks, such changes always offer numerous, sometimes unexpected, opportunities.
The pharmaceutical industry, which was able to respond to the new virus within a very short period of time with new diagnostic instruments, vaccinations and drugs, certainly serves as a good example in the corona crisis.
So the question does not arise whether an agile approach in development and organization is good or bad, but only how it is implemented in your organization as effectively and sensibly as possible?
Peculiarity of agility
The term agility is sometimes very overused.
As soon as a project or plan has an iterative approach, it is touted as agile.
In many places there is a lack of the necessary knowledge and experience to a) use agility effectively and b) make an existing organization more agile.
The aim of agility is to increase flexibility in order to be proactive, anticipatory and proactive. It also increases the ability of an organization to adapt quickly and effectively to changing situations.
Agility is based on the principles and values of the Manifesto for Agile Software Development. It is not just an agile approach, it is much more based on an agile mindset.
However, it is (unfortunately) not a cure-all, it fits primarily into development and less into production or service provision.
Or do you want to build a house, a street, a vehicle with an agile approach or use an agile approach to treat your toothache?
Operations or a rollout project can also be less agile within IT but still implement agile elements such as DevOps.
Thus, with the agile approach, what and how it should become more agile and to what extent must always be clearly delineated.
For me it is crucial not to see agility in isolation, but as part of the whole.
It is an important, fundamental, but not a stand-alone component in the organization.
It is used in numerous other concepts and methods (e.g. teal organization), but is itself based on various theories (social systems, chaos theory, constructivism, etc.).
Here, too, application and implementation apply with a sense of proportion. Other concepts can and may well be left standing, integrated or newly implemented.
Transition comes to a standstill
This starting point is clear and the need for agility will soon have arrived in every company. Numerous projects have been started to adapt the classic structures and procedures to an agile organization.
I observed two fundamentally different approaches.
Either a project or the architecture department develops a tailor-made agile concept and tries to impose it on the entire organization, or the organization starts with a pilot project of two or three teams and hopes that it will then work itself out in the organization spread.
For this purpose, extensive agile concepts are usually developed, which are initially introduced and implemented with a lot of euphoria and then stall or even peter out.
The reasons for the lack of success are complex. In addition to the generally applicable explanations, in my opinion the following problem areas can also include:
- There is no common vision that shows management and employees what the agile organization should ideally look like in the future.
This vision does not have to be perfect, but it has to be tailored to the company and organization, understandable and relevant and meaningful to the employees.
Numerous questions need to be answered?
- How does the model look like?
- How should work be done in the future?
- What are the competencies and responsibilities?
- How are services provided and how are existing and new customer needs dealt with?
- Is still being conducted and if so, how?
- How does the cooperation with other teams look like, especially with teams that are further or less in the transition?
- Should all organizations become agile or are there those that continue to be run in the traditional way (e.g. operation, infrastructure, support, SAP)?
- How does communication work in the organization? How does information flow?
- How is knowledge shared? How is innovation promoted?
- Who can I contact for any questions
- What is missing is a clear strategy that shows the steps towards this vision. It is not enough to set up a project and then see how it goes on.
- The transition from a classic to an agile organization is a cultural change and also affects the values of the organization.
A cultural change takes time, on the order of five years and cannot be pushed through by management within three months.
- The scope of the transition is not meaningful or adequate. Sometimes there is an attempt to bring everything under one roof, which leads to problems.
- Agility in software development is not just SCRUM, it also requires an agile mindset, which is neglected.
- The transition from a classic to an agile organization is a (massive) change.
It runs analogously to the change axis, creates resistance and fears, and must be accompanied by a change process (Organizational Change Management OCM).
The most important instrument of OCM is communication.
- Missing management attention. Such a transition affects the core of the organization and is therefore an absolute management task, initially and for as long as this management exists. It cannot be delegated to subordinates or to a project.
- The involvement of affected employees are too little and too late. This contradicts the concept of self-organization.
It is also very effective and efficient when employees are actively involved in the process at an early stage.
- Agile teams have not enough competences and responsibility. At a certain point in time, the affected team has take over the responsibility over the process itself (self-organization, self-control).
This also means that management has to give up more and more responsibility, which is often difficult for individual managers.
- Transition without a transition project. It is highly recommended to set up a transition project in order to accompany, care, support, control and continuously improve the process.
Like every project, by definition such a project is limited in time and should then hand over its tasks to the responsible organizations.
The project is to be led by management and supported and accompanied by a lean agile and OCM specialist team.
- A project management method from software development is for a transition project not suitable. The project management method to be used should control the change process and can itself contain agile elements.
- From my point of view, the agile concepts of the organization are often too complicated and too detailed. Keep it simple. Principles, foundations and framework conditions are important.
I also find it contradicting to implement a detailed concept with uniform work instructions for the entire organization if agile organizations are to be self-organized.
The teams should determine for themselves how they best do their work and perform.
Furthermore, instead of a fixed procedure, a concept should rather offer options for application where the agile teams can make use of. I see more of a modular approach with a self-service shop.
How to continue?
If you are now in such a transition project yourself and it does not develop as you would like, then of course you ask yourself the question of how next?
If you have already started, my recommendation is not to stop the project, but instead use the momentum.
Start simple, don't make it too complicated, and give yourself the time.
In the spirit of agile, I would now continuously improve the approach and support the project better:
- Start with the vision (see above). Is it clear where the journey is going? Do everyone understand this vision? Have the principles of agility arrived?
Every employee in the organization needs to know and understand this vision. Management itself must also have a perspective.
This is the only way that employees and management can support and live the approach.
Even if it costs a little more, there are innovative technical possibilities here to tell this story in an engaging way.
It doesn't always have to be PowerPoint.
- Work on the agile mindset. Do training and communication. Work with examples. Only if it is really understood and lived by every employee do agile concepts have a chance.
- Maybe it helps to use an overarching model. A possible concept for a service-oriented organization could be VeriSM .
For software development, the Scaled Agile Framework SAFE is worth looking at.
- If you use a framework like SCRUM or something similar, use it completely and correctly. Only then will you achieve the benefits announced and hoped for.
- Try to be specific but avoid setting anything in stone. "We're becoming agile" is not enough.
- Improve the strategy on how to get to this agile organization.
- Accompany and actively support your employees and your managers. They are your most important asset.
- Improve the transition project with a small, powerful team. Get specialists with extensive experience, including from the agile and OCM areas.
- Get committed employees on board as ambassadors, ideally very different personalities, of all ages, female and male, from different areas, in order to address as many interest groups as possible and bring diversity to the project.
- Try to become agile in the transition project. In this way you can already use the advantages, become more sensitive to future challenges and provide a good example for the organization.