Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: BoD - Books on Demand
- Kategorie: Fachliteratur
- Sprache: Englisch
Becoming a customer-focused, versatile, and resilient organization is the goal of many of the agile transformations we are seeing in Germany and Austria, regardless of company size or industry. The journey for organizations is not easy - sometimes it is even bumpier than it needs to be. One thing is certain: there is no single right way - no "happy path" - to achieve an agile transformation, because the individual requirements of countless organizations cannot be met by a one-size-fits-all approach to change. However, there are tools that make the journey easier and sustainable success more likely. Even when transformations go through a crisis - which is more common than you might think - there are reasons to remain optimistic. The authors of this book work at the heart of transformation activities. They design strategies for agile transformations, bring derailed transformations back on track, and guide people in the organization until they are able to design the next stages of change themselves. All of the approaches presented in this book are backed by experience and proven to work.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 512
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Contents
Preface by Boris Gloger
The authors
Before you set off
1. Agile Transformation: What is it and which roads take us there?
1.1 Deciding in favor of an agile transformation
1.1.1 Setting an agile transformation objective
1.1.2 Measuring the success of the transformation
1.1.3 Working on contents: The transformation team
1.1.4 Generating awareness of the impact of change
1.2 Agile transformation scenarios
1.2.1 Choosing a suitable pace for transformation
1.2.2 Agile organizational structures
1.2.3 Scaling frameworks
1.2.4 The six building blocks of an agile organization
1.2.5 Agile organization—is it all about Scrum?
1.3 Internal and external support for agile transformation
2. Route 1: How lost transformations get back on track
2.1 Organization and structure
2.1.1 Adapting the scaling approach
2.1.2 Managing dependencies
2.1.3 Agile assessment of the organization
2.1.4 Dealing with cross-divisional units
2.2 Roles and leadership
2.2.1 Creating a better understanding of roles
2.2.2 The responsibilities of an agile team
2.2.3 Integration of experts into agile teams
2.2.4 The product owners’ understanding of management
2.2.5 Scrum masters and solving impediments
2.2.6 The three central leadership facets in agile organizations
2.2.7 Scaling agile roles
2.3 Continuing the agile transformation
2.3.1 Chapters and guilds
2.3.2 Sharing responsibility among several people
2.3.3 Organic agile transformation with pilot teams
2.4 Integration of the findings into an organizational model for the start in other business units
3. Route 2: The transformation team - a guide through change
3.1 The transformation team approach
3.1.1 Agile implementation teams
3.1.2 Agile transformation in the remote age
3.2 Putting the transformation team together
3.2.1 Gaining top management ´s support
3.2.2 A transformation team canvas to identify team members
3.2.3 Transformation team kick-off workshop
3.2.4 Developing the agile transformation ´s vision
3.2.5 Splitting the transformation ´s tasks into appropriate streams
3.3 Cooperation within the transformation team
3.3.1 How the transformation team works in an agile manner
3.3.2 The transformation team ´s review
3.3.3 The transformation team ´s artifacts
3.4 Developing organizational structures and processes that fit
3.4.1 Initiating changes in the organization
3.4.2 Developing the first version of a new organizational and scaling framework
3.4.3 Identifying agile pilot teams
3.5 The work of the transformation teams in practice
3.5.1 Developing know knowledge
3.5.2 Impediment management
3.5.3 Starting up and accompanying focus groups
4. Climbing the steep walls: The transformation team in times of crisis
4.1 Problems within the transformation team
4.1.1 Adressing motivational issues
4.1.2 Dealing with expectations
4.1.3 Gaining force through lateral leadership
4.1.4 Team members do not live up to the expectations associated with their roles
4.1.5 Keeping busy in the ivory tower
4.1.6 Incremental deliveries as the key to successfull change
4.2 Resistance from within the organization
4.2.1 Insurmountable obstacles
4.2.2 Impediments do not make it to the top
4.2.3 We lack support from top management
4.2.4 Competing transformation teams
4.2.5 Challenges with external service providers
4.2.6 Change within the organization is too slow
4.3 Implementation gone astray
4.3.1 Do we still have the right target image?
4.3.2 For all intents and purposes: What is agility?
4.3.3 The transformation team is not authentic
4.3.4 Agility is expressed in different ways in different parts of the organization
4.3.5 Difficulties in achieving improvements
4.3.6 The transformation team is not authentic
5. At the summit: Maturity and Transition to the next change?
5.1 Safeguarding the achievements
5.1.1 Establishing the transformation´s status quo
5.1.2 Intervene or take a break
5.1.3 Transformation successful: Transformation over?
5.2 Thinking about transformation and culturral change throughout the company
5.2.1 Implementing reflective processes
5.2.2 Consistently developing leadership
5.2.3 Salary and performance management
5.3 New working models for the transformation team
The next part of your journey
Thank you!
Bibliography
Preface by Boris Gloger
Our society is currently facing the largest economic challenge since World War II. The US no longer perceives Europe as a partner, but as a rival, and as far as the digital economy is concerned, we are lagging far behind China. The much-praised German and Austrian “Mittelstand”, small and medium-sized companies, have quite simply missed digitalization. Our education system cannot accomplish its mission of training tomorrow’s innovators and entrepreneurs—basically because the ministries in charge are unable to provide efficient, unbureaucratic infrastructure for digital learning.
One-size-fits-all approaches are impractical in this new era. The COVID-19 pandemic served as an accelerant and proved to us, in a matter of days, what was amiss: a lack of digital infrastructure, too little bandwidth, rash outsourcing of know-how to other continents and, as a result, global supply chains that are interconnected to such an extent that not even things as basic as protective masks or rubber gloves were available. At the same time, the pandemic propelled us into a “new normal”, which large parts of the population and companies were not prepared for. Within mere weeks, entire sectors changed and new business models emerged. In the past, several generations were able to live off the idea of a founder; nowadays, founders need to reinvent themselves at very short notice.
One thing has become blatantly obvious, though: Europe, and Germany in particular, only play a marginal role in all of these transformations. There is no leading European videostreaming platform or search engine. We give praise to domestic online shipping services that work for a change, but these services are insignificant on a global scale. Our decision-makers often give the impression of hoping that the digital hurricane will pass us by, allowing us to escape relatively unscathed with just a couple of cracks in the wall.
Gary Hamel once said that management was one of humanity’s most important inventions, and that this invention allowed us humans to cooperate in dimensions unimagined thus far. According to Gerald Hüther, this invention was so successful that it created a complexity which could no longer be governed by management itself.
This is why we are at a crossroads in the management of organizations and institutions. Humankind has evolved from an agricultural society into an industrial and financial society, and most recently into a digital society. Software corporations are more valuable than companies in any other era. How did they get there? I believe that this is due to two factors:
On the one hand, a new management paradigm: introducing new forms of cooperation between people, just like Gary Hamel said. We need to understand that we are dealing with sociotechnology: agile management. New and different forms of interaction lead to increased productivity—after all, this increase cannot be the result of technology alone, as technology existed before.
On the other hand, a factor that I consider to be highly underestimated in current debates: thinking in networks or systems. A software company such as Tesla does not only produce vehicles with electric propulsion; they also factor in charging stations with solar panels. This is very different from a German car manufacturer that still considers premium cars to be its core business. The fact that these cars also need software is considered to be an add-on, not a major value-adding factor.
All in all, we are currently experiencing a transformation in our society. Organizations are becoming learning spaces in which every single one of us realizes that we need to adapt to the new conditions and learn new ways of working. Seeing organizations and institutions as learning spaces also means that we need to accept that they will change fundamentally and irrevocably.
After all, at the beginning of 2020 it was still unimaginable for companies to have the majority of their staff work from home. Today, working from home is more normal than ever. And it is exactly this change—although it is not actively promoted, or even wanted, by leaders - that results in new forms of working, which in turn leads to employees rediscovering themselves.
As leaders, we can either stand by and watch this tidal wave force our companies to transform, or we can keep an ear to the ground and start this transformation ourselves. We can make deliberate use of agile management methods and systemic mindsets, or we can surrender ourselves to change. We can shape this process; that is the message of this book.
My colleagues will show you the ropes and what it takes to successfully achieve transformation. They will not promise pie in the sky but share the knowledge they gained in hundreds of days of work with our clients. The authors, among them Christoph Schmiedinger and Carsten Rasche, write about more than team-based, network-like, customer-focused organization. They know how to help traditional organizations adopt this new structure, whilst making them resilient and versatile at the same time. No one-size-fits-all approach, no prefabricated frameworks—on the contrary: always considering the organization’s specifics as a starting point in transforming to a new level in order to be just as successful in the future.
I hope you enjoy reading this book and gain many useful insights!
Boris Gloger
The authors
Christoph Schmiedinger, Executive Consultant at borisgloger consulting, provides leadership training and management coaching. He supports companies in the finance, telecommunications and automotive sectors in agile transformations and business transformations as well as in organizational development. Before working as an executive consultant, Christoph Schmiedinger was a product owner and responsible for product development for a leading safety-critical telecommunications systems producer. He holds a master’s degree in Technical Management and an MBA from ESADE Business School in Barcelona.
Carsten Rasche, Executive Consultant at borisgloger consulting, is an expert in scaling agile organizations, especially in the finance and insurance sectors. Working as an organizational psychologist, management coach, and professional facilitator, he has successfully completed several business transformations using a participative approach. Before joining borisgloger consulting, Carsten gained experience of organizational dynamics as a project manager in youth welfare and applied agile methodologies in his work in Silicon Valley.
Ellen Thonfeld, Head of Training Management for Internal Auditors at KfW (Reconstruction Credit Institute) is a trained and experienced banker, professional facilitator, trainer, and management coach. During her time at boris-gloger consulting, she developed the Agile Audit Transformation approach, which introduces and establishes agile work techniques within the audit team in short cycles. Parallel to the transformation, she applies her experience as a business educator to shape the audit departments into a learning and self-evolving organization.
Kathrin Tuchen, Senior Management Consultant at borisgloger consulting, is a professional facilitator and provides management coaching. She contributes to agile organizational development by sharing the knowledge she gained concerning the customer experience at an international tourism group. As a trainer and team coach for projects in the banking and insurance sectors, she shows agile teams how to unleash their full potential, and supports scrum masters and product owners in successfully living up to their roles’ demands.
Before you set off
Books about agile transformation often outline an ideal process. Just follow these steps in the right order and you will have created an agile company. These steps are correct, important, and rational but the transformations that we experience in our day-to-day work do not proceed according to this pattern. We are usually asked to consult and particularly to support companies when a transformation gets stuck.
The good news: transformations struggle more often than you might think. When an organization aims for nothing less than its own comprehensive change, it will not be able to plan every small step along the way. Also, there is no way of guessing, and even less chance of predicting, how people within the organization will react to the transformation. We believe that losing your way a little is part of the process; after all, there are many uncertainties on your way toward agility. Going astray, either a little or a lot, is part of the process and it is these experiences that will help the organization to progress.
This is why we chose the metaphor of the way to the summit for our guide to agile transformation. We are aware that the metaphor has its flaws: after all, the summit usually marks the destination of a hike; as soon as you have reached it, you turn around and consider the mountain to have been conquered. We, however, do not see the summit as a finish line, but as an initial expedition. It is the destination at which your organization will have successfully overcome the first challenges on the way to becoming an agile organization. The view from the top is stunning and you can be confident—and rightly so—that your organization will reach further summits. It has set off on its journey and has become more mature and stronger as a result.
Figure 0.1Chapter overview
What do you see in this image? Usually, a few agile initiatives already exist within a company—they might have started out of curiosity, interest, or sometimes a state of emergency, when a project got into trouble. Initial experience has already been gained. This is why agile transformations which aim to change parts of the organization, or even the entire company, rarely start from scratch. At some point, those responsible decide to expand their agile experiments and set the entire organization off on the path to becoming an agile company. This is the first stage (Chapter 1): the green meadow on which the first important decisions are made. Which route do we choose?
There are usually several routes to climb between that first green meadow and the summit. Most of the time, you can choose between a more difficult or an easier route. Either the rope team just sets off, relying on its used equipment and experience from other, less difficult routes, or it requests the support of experienced mountain guides who take time to help it get to know the new terrain and learn to read it. At the beginning of a transformation, we observe different strategies in companies. For reasons of simplicity, we have divided them into two fundamental approaches:
Version 1: the company tries to propagate initial agile experiences with traditional change instruments within the organization in order to promote change (more on this in Chapter 2).
Version 2: before launching an agile transformation process, the company establishes a transformation team which keeps a close eye on the rope team’s situation and draws on previous experiences from earlier explorations in every step along the way (more on this in Chapter 3).
Both versions can lead to the summit: but the dangers in version 1 often tend to be greater than necessary. Sooner or later, everyone following this transformation approach will come to the conclusion that an agile organization is easier to achieve on the iterative-incremental route and with a team of well-versed mountain guides (the transformation team).
We have therefore divided this book into two possible paths, each aimed at different target groups:
Chapters 1
,
3
, and
5
are particularly useful for readers who are just at the beginning of their company’s transformation. You will learn about the transformation’s “happy path”, which involves having a transformation team from the very beginning. In addition, you will learn how to avoid pitfalls ahead of time in
Chapter 2
. Do remember, however, that any transformation can lose its bearings sooner or later. For this reason, it is useful to take a look at
Chapter 4
, which deals with transformations in times of crisis.
Chapters 2
and
4
are devoted to those readers who are already in the middle of their transformation and are facing numerous challenges. Here we describe the details of how to return to the path to the summit when a transformation has gone astray.
Of course, you can also read the book from cover to cover. Then you will gain knowledge of both the “happy path” and the pitfalls encountered on the climb to the summit. Regardless of the path you choose in this book, all chapters have the following structure:
First, a brief overview of the starting point is provided.
We then answer questions that we are frequently asked in such situations.
At the end of the chapter, we point to specific risks that arise in this situation.
Finally, you will also find references for further reading that could provide additional help.
Therefore, this book is not to be construed as a start-to-finish story. The contents have been compiled from the many questions that those responsible for transformations have asked us in different phases of their processes.
Our mission is to offer guidance through a transformation’s uneven terrain, providing you with relevant support at the appropriate time on this journey. You can therefore read this book from cover to cover, skip parts, or move back and forth between chapters. Whatever stage you are at in your transformation: this book will provide you with advice on how to reach the summit from your current position.
We wish you and your organization success in your endeavors, and we hope you gain valuable experience along the way.
Christoph Schmiedinger
Carsten-Hendrik Rasche
Ellen Thonfeld
Kathrin Tuchen
1. Agile Transformation: What is it and which roads take us there?
Companies are under enormous pressure. They need to hold their ground against young, flexible competition and consider the impact of new technologies on their supply chains. This is why agile methods have been the subject of many experiments, most of all in IT departments. It has often been—and still is—individuals who take the initiative: heads of department, team leaders, or project managers, who have recognized the benefits of agile ways of working. These individual initiatives are usually met with a great deal of success: projects are completed much more quickly than usual and frequent coordination brings a new quality to cooperation with customers. Individual agile teams also tend to reveal problems within the entire organization.
However, these individual initiatives often remain just that: separate initiatives. They do not touch upon major issues that an organization might encounter if it fundamentally changed its environment, introducing a flexible mindset, thinking in iterations, and thus establishing direct contact with the end users. Naturally, this is frustrating for agile teams. They see all the lost opportunities and their motivation plummets. The initial momentum gained from agile experiments cannot be sustained and increased.
If agility is not supported within the company beyond individual initiatives, we often observe that every team has a different understanding of how to work in an agile manner. Some turn to Scrum, using every trick in the book, while others only use individual, disconnected meetings or artifacts. Other teams use agile methods but have failed to overcome thinking in specialist disciplines. They all only work on their own parts and work is often duplicated. Another alternative: no stakeholders, customers, or end users attend the sprint reviews. Sometimes, they are not even invited.
Management becomes aware of the fact that things are not going well. Eleventh-hour panic takes hold: managers have their eye on the competition, where comprehensive change has long been introduced. The executives embark on an exploration of these companies, start initial discussions about diverse models, and consider whether they might be suitable for their organization. Suddenly, management demands change: right now, and without compromise. The company is to become an agile organization!
This is when the company starts talking about an “agile transformation” (if it has not done so already). But: what is agile transformation anyway? What is an actual transformation, and what should just be termed the introduction of agile methods? And: does every agile transformation aim to produce an agile company?
In our view, the following is true for agile transformations:
It is not just the introduction of a new method. It is an endeavor to introduce change beyond the scope of individual or multiple teams, to a company’s general organizational conditions. This includes, among others, coordination processes, portfolio processes or financial and budgeting processes, comprehensive development of IT architecture and infrastructure, cultural change, and a new kind of leadership. A relevant part of the company is affected by this change. This is no set rule, of course, but we usually call it an agile transformation if at least 25 percent of the staff are involved in the change. It is not considered to be a project with a deadline. Agility means facing continuous change, forced upon a company by its environment. In this respect, an organization can never stop transforming or at least adapting.Pursuant to this attempt at a definition of agile transformation, it is not necessary for the transformation process to result in a company that fully implements agility in all parts of the organization. What is most important is that significant, positive changes become apparent within the organization, and that there is willingness to adapt to constant change. The actual destination of this journey, therefore, is not the successful completion of a transformation. Rather, it is improved adaptability that allows the organization to remain competitive in the long term.
So now you are facing this agile transformation and you might be wondering where to start.
This chapter will provide information on
what you should consider before initiating an agile transformation,how you set targets for your agile transformation,how you raise awareness of the impact of change, andwhich fundamental approaches and scenarios there are for the transformation1.1 Deciding in favor of an agile transformation
Who will decide whether to initiate an agile transformation? And when is the right time?
Depending on one’s point of view, the time for change is always now—or never. In light of the dynamic market situation, companies basically face two situations that lead to a decision in favor of an agile transformation:
Pressure for change within the sector.
Many companies do not even have time to try and test agile ways of working in small teams anymore. Companies that are hit full-on by digitalization are currently facing the highest pressure. Until approximately 2010, it was almost exclusively teams and companies in e-commerce that introduced agile methods. They were agile pioneers. Early on, the telecommunications sector also discovered the benefits of agility, and ever since, this surge has swept across many sectors: from the automotive industry to energy suppliers and medical engineering to the financial sector. Agile transformations were a logical consequence of the important role software plays in the creation of value and therefore go hand in hand with the pressure to digitalize in these sectors (see Bradley et al. 2015). In the meantime, however, less software-focused companies have equally discovered the benefits of work-ing according to agile approaches and agility has become the latest leadership paradigm.
Pressure for change through agile pilot projects.
Many companies have gained initial experience with agile methods. These insights often reveal that limited use of agility will not bring about significant change in the company. The first steps with agile methods are often sufficient to reveal obstacles within the organization that prevent success or render future success difficult. This begs the question of whether change ought to be thought through more comprehensively and expanded to include all levels of an organization. The advice to translate the experience gained by individual teams into a comprehensive change program can be brought forward by different parties: management itself, the strategy department, or the business units that have actually gained first-hand experience.
In the end, the decision in favor of or against an agile transformation comes down to the importance given to these two forms of pressure for change. When deciding in favor of a transformation, however, one thing becomes indispensable: management needs to be involved in every step along the way. An agile transformation can only be successful if it is supported from the very top and—even better—if top managers themselves work in this way, implementing the kind of leadership that they expect from others.
This is why it is imperative to point out, right from the start, that management’s involvement will bring about the success or failure of the entire transformation. Should top management have difficulties in recognizing the significance of their own involvement, one recommendation has proven its worth: “Go and have a look for yourself.” Managers are put into contact with teams that already work in an agile manner, and they can go and have a look at the structural challenges these teams are faced with on a daily basis. Most frequently, issues are caused by company-wide processes and organizational structures.
These are problems that cannot be solved by individual business units, and even less so by individual teams. They can, however, be solved if top management creates the necessary conditions for the entire organization (or at least a large part of it) to realign and adjust itself.
Getting the decision-makers on board
At a medium-sized company providing financial services, several project managers had introduced agile methods, primarily for projects that included the development of software. Motivated scrum masters had identified many impediments during the first sprints and were persistent enough to overcome some of them. The first successes became apparent: only a small number of iterations were necessary for the delivery and productive implementation of parts of the software.
However, many impediments were very large, and organizational in nature. At the beginning, the scrum masters had tried to meet with those responsible to find solutions at a bilateral level. Most of the time, though, one problem led to the next and sustainable solutions were rare. For example, an appropriate development environment was needed. At first, this was to be created by the IT department, but they lacked both funds and experts. Therefore, the responsible member of management, the procurement department, and HR had to be involved. In the end, the request just petered out.
Understandably, the scrum masters grew increasingly frustrated when faced with so many obstacles. So they aimed to make a clean break: they compiled the largest obstacles, created a demonstrative illustration, and presented it to management. Their message was clear: “We need your help! If you want more and more productive teams, we need a comprehensive, structured process!” The scrum masters referred to their previous successes to underpin the prospect of more productivity.
This first workshop with management served as a catalyst for comprehensive transformation that took almost one and a half years—during which the organization was partially restructured and many processes were made leaner.
A workshop with the top management should therefore include the following:
Everything that has been done in connection with agility, and all the successes achieved
Challenges across business units and how their solutions would benefit agile teams
Setting priorities for current challenges, using a benefit/ effort matrix or a benefit/cost-of-delay matrix (see Willuda 2016)
Determining the next specific steps, such as the establishment of working groups for the solution of specific issues
Optional: a first roadmap as well as measurement criteria that allow for the assessment of whether targets have been met
Most importantly, it needs to be stated time and time again during the workshop that measures across business units are imperative. It is not about selective solutions, but about sustainable solutions.
One other consideration needs to be taken into account during this workshop: is the company in an economic situation that allows for such change? Agile transformation rarely works without significant investments, e.g., in modern IT infrastructure, new working environments such as innovation labs or offices suitable for team cooperation, as well as support from external experts. At the same time, productivity will decrease in the short term (see Figure 1.1). This is not unique to agile transformations, but a phenomenon that occurs whenever people reorganize themselves and build a new system. Does the company have the necessary financial means to overcome such a decrease in productivity? In preparation of a transformation in a medium-sized enterprise with approx. 250 employees, we conducted a three-day assessment. Together with management, we tried to select a representative sample
Figure 1.1J curve: the typical decrease in productivity during change processes
Assessing the existing conditions: agile assessment
An assessment can help identify, to a certain degree, how appropriate a certain point in time is for the start of an agile transformation. Such an assessment puts current processes and methods of working, culture, and also “hard facts” such as IT infrastructure to the test. Thus, it can help to get preliminary obstacles out of the way before fundamental change is put in motion. And it also reveals where within the organization initial change measures can be implemented. How does such an assessment work?
In preparation of a transformation in a medium-sized enterprise with approx. 250 employees, we conducted a three-day assessment. Together with management, we tried to select a representative sample of six teams, some of them working agile. Together, we reflected on the last six to twelve months.
The questions we asked the teams were based on traditional retrospective questions:
What is the team’s history and context?
What went well in the last six to twelve months?
Where do you see potential for improvement?
What are your wishes for the future?
At the same time, we conducted individual and group interviews with stakeholders relevant to agile product development. In this specific case, these stakeholders were:
the person responsible for IT architecture (enterprise architect)
representatives from operations
the chief operating officer
the person responsible for the portfolio roadmap and its budgeting
the veteran scrum master—the company’s first scrum master and a senior employee
We immediately documented the most important statements from the workshops and interviews on flipcharts in order to ascertain whether all those involved agreed with them. We compiled the most significant positive aspects and those aspects with most room for improvement from a large number of photo protocols (more than 80 flip charts in total). Following that, we arranged them according to the following building blocks or success factors of agile scaling (read more on this in Section 1.2.4):
organizational and product architecture
infrastructure
skills & expertise
customer orientation
management frameworks
leadership & values
Finally, we also identified the organization’s most important meta topics. These included low appreciation of success, both at the team level and at the corporate level, and the non-existence of a closed feedback loop from the team level to the management level. Therefore, knowledge about problems and obstacles slowing down the teams’ operational work rarely reached the relevant positions in management and were not resolved in a sustainable manner.
An assessment can help gain a good, initial overview of the system’s status quo and give an idea of the agile maturity of the company (see Section 1.4). In turn, such knowledge helps to gauge what kind of agile transformation a company needs and how radical it will have to be to benefit the company in its development. We highly recommend considering these points before starting an agile transformation.
1.1.1 Setting an agile transformation objective
Is it necessary to set a large transformation objective that will be communicated? After all, this change project is not meant to be one of many, pushed through simply because “agile” is all the rage at the moment.
Like any other project, no agile transformation should be initiated without a clear reason. This requires a business vision which serves as a basis for the identification of the transformation’s tasks and objectives. The following questions—which are often raised during a workshop—help reflect on the motivation for carrying out the transformation:
Why do we want this transformation?
How do we want the company to develop and how can agile transformation help us get there?
What do we want to change or improve over the course of this transformation process?
How will we recognize the transformation’s success?
Which objections are not part of this transformation?
Before holding a workshop on the reasons for transformation and before setting relevant objectives, it is necessary to gauge the support for this transformation. An objective-setting workshop can include small groups such as leadership teams, but it can also be held as a large event with representatives from all areas of the company.
Basically, the process of setting objectives needs to be held on as large a scale as possible, including many employees. Especially if only a small proportion of the workforce sees a need for change. There are many large group formats suitable for involving many people. One example is the Future Search Conference (see Weisbord, Janoff 2010): this is a multi-day workshop during which up to 100 people— from all parts of the organization—get together to work on the reasons for transformation and design a target image for the organization. For working on the design’s details, an Open Space format is a good choice, relying on the principles of volunteering and a marketplace (see Owen 2011).
Vision or target image – or both?
We do not aim to provide scholarly definitions of “vision” and “target image” in this book; our intention is rather to provide our opinion on these cornerstones of organizational development to enable better understanding.
We understand the vision to be an emotional, challenging, and inspirational formulation of the objective an organization wants to achieve. The target image, on the other hand, is a specific design of the—often near—future of the organization. It includes at least one, but often several dimensions: organizational structure, internal processes, or sales. Target images define the results of the change process in greater detail. However, they are not set in stone and remain flexible.
It is therefore recommended to use the developed vision as a starting point and proceed on to the next level, the organization’s target image, in order to design the initial characteristics of individual dimensions.
A sensible, realistic approach is the most important ingredient in any objective-setting workshop. This is why a target image for the medium term—usually achievable within the next two years—serves as a starting point. The choice of tools depends on the objectives that should guide the transformation:
Business modeling tools are advisable if the objective is to develop new business models. Alexander Osterwalder and David J. Bland provide a comprehensive review of various methods, such as the Business Model or the Value Proposition Canvas, in their book “Testing Business Ideas” (see Osterwalder, Bland 2019). Additionally, we recommend creative methods such as LEGO
®
Serious Play
®
or Video Prototyping (you can find an example here:
https://youtu.be/9yCVIrZJLn0
) for designing bright, inspiring visions and plans for the future. LEGO
®
enables the graphic discovery of the vision, even enabling role play, whereas Video Prototyping vividly recounts the vision using the story of a protagonist.
If the transformation’s focus is on corporate culture and new forms of cooperation, creative and communicative methods such as Video Prototyping, in which management tells a story, are highly recommended. This is significantly more authentic than a professional, “polished” image film. Learning journeys also tend to provide a lot of food for thought for management. These visits to other companies often reveal the actual scope of a transformation and what pioneers do differently. Here, again, the results and impacts on your own organization need to be recorded and shared, ideally in an interactive video format. Irrespective of methodology, it is the leaders’ behavior that counts, especially if the corporate culture is to be changed. They have to credibly live the culture that they want to see within the organization, and they also need to be approachable.
Be it business model or corporate culture: it is key not to lose perspective of the “outside”—clients and users of company products and services. Tools such as Personas and Empathy Maps are a good choice for integrating their perspectives (you can find a great collection of such tools in the “Design Thinking Playbook” by Lewrick et al. 2019). Both methods place the users and/or customers at the center: the workshop participants reflect on their motivation, feelings, problems, and what the company can do to help them.
Once the target image has been drafted, the following question arises: which supporting structures and methods are necessary in order to attain the objective? The motto is: structure follows strategy. This part of the workshop is generally about establishing whether agile methods are the right tool. One thing is certain: “everyone is doing it” should never be the reason for agile transformation. Before setting an agile transformation in motion, it is essential to have a clear, common, and fundamental understanding of when agility leads to success and when it does not (see Section 1.2.5).
Sometimes, the workshop reaches a standstill over the questions of “why” and “how” an agile transformation should be initiated. In such cases, paradox interventions that initially cause irritation can be helpful tools. For example, the Nightmare Competitor method (see Tagwerker-Sturm 2018) serves to define the company’s absolute nightmare competition and how such a competitor could endanger the company. Often, the question “what will happen if nothing happens” is also a useful tool on its own.
Regardless of the exact details of this workshop, it is important that the employees get the impression that discussing the future has an impact. The workshop should therefore end with an unequivocal agreement between the participants: which effective measure will be taken in the next weeks that will have repercussions throughout the organization? The most important measure to be taken immediately after the workshop is sharing the results, such as in a video. Other measures could include regular visits by workshop participants with agile project teams. It is vital that such activities are implemented by all participants in a well-concerted manner in order to make behavioral changes visible.
If your company is already working on several—more or less successful—change projects dealing with similar issues, it is best to conclude them with a retrospective. You should also try to integrate the lessons learned from these initiatives into the planned agile transformation. This serves the double purpose of enabling participants to have a neat conclusion of old projects and including important learning experiences in the new transformational effort.
1.1.2 Measuring the success of the transformation
We now have the vision and the target image for our transformation. However, top management also wants proof that agility really will be beneficial to the company in the long term. So, is it time for us to start calculating?
We constantly encounter the question of how to measure the success of a transformation. The reason behind this is often the desire to initially create a business case in order to then be able to approve a budget and thus also an initiative such as the transformation with a higher degree of certainty.
We are not opposed to measurement and setting target values in the metrics. However, we would like to point out that this should be done with a reasonable level of detail and a proportionate amount of effort. Business cases often include every last detail and are then finetuned until they somehow match the expectations of the stakeholders. In business, this level of nit-picking only results in losers.
Transformations are about believing in what is right. An organization is a highly complex entity. In retrospect, it is difficult to determine whether an increase in profit is attributable to working in an agile manner, the successful hiring of new employees, or a keen sense for new products. Usually, the positive impact of an indicator is a combination of several or an even greater number of good decisions. This raises the question of the extent to which it is feasible and sensible to break it down.
Let’s go in order and first tackle the business case and objectives separately within certain dimensions or KPIs.
Business Case
When we are asked for a business case, we usually request to engage with colleagues who have a good understanding of the context in which agility is to be deployed as well as a good sense of the financial considerations. We discuss a series of questions that focus on both efficiency and effectiveness with these experts. These questions are deliberately simple: the goal is not to calculate amounts to the nearest cent, but to develop a feeling for the possible financial impact. For us, the value lies in the discussions with the experts; initial indications for a business case are the by-product.
The following questions focus on efficiency and thus also on cost:
What results can we achieve if colleagues in a particular business unit can focus and work in a team on one thing?
What additional costs can be avoided if developments that have gone astray are steered back on track earlier (among other things, by means of regular contact with customers and users)?
How much easier is it to complete tasks if cross-functionality is increased within the team to ensure fast and smooth exchange?
To what extent is it possible to accelerate the process if current obstacles are systematically removed and thus eliminated?
How much management time can be saved if communication is less akin to the “telephone game” and reporting efforts are drastically reduced or eradicated?
How much time can the team save by making decisions themselves?
By contrast, the following questions examine the effectiveness and thus the turnover of the company:
How much more revenue could the company generate if it was able to place its products and services on the market earlier?
To what extent can customer satisfaction increase if products and services are more in tune with the expectations and needs of the customers and users?
There are, of course, a number of other questions that could be asked. We see it as an invitation to join the conversation and prefer to work with ballpark figures. For example: in discussion with the experts, we agree that the development team could save a good three percent of their time by drastically reducing their reporting efforts. Perfect—in the business case, we attribute three percent of staff costs to development. In discussions with the sales team, we understand that by reducing the time to market by a quarter of a year—depending on the product—they could achieve two to five percent additional sales. Great, we will take that on board.
In fairness, it must be said at this point that this business case must also be offset against additional costs. These are running costs, for example for additional colleagues (scrum masters and agile coaches). On this point, however, we repeatedly find that the cost of new roles is offset by the elimination of roles that are no longer needed (for example, project management as well as coordination and integration roles). Frequent prototyping can incur additional costs in the development of physical products. On the other hand, there are start-up costs, such as training on agile ways of working or additional agile coaching.
Setting objectives for dimensions & KPIs
It is not only business cases that are required, but also target values in certain dimensions that can be measured by KPIs. A common desire is to become faster in the market by using agile ways of working. Expressed as a KPI, this would be the average time to market from idea to launch. A second frequently expressed desire is to increase the quality of deliveries. If the quality of deliveries is to be improved, complaints and errors reported by customers could serve as a suitable KPI. KPIs can also arise from the business case: if shortening the time to market by three months was expected to boost sales, it is worth checking whether this hypothesis has become a reality.
A workshop with experts might also be useful in defining a transformation’s objectives. Our recommendation: focus on a maximum of four dimensions, each with a maximum of two KPIs. Time and again, we have noticed an immense appetite for measurement within organizations, but this is associated with considerable effort. It makes more sense to stay focused and survey the chosen indicators on a regular basis.
This brings us to the question of assessment. It is ideal, of course, if individual KPIs can be easily calculated and evaluated automatically or with little effort. If this is not possible, we usually resort to surveys. For example, the colleagues concerned might be asked how much effort reporting, including preparation and follow-up, currently takes. The advantage of this is that we can establish a “baseline” prior to the transformation, which is of immense importance—otherwise no comparison can be made with the time afterwards. Let us assume that the answers indicate an average of four hours per week prior to the introduction of agile ways of working. During the piloting phase, the team is at about three hours per week and eventually settles at two hours per week. Fantastic! The team was able to save an average of two hours per week. Incidentally, in a 40-hour week, this represents five percent of development time, which is more than assumed in the sample business case.
The difficulty in measuring is that from the beginning of the transformation, a good sense for having a small number of “right” KPIs must be developed. Adjustments can, of course, be made later, but the history is lost—especially the all-important baseline that was the starting point before the transformation.
Nevertheless, we advise that you do not let them drive you crazy. Yes, the aim is to measure whether the transformation is going in the right direction. Just be sure to do it in moderation and with purpose, not with exorbitant effort.
Measuring tools during the transformation
There are, of course, several other measurement tools that are helpful in certain stages of a transformation. We will briefly introduce some of them here, referring to the sections in this book that deal with the respective stage in the transformation. However, one thing we would like to state in advance is that the point is not to introduce measurement tools for the sake of measurement. The goal is to provide a transparent overview of the progress made in the transformation process so that changes can be made based on the data evaluated. Their effectiveness will be measured again in the next cycle.
After the vision and objective of the initiative have been defined in several workshops at the start of the transformation (Section 1.1.1), one of the first steps should be to hold a retrospective based on the “six building blocks of an agile organization”. With the help of this retrospective, you can work out the strengths of your organization, but also the potential for improvement. To determine whether the improvements are working, we recommend regularly conducting surveys among the teams involved in the transformation (see Section 5.1.1.3 for an example). These mini surveys can also provide transparent information about the status quo of the transformation in the teams themselves as well as about cross-team collaboration.
An example for illustration: in the retrospective at the beginning of the transformation, it might be concluded that decisions are made too slowly. The surveys among the teams will thus examine whether the speed of decision-making has noticeably changed for those involved as a result of the new processes. In order to leverage synergies, those KPIs that cannot currently be calculated should also be queried. The survey thus provides an overview of the impact of the improvement measures and at the same time contributes to the completeness of the set of KPIs. The interval between surveys should give teams the opportunity to introduce and/ or try out the measures they have developed. From our perspective, it makes sense to check on the transformation every three to six months.
Together with colleagues from HR, you can also evaluate how you might benefit from formal employee satisfaction surveys. These are typically already being conducted on a regular basis and are therefore another source of data for the transformation initiative. For example, the group of teams working in an agile manner could be compared to the overall set. Additional measurements designed to reveal a team’s agile maturity can be used in the individual teams (see Section 2.3.3). These measurements involve checking the basic elements of the agile process, the characteristics of the roles, and the ability to deliver.
More comprehensive external assessments are suitable in advanced transformations, such as the “business agility survey” (see Section 5.1.1.5). These test all of the capabilities of an agile organization and thus go far beyond agile working in teams. Such an assessment only makes sense if major changes have already taken place in the organization, such as modern budgeting and portfolio processes, and if self-organization has reached a decent level. Carrying out an assessment is very useful in these cases because it provides information about the starting points for further development of the organization.
The combined data points from
the collected KPIs,
the regularly conducted surveys, and
the maturity measurements at the team level
paint a transparent and data-based picture of the transformation. The transformation team does not need to rely solely on its gut instinct but can act whilst equipped with data.
1.1.3 Working on contents: The transformation team
Setting an objective is only one step along the way, though. Transformation needs content work in order to define the direction and get change going.
As soon as a fundamental decision in favor of agile transformation has been made and the objective has been defined, a core group of people get together—ideally voluntarily—to plan the transformation’s contents as well as the process and to move it forward. Not all agile transformations have such a group, which is why some of them end in a deadlock, as we will see in Chapter 2. We call this group the “transformation team”. In Chapter 3, we will describe how it is formed and how it works. Who should be represented in the transformation team?
At least one
sponsor
from the company’s management should be part of the transformation team, and in larger companies it would be advisable to include more than one sponsor.
One team member should be responsible for the transformation process, for example as the
transformation team’s product owner
.
The
further composition of the team
depends on the transformation’s priority: the transformation team can, for example, include representatives from the IT, product management, or human resources departments—depending on which forces should be bundled to best advance the project.
This team will hold further workshops to work on the details of the transformation. It is imperative that they take enough time for these workshops. It has often proven to be a mistake to dedicate only half-day, half-hearted workshops to the change strategy, because while many issues are briefly addressed, very little is decided or implemented. So-called “bootcamps”, however, present a suitable format: in these full-day workshops, the participants put day-to-day business to one side and focus exclusively on the transformation.
Team composition is one key to success—another is the way in which such workshops are held. A transformation team first needs to experience agile ways of working for itself. Therefore, there are (workshop) backlogs, the participants work in an iterative manner, and regular feedback is gathered on results and cooperation. The entire organization is influenced by the work of the transformation team. It becomes clear to all: the transformation’s initiators themselves work according to the principles they want to introduce.
Transformation in the Rhine Valley
We organized strategy workshops for a client’s transformation team at a location far away from day-to-day business: in the furthermost corner of the Rhine Valley. We blocked full Fridays for these highly focused workshops. It certainly was not the most popular day of the week, as the workshops sometimes lasted until late at night. However, the team recognized the importance of detailed discussions on the transformation’s strategic issues.
We used a wide range of agile tools and instruments: the overarching framework was the bright vision of transformation. Our backlog was full to the top: identify pilot teams, organize training, revise the organizational structure, etc.
During the first workshop, we tried to establish the extent of the project (at least roughly) to devise an initial “release plan”. We planned to work on a specific focus area each Friday. The Fridays themselves were divided into 60-minute iterations to allow us to verify if we were approaching the day’s target. We often achieved less that we had planned. Yet that was not what counted most—what counted was that we were able to define the transformation’s cornerstones. Subsequently, we worked on the details in smaller groups.
One example: we drew up an outline for every future role needed in order to establish whether employees would need training and, if they did, what kind of training would be best. We came to the conclusion that product development teams were to be trained in individual agile methods, the entire workforce would receive info sessions, and modular workshops would be useful for management.
1.1.4 Generating awareness of the impact of change
We have a plan, and we know what we need to tackle. However, we still get the feeling that management sees and perceives certain things differently. Are the people at the top aware of the impact that this change will have? Some seem to believe that all it needs is to put one agile team next to another and occasionally adapt processes to make life easier for these teams.
In many organizations, management is not aware that transforming into an agile company means undergoing enormous change. Depending on the size of the company, this could be years, rather than just weeks or months. The methods alone will not create any added value—not unless the organization’s attitude towards people as human beings and its cooperation culture undergo scrutiny and fundamental change. Likewise, ISO 9001 will only be beneficial if the attitude towards quality corresponds to the norm’s provisions—and “agile” can only be successful if thinking patterns are changed, too. If an organization is seeking its salvation in a method, such a method might be perfectly implemented but will have no lasting effect.
The change needed is so far-reaching that besides new methods, a new attitude towards people, and a new leadership style, it will also be necessary to review, reconsider, and modernize product architecture, infrastructure, and governance processes. By and large, it will entail comprehensive reorganization of the company. This cannot and will not happen in one day; it will be a long process if the aim is to create a sustainably agile company.
It is also vital for employees who do not work in agile teams to take the time to thoroughly understand agile methods. This means intensive work on the content—on the one hand concerning theory, in training for example, and on the other by accompanying agile teams, learning about how this approach works, and discovering why it is so successful.
Change is always highly emotional. Most people tend to feel threatened by change, even if its objective is to secure their own future. In such situations, it can be helpful to talk to people who have already experienced and successfully completed such change. If there are existing agile initiatives and movements within the company, they ought to be presented. As such, change is not only supported by management, but its meaningfulness is also confirmed by employees at the operational level. In such contexts we often organize “Agile Days” (a kind of mini conference) or “Fuck-up Nights” during which agile teams do not only talk about their successes but also about their failures and how they have overcome problems and obstacles.
If no one within the organization has had any experience with agility yet, visiting other companies—on so-called “Learning Journeys”—can be useful. It is recommended to visit companies that have completed a comprehensive transformation or become successful through agility. These include start-ups and renowned tech companies such as Sipgate in Dusseldorf or entire startup ecosystems like in Silicon Valley, Boston, Tel Aviv, or Berlin. However: learning journeys ought not to be considered as relaxing day trips. Before such visits, it is vital to define a clear objective; after the visit, the lessons learned should be reflected on immediately to make use of the momentum gained. How can we transfer what we experienced to our own organization, without simply copying and pasting from the other company?
Creating understanding for a new leadership paradigm
We held a series of workshops for a car supplier’s leadership squad, to allow them to experience agility. To that aim, we created an agile knowledge map in the form of a large jigsaw and worked on one piece at a time. Each two-hour workshop started with a lightning talk, followed by discussions, in small groups, concerning the impact of the presentation’s contents on everyone’s individual area of activity and on the company as a whole. Subsequently, we took another look at the map to prioritize the existing topics anew and include issues that might have come up during the discussions.
While the goal was to achieve a comprehensive understanding of agility within this organization, we used another concept focusing on “agile leadership” at a bank. We developed a six-module curriculum and held one half-day or full-day module every two to three weeks (see Figure 1.2). The participants learned about the most important aspects of agile leadership and combined what they learned in the modules with their preparation to implement it in their day-to-day leadership.
Only when leaders have reflected on the implications of agility should they decide on the organization’s future agile set-up: e.g., on comprehensive end-to-end responsibility of individual business units and teams for their products, processes, and fields of activity. Thorough reflection on the impact will reveal that organizational restructuring alone is not enough; it needs a series of supportive measures that enable the business units and teams to take on this responsibility, work autonomously, and produce results.
2-4 weeks between each module to work on the following two tasks:
Preparing the next module with a taskTrying out insights from the last module to start the next meeting with a round of reflectionFigure 1.2Modules for addressing the topic of agile leadership
Top managers first need to really understand the mantra “the organization’s change starts within me” before they can become aware of what others need to be able to change. In “Reinventing Organizations”, Frederic Laloux (2015) writes that an organization can only achieve the level of maturity that the people in the top management level have achieved in their personal development. An inspiring example of the force that personal change can generate involves the German hotel chain Upstalsboom, led by Bodo Janssen. He fundamentally changed his leadership behavior in 2010, after the results of an employee survey came in. One of the replies was: “We need a different manager to Bodo Janssen.” By working hard on his personal development, Bodo Janssen was able to completely overhaul the atmosphere within the company, establish new values, and lead the organization on the path to economic success. Alfred Herrhausen, Board Spokesman at Deutsche Bank who was assassinated by the RAF in 1989, once said:
