Your Agile transformation is likely set up to fail. Here is how to do it differently

Your Agile transformation is likely set up to fail. Here is how to do it differently

In our consulting practice we see that many organizations take remarkable efforts to carry out Agile transformations, yet the outcome of these efforts varies considerably. While some organizations achieve great positive impact, others reap little benefits. It is common to find Agile written all over an organization but little Business Agility being realized. We want to support executives in avoiding common pitfalls in Agile transformations and help them to build Business Agility successfully and sustainably.

No alt text provided for this image

Jumping straight to implementing Agile methodologies creates a false sense of getting things done

Agile methodologies come with very specific instructions on how team members need to work together, how to structure workflow and how to design an optimal working environment. Implementing such a framework can create a strong sense of getting things done because of its direct practical application.

The most popular methodology to start with is Scrum. Scrum allows teams to split their work into small prioritized tasks, accomplish these tasks autonomously in a restricted period of time and track their progress. The organization thus proceeds to create Scrum teams, install Scrum rooms, put employees through a Scrum training, give project managers the title of Product Owner, and then expects improvement to ensue. After a while this leads to the surprising realization that either some improvements have come about but the desired effects haven’t materialized, nothing has changed at all, or that things have gotten worse. 

It is usually only at this point that a greater moment of reflection sets in where the organization recognizes that is has not undergone a transformation. It has simply grafted a new methodology onto existing structures which has led to doing the same things under new names. Managers often underestimate the difficulty of breaking through legacy structures.

No alt text provided for this image

Your approach determines your outcome

The difference that creates a successful or non-successful outcome of an Agile transformation is the approach an organization takes. Organizations with little success take an instrumental approach that focuses on the implementation of Agile management methodologies such as Scrum, SAFe or LeSS without understanding the underlying principles and the consequences for the operating model.

Successful organizations appreciate that building Business Agility requires a fundamental shift in an organization’s thinking, operating model, and the way it conducts its business. They also understand that becoming Agile is not the result of a large one-time effort but a permanent state of continuous learning, improving and adapting. Successful organizations therefore apply a principled approach to building Business Agility. This approach does not start with the implementation of Agile frameworks but with the adoption of an Agile mindset throughout the company. This is followed by the restructuring of teams around core capabilities, a reconception of culture and leadership, and an adjustment to quarterly steering, planning, and budgeting cycles.

No alt text provided for this image

Underestimating the depth of the required organizational change leads to superficial and unsuccessful implementations of Agile methodologies

No alt text provided for this image

A frequent problem we encounter in our practice is that organizations are aware of the importance of cultural and behavioral change but still choose an instrumental approach that solely focuses in implementing different management systems. This approach then leads to predictable dissatisfying results. This can best be illustrated by a simple example from the banking sector:

Imagine making a money transaction in 1990. You physically go to the bank, you get a physical transaction slip, write down the name and account number of the recipient, you throw the slip into a physical transaction box and go home. At the end of the day, employees of the bank collect the transaction slips. On the following working day, they manually type all the transactions made into the bank’s computer system. Depending on how many employees are available to process the slips, it can take several working days for your transaction to be booked.

When processes are bound to physical entities in this way, they are slow, divided into a clear succession of actions, stable, fully predictable and largely immune to change. The more you specialize in the individual actions, the more fluent and reliable the process becomes. You might for example hire a specialized typist who can process transactions quickly with a low rate of spelling mistakes. This logic holds for entire organizations. More functional specialization leads to more process optimization which leads to better results and more efficiency.

The customers of the pre-digital era first and foremost expected products and services to work satisfyingly, not to surprise and delight them. Consequently, there was little pressure to come up with new innovative products in short periods of time. Organizations mainly focused on making the already existing products work better. Customer demand was well-predictable. Organizations therefore became masters of planning and forecasting. Five-year projects, long-term budgeting, corresponding resource allocation, and personnel planning were valuable organizational skills to drive growth and a strong position in the market. A great advantage of high levels of functional specialization was the build-up of invaluable knowledge and expertise driving research, development and innovation. It was therefore a major component of an organization’s competitive edge.

Imagine the same money transaction today. You take out your smartphone, open the mobile banking app, type in your security code, select the transaction option, type in the amount and recipient, and press send. The transaction is made instantly. From your perspective no physical entities are involved except you and your phone.

Compared to the transaction in 1990, we now have a perfectly convenient process for the customer. Yet, for the bank, this process is immensely complex. It necessitates a digital environment that can be accessed from any device, with any operating system, anywhere in the world. This environment needs to be built, secured, maintained and continuously developed further. The transaction itself is a mixture of hundreds of constantly evolving technological processes. All this digital activity happens in costly data centers that cover thousands of square meters and which are themselves subject to continuous innovation and changes in regulation. The bank whose core business used to be banking, not technology, now must follow the inventions of actual technology companies to keep its banking business going.

Imagine now that the bank tries to solve this problem with an instrumental approach to Agile. The bank proceeds to create Scrum teams, install Scrum rooms, put employees through a Scrum training, and give project managers the title of Product Owner. The whole process is supervised by an Agile coach. The bank expects so see improvement soon, yet after a while comes to the surprising realization that the desired effects haven’t materialized.

This is a problem that we encounter often in our practice. Organizations choose an instrumental solution approach that focuses on the implementation of Agile methodologies and ends up doing more bad than good. We observe a big difference between these organizations and organizations that choose a principled approach. The latter organizations focus on understanding the principles of Agile and how to make them work for their business model and market. They then implement Agile methodologies in a way that suits their specific needs.

To simplify the underlying principles of Agile, we have summarized them into 6 fundamental shifts of organizational and behavioral change that every traditional organization needs to go through.

No alt text provided for this image

In our next blog, we will explain each of the six shifts in detail.

No alt text provided for this image

This blog is the first part of a series of three blogs that is dedicated to informing executives about how to build Business Agility successfully and sustainably. For our full article on building Business Agility click here.

?

Ewoud Ravenshorst

Chapter Lead Roche Healthcare Consulting

5 年

Hi Floris! Interesting blog. I believe this principle is applicable to almost all methods/ tools, including Lean, Design Thinking, etc. The instrumental approach will result in unsustainable results (if any). I look forward to your next blog.

要查看或添加评论,请登录

Floris De Bruin的更多文章

社区洞察

其他会员也浏览了