The Why, How and What of Agile Transformations

Agile can be compared to ﬁtness. It means being ﬁt enough as a team, department or organisation to be able to deal with all circumstances. Being able to react rapidly and nimbly when the situation demands it. And that is a very important skill in a time of digitalisation, disruption and rapid change. In this chapter, we explain the why, how and what of agile transformations, introduce a step-wise approach to undertake such transformations and discuss the most common pitfalls observed in practice.


Introduction
Agile is a mindset that embraces change, and is about delivering results quickly and learning from that. Agile working is about giving autonomy to people and teams, with clear room for decision-making and a great deal of self-organisation. Continuous improvement is paramount, as well as making gradual efforts to generate even higher customer value and surpass existing performance. Learning step by step and improving by doing. Delivering results and learning how to improve, together as a team. That is agile.
Agile works best in situations where a lot is changing and still being discovered. Ideas may have been formulated in advance, but a great deal still needs to be reflected upon, learned and changed. Making a plan in such a situation only makes limited sense, because things always turn out differently than expected. A clear goal is necessary, but how it is reached is largely left open. And even the goal can be regularly reviewed, since that, too, may well alter in our rapidly changing world. And the more agile you are, the easier it is to deal with change.
The starting point of this chapter is that above all agile is a broadly applicable mindset that will find its way into many different environments. And this isn't such a crazy idea. After all, society is rapidly accelerating as a result of digitalisation and new ways of working together. Agile helps you, in cooperation with others and in small, clear steps, to achieve objectives that can be adjusted at any time.
This makes agile particularly suitable for what we often call 'knowledge work': cooperation between people in which the work itself and the results are often volatile, uncertain and consist of information, data and the like. Knowledge work is non-physical and is therefore fundamentally faster than physical work. After all, you can send messages, documents and files to the other side of the world in digital form in seconds (and for free!). This acceleration makes hierarchies within organisations unsuitable for rapid operational decisions. The speed and dynamism of change are simply becoming too great to ask permission from the boss each time. As a result, operational decisions and choices are increasingly made at the operational level, usually in teams that are allowed to organise themselves.
Agile working is, as such, a response to a rapidly changing and complex world. And it turns out to be effective rather than a short-lived hype. Many organisations are actively engaged in increasing their agility-whether they are large or small, commercial or public, young or old, technical or administrative in nature. They all struggle with the dynamism of the outside world, and they all see many advantages in making their working methods more agile and nimble. How they do this will vary from one organisation to another. It depends on their situation, their customers and their people. But striving for faster results and more flexibility is a uniform change in almost any organisation.
The essence of agile working lies in the acceptance of the fact that, as far as the future is concerned, it is never exactly clear what you can achieve and when. The reality is that so much is changing that we cannot actually make agreements far in advance. An important personal threshold for achieving agile working is therefore daring to let go of the idea that a detailed plan is necessary in order to be successful in complex situations. Learning to trust that taking the first step is the most important, because it is only during that first step that you will discover what the best next step is. Work experimentally and step by step. Agile teams do not plan too far ahead, and they jointly deliver results at a gradual pace within short periods of time, with the aim in particular of learning from each step. Learning how to do things better, learning what customers really need and thus discovering together where the highest customer value lies.
The structure of this chapter is the following. In Sect. 2 of we present the key characteristics of agility: iterations, validation and step-wise improvement. In Sect. 3 we present the key dimensions along which to decide whether agile ways of working make sense, depending on the amount of unpredictability. Section 4 introduces the reasons why more and more organisations start to implement large-scale agile transformations. In Sect. 5 we introduce a step-wise approach to use when leading such a transformation. Finally, Sect. 6 presents the seven most common pitfalls observed in practice during agile transformation. We round off with a short conclusion in Sect. 7.

Agile Is About Short-Cyclic Working and Iterations
The essence of agile is easily explained by the difference between a submarine and a dolphin (Fig. 1). Project-based working is similar to a submarine: the boat is invisible and dives under water. It can stay there for a long time-just like a big project. Only towards the end do you become restless; as the deadline approaches, urgency and activity increases. A submarine comes up at the end with the result. For the first time. You then hope that everything is okay. That customers will be happy and that your result will prove valuable. Unfortunately, in practice things are different. The hope then often turns out to be deferred disappointment. And this makes sense, because this is when the very first feedback is received. You find out about everything that's not right at the same time. And unfortunately, you don't really have time to do anything about it anymore. After all, the project is over and the budget is spent. This submarine is sometimes also called the see-you-later model.
The alternative is the dolphin. A dolphin also dives under water. But a dolphin soon rises up to the surface again. This is because dolphins need air. With the dolphin approach you dive under water, but you quickly emerge with the first result. It is of course smaller than the total result you have in mind, but it is something you can test at least. You can test if it has value, test if it works and test if it does contribute to making the goal a reality. In this way you discover whether it delivers With this knowledge, the dolphin dives under water again and emerges a little later. A dolphin works with so-called iterations or sprints (repetitions)-always diving and surfacing again. Breathe, check if you're still going in the right direction or decide to make adjustments. And then quickly dive under the surface again and re-emerge. The dolphin approach is also called the see-you-soon model. Try to deliver results in everything you do as quickly as possible and ask for feedback. You'll see that you'll get results sooner and that you'll also get to know much sooner which parts of your original plan aren't needed at all. And that's how agile speeds things up. It's not about working harder, it's about working smarter. Discovering what you don't have to do because it has no value, saves a lot of time. And it gives you the opportunity to deliver earlier or to deliver additional value.
The two different approaches function in a totally different way: In short, working in long cycles versus working in short cycles. Agile working really is fundamentally different. In a dynamic and complex world where a great deal is changing and under discussion, it is smarter to work in short cycles. That works much better here. Agile working means swimming like a dolphin: always resurfacing and adjusting on the basis of concrete results and new insights.

When to Be Agile and When Not?
Agile is not a silver bullet. It is not the solution to all problems. Agile is suited to situations where there is a lot of uncertainty. Where a lot is still changing and a lot is still being discovered. These are also what we call complex situations. You know beforehand that many things will still change and afterwards you always know how it should have been done. It's about the degree of (un)certainty in this choice of whether agile will help or not. Agile helps in particular when work is complex and cannot be planned in advance. An alternative to agile is lean. Lean is especially helpful when the work is clearer. It may be complicated, but through repetition it is possible to master the work and make it plannable.
The best way to explain when agile makes sense and when it doesn't is to use the model created by Ralph Stacey (Fig. 2). This model describes the different situations that can arise when both the certainty about what is needed and when it can be achieved decreases. Whether or not agile working is a good choice is strongly dependent on this degree of (un)certainty: Simple situations include baking a cake, riding a bicycle or learning to swim, for example. There is a very clear relationship between the what and the how. If you follow a fixed number of steps, you will get the result you want. This is a known method, so there are best practices you can learn from an instructor. And then it works-all the time in fact. If you don't yet know how to deal with simple situations, find a trainer or instructor to teach you. • Complicated situations: These arise when the uncertainty around the what and how increases. It is fairly clear what is needed and how this can be achieved, but rock-hard guarantees are no longer possible. It is therefore worthwhile making a detailed analysis in advance of what exactly is needed. The more precisely something is thought out and specified, the greater the chance of success. Take choosing a technical platform, for example, or making a medical diagnosis or repairing a large machine. All these tasks may seem very difficult beforehand, but if well-trained people carry out a thorough analysis first, they will almost always succeed in achieving a good result. The success rate of the how can be increased by additional attention, training, the use of expertise, automation and/or standardisation. Complicated work is usually repetitive. You do it more often and get better at it. Optimisation with lean, therefore, is perfect in complicated environments. Experts and consultants who carry out analysis and propose a specific solution are therefore suited to complicated situations. Complicated work can be planned in advance, but needs expertise, analysis and preparation.
• Complex situations are those in which the what and how become a little more uncertain. The characteristic of a complex situation is that it always turns out differently to what you expected. There is more uncertainty than certainty beforehand. There are too many variables involved that are interdependent. Think, for example, of a large project involving many people and parties, the creation of new IT systems or the merger of two companies. You have an idea of what you want to achieve and how it could work, but things always go differently to how you thought they would. However, in complex situations you can always give a good explanation afterwards of why they went this way. And in retrospect you always know, with your current knowledge, how you should have tackled things. In a complex situation it is therefore best to discover in small steps exactly what is needed and how you can achieve this: experimenting, discovering, learning and making adjustments based on intermediate results.
Complex situations are therefore extremely suitable for agile. Daring to discover and getting a coach to help with this are suited to complex situations. Complex cannot be planned in advance, but can be explained afterwards. The answer to the question as to when to be agile and when not depends purely on the situation. Is it complicated or complex? Complex situations are not repeatable. Things always turn out differently. Then agile comes into its own. Agile helps you discover a route when you do things for the first time. Agile is applied in situations that are not repetitive, where only afterwards do you know how it should have been done and what is actually needed. Take small steps and thus make the learning process short cycle and repetitive.
If it is complicated and therefore repetitive, lean is more useful at first. Lean helps to optimise things you do more often and to learn from them. Lean is applied in situations that are repetitive in themselves-think of operational processes or production lines, especially in the manufacturing or service industries. The goal of lean and agile is basically the same: to be successful and to improve on the basis of experience.
However, our society is changing in such a way that more and more complex situations are arising. Everything is accelerating and also becoming increasingly digital. A lot of simple and complicated work is disappearing because it is being automated. And automating something is again complex. As a result, more and more environments are becoming complex and there is also increasingly complex work. This explains why agile is being used more often and more widely. Agile is capable of dealing with complexity, unpredictability and change.

Agile Transformations
Because of the growing dynamism in the market and the need for far-reaching agility, many organisations are rigorously transforming themselves into agile organisations. They are introducing agile, top-down and organisation-wide, as the standard working method. Such transformations are usually introduced on a large scale with very large budgets and a great deal of management attention. Besides a new way of working, also being introduced are reorganisations, new career paths, social plans, retraining programmes, etc. These are complex projects that take many months or even years to complete. They are also extremely radical and risky.
Most large organisations have a great deal of experience with radical change. It is carried out in a planned and controlled manner using best-practices, project plans, experienced programme managers, complicated presentations, Gantt charts, and much more. With an agile transformation, such a systematic approach doesn't work. This is because there is so much dynamism and uncertainty that a traditional plan very quickly becomes obsolete and needs to be adjusted very frequently and rigorously. In practice, with agile transformation such a plan is only useful in order to involve all the parties beforehand and to give them the feeling that their interests are being looked after. But you're quite sure that the transformation will not go according to plan.
What does work is: carrying out the agile transformation in small steps. This way, both controlled and agile changes are made. This means that an outline plan is drawn up, which is divided into small steps, with only the short term being worked out in detail. Each step produces concrete intermediate results, on the basis of which the plan can be adjusted again and again. This means that adjustments are made on the basis of concrete results and experiences.
However, this requires a great deal of knowledge and experience with agile on the part of those who lead the transformation. Line and programme managers generally have insufficient resources and are therefore unsuited to carrying out the transformation themselves. VersionOne's annual study (The 11th State of Agile Report, 2017) into the global application of agile in 2017 revealed the top 3 bottlenecks when it comes to agile transformation: 1. The current culture (63%) 2. A lack of experience with agile (47%) 3. The current management (45%) Points 1 and 2 are also the responsibility of the management and this research shows that the management is mainly the biggest bottleneck when it comes to agile transformation.
Large-scale, top-down agile transformations require an approach that is itself agile. This makes it possible to achieve results quickly and to adjust them on the basis of concrete results and changing needs. A plan can be used to do this, provided that it is set up iteratively. Such a step-by-step plan describes a rhythm on the way to the goal, with interim adjustments based on what does and does not work.
And that is actually the essence of successful agile transformation: learning by doing. After all, you learn more from doing things than you do from thinking about them.

Agile Transformation in Eight Steps
Although a repeatable recipe to agile transformation does not work because of the high degree of dynamism and changeability in this type of process, it is possible to carry out a transformation in a rhythmic and step-by-step manner.
The following step-by-step approach has already proven itself in practice many times. • Step 1-Perform an initial assessment. Each agile transformation is unique. It is therefore advisable to start with an assessment that maps out the current status, where the introduction of agile is most opportune and which specific obstacles are present. The result is a zero-measurement with insight into the current state of affairs and clarity about where to start. • Step 2-Formulate the why and the urgency. Successfully implementing an agile transformation is only possible if it makes sense and there is sufficient urgency. It is therefore necessary to specifically articulate the reasons for the transformation, so that all those involved gain a clear picture of it. Specify the target quantitatively, so that actual progress can be measured during the transformation. • Step 3-Work out a blueprint. Transformations need direction. So make the ideal final situation (or blueprint) explicit. In order to achieve this situation, it is often necessary to divide the organisation into market-and customer-oriented teams, which work completely autonomously and independently. • Step 4-Determine the change strategy. Will the transformation be carried out in phases, via an oil slick or perhaps with a big bang? All three (and hybrid) variants are possible. It is essential that a fixed change strategy is used. The one that fits best always depends on the environment and the people in that environment. It is important that there is a strategy and that it is consciously chosen. • Step 5-Create a transformation roadmap. This determines the order in which the changes will be implemented. Usually, such a roadmap is worked out on a large board or brown paper on which the various transformation themes and actions are set out over time. For example, with columns such as this sprint, next month, this quarter, next quarter, rest of the year. This is the plan to deviate from and that will be revised and adapted continuously. • Step 6-Implement the roadmap iteratively in sprints. Set up a tight rhythm for the transformation team. Experience has shown that 1-week sprints are very effective, because they result in fast and agile working. In addition, they help keep actions small and result oriented. • Step 7-Measure and revise the roadmap. It is crucial to measure progress explicitly, especially the extent to which the actual goal is achieved. In addition, the roadmap will need to be updated regularly. This is done in detail on a weekly basis (step 6) during the refinement and planning, but it is also important to adjust the roadmap more intensively on a quarterly basis and generally (step 7). • Step 8-Integrate through governance and culture. Changes are immediately anchored in the normal way of working. There are two ways of doing this. Firstly, by making them part of the governance-for example through practices, KPIs or procedures. It is much better to anchor changes through culture. This is because they are then directly integrated into the actual behaviour of teams and people.

Pitfalls of Agile Transformations
Becoming truly agile involves much more than learning a new trick. Agile working requires the transformation of firmly anchored structures, processes and systems. However, the existing culture, the underlying views, principles, norms and values also shift. This complicates matters, and even with a quick start it can take several years before an agile transformation is fully implemented. Because agile working is much broader than initially imagined, its actual impact is always underestimated. As a result, many organisations repeatedly make the same mistakes when seeking to become agile. The seven most common pitfalls are: • Pitfall 1-No focus on interim results. An agile transformation requires agility. That is why it's important that whatever is changed really is changed. This requires a continuous focus on the implementation of large ideas through small, noticeable steps during the planning and implementation of the changes. In fact, this is the basis of any form of agile: making things small, following things through and learning by doing. Agile transformations themselves are no exception in this respect. However, in practice we regularly see a detailed schedule for an agile transformation with interim milestones and a fixed end date. The most important condition for successful agile transformations is nevertheless agile execution.
Step by step, implementing the most valuable change first and making adjustments based on learning experience. • Pitfall 2-The 'why' is not measured. Agile is not an end in itself. Introducing it serves a higher purpose. Many organisations do not make that goal explicit. This creates confusion about the motives, and everyone creates their own interpretation. Subsequently, the extent to which the transformation has the desired effect is often not measured. Without measurable progress, the usefulness of the investments will sooner or later be called into question. Making the goal explicit and measuring whether it is being achieved is therefore very important. • Pitfall 3-Management support is at a too low level in the organisation.
Transformations are often made by one specific manager or director. However, practice shows that the desired changes always have an impact on adjacent departments or other companies in the same ecosystem. This is often forgotten, causing senior management to make the wrong interventions at the wrong time. This in turn is a hindrance and counterproductive. It is therefore necessary to have active support from at least two management layers higher than the place where agile is implemented. But there comes a time when it is the CEO him/herself who will lead the transformation. Ultimately, an agile transformation is an integral transformation of the entire organisation. It can't really succeed without the full support and involvement of the highest executive. • Pitfall 4-The impact is heavily underestimated. Transformations to agile are farreaching and usually require adjustments far beyond the area in which they begin. Agile teams are set up, for example, and the individual assessment of employees is quickly called into question-after all, it's all about the team's result, right? Before you know it, HR systems and assessment processes are transformed. It is therefore worthwhile to learn from the experiences of other organisations through company visits, for example. In this way, it is possible to anticipate what is yet to come. It is also advisable to include, involve and inform top management.
Ultimately, agile will affect the entire organisation. And not only in terms of working methods, but also in terms of processes and structures and even culture. • Pitfall 5-Fear of failure rules, and there are too few experiments. Agile working requires short cycles and is therefore able to handle the unknown well. This does require an organisation to learn how to work with uncertainty, mistakes and experiments. A fear culture makes it extremely difficult to implement agile. As long as people are afraid to make mistakes, experimenting is extremely difficult. But it is precisely experimentation that is needed to be able to work in an agile manner. After all, the faster one learns, the more agile one becomes. A focus on learning experiences and the future in the case of mistakes is then important. As long as there is a fear of failure or in the case of failure, the culprit is sought in the past, an agile transformation will prove difficult. This is because agile is all about learning by doing, and successful learning is impossible without mistakes. Fear of error is perhaps the greatest assassin in any agile transformation. • Pitfall 6-The importance of a new rhythm is not understood. Rhythm is essential for agile working. Many organisations have a hard time with this and add agile meetings as an extra, whereas they should be the basis of everything. The organisation then remains very ad hoc and there is less time for the real work. By establishing a rhythm of recurring meetings, adjustment is provided for. If something unexpected occurs, escalation is no longer necessary, and questions and problems can be dealt with in existing rhythms. This provides security and structure. It does require a new rhythm to schedules and the structural cancellation of the usual meetings as they were held. • Pitfall 7-Attention is paid solely to the process. With a focus on the mechanical process, too much attention is paid to the procedural side of agile and not enough to the side that has real impact. Agile working requires much more than a set of meetings and working arrangements. It requires a different approach to organisational issues. Agile transformations require a change of culture, beliefs and prevailing values and norms. Make sure, therefore, that the transformation to agile is much broader than just the process side.

Conclusion
Agile goes beyond a wish for novelty. Agile working is often started because the market and the environment require more speed and agility than can currently be delivered. Something therefore has to change. Generally, a number of pilots or initial projects are cautiously started. Once confidence has been established, the strategic choice is quickly made to switch completely to agile. This doesn't just happen in smaller companies. Increasingly, large organisations are also switching to agile as standard. A number of multinationals, banks, manufacturing companies and telecom giants are currently carrying out transformations in which agile working will become an important basis for the future. What does work well in practice is to structure the transition to agile as a separate change process. The first step in such a transformation consists of strategy and planning. Questions are answered such as: Why do we want/need to change, what will the organisation look like in the future, what are good objectives, what problems have we solved? And naturally also: What is the business case for this change, and what does the planning look like? Such questions sometimes do not seem very 'agile' at first glance, but practice has shown that an agile transformation begins by first properly adapting to the current situation.
Implementing an agile transformation is not an easy task. What usually starts with a single agile team soon results in all fixed values being called into question. Despite the good intentions, organisations regularly find themselves mired in an agile transformation. At the same time they often have no choice but to attempt it, since the market demands far-reaching agility and speed. Doing nothing is therefore not an option. Lessons learned and mistakes from the past can help make agile transformations run better and faster.
An agile transformation is best carried out via a step-by-step rhythm of iterative changes, i.e. agile is best introduced agilely! Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.