Thoughts on Agile Transformations

Growth pains

The world is becoming more complex by the day, and the same is true for most organisations. That makes sense. We encounter new exceptions to our rules, so we create additional rules. As a result, our governance becomes increasingly rigid and detailed.

We introduce new products to meet the growing needs of our customers and add more variations along the way. To manage this complexity, we create more departments. We attract new, larger, and different types of customers, so we hire more salespeople.

The market shifts, so we bring in more marketing professionals. At some point, we have so many people in marketing and sales that we decide to turn them into a department. They are busy serving our existing products and customers, so we set up yet another department focused primarily on new products.

Technology continues to evolve, which means we need to ensure the right skills and capabilities are in place. So we hire more people. With this growing range of competencies, coordination becomes harder and standards need closer oversight.

We respond by organising around technical competencies and appointing managers who are senior in those domains. Before you know it, you are looking in the mirror thinking: what happened to the small, flexible, fast company we once were?

Simplification is the answer

As an experienced manager, you reach a moment of reflection. You pause and look at your organisation.

You see a large, layered system optimised for local efficiency. Over time, it has gradually turned into something you are no longer proud of, but you were too close to notice it happening.

Could this have been prevented? Perhaps. But you are here now, and the most important question is where to start making things better.

One thing I am certain of: adding more rules and procedures, layers, roles, experts, and managers is not the answer. That is how you got here in the first place. Do not add even more complexity to an already complex problem. Do not simply bolt on an agile framework. If you are going to “do agile”, what are you going to stop doing?

The very idea behind lightweight frameworks such as Scrum is to simplify processes and interactions. Do not add agile as yet another delivery process within a larger waterfall-style approach. Use Scrum as the foundation instead, rather than Prince2 or IPMA, not alongside them.

Use feedback to learn iteratively which rules, procedures, layers, roles, and experts are slowing you down from delivering faster, cheaper, and better. Agile will not solve your problems for you, but it will reveal where your organisation hurts. It is then up to you to simplify your processes and structures.

Acceleration as a cornerstone

The benefits of an Agile transformation are usually described in terms of delivering better, cheaper, and faster. Better in terms of quality, customer satisfaction, or market share. Cheaper in terms of reduced waste in products and processes. Faster in terms of time to market and time to learn.

The more clearly you define what you are aiming for, the better you can measure progress. In the search for long-term advantage through being better, faster, or cheaper, I am comfortable stating that speed is the decisive factor. Increasing delivery speed deserves even more attention than the other benefits.

When you move faster, you can serve customers sooner and learn more quickly. Speed in terms of efficiency also translates into lower costs. The faster the feedback loop, the more effectively you can validate whether you are delivering value. This works like compound interest. It may seem insignificant at first, but over time it puts your organisation on a very different trajectory and ultimately makes all the difference.

Since your organisation started working in an agile way, have you actually accelerated your delivery process? Are you adding “agile” on top of existing structures and increasing complexity, or are you removing elements, simplifying, and speeding up the organisation instead?

All of us know more than one of us

Simplifying your organisation by changing the environment.

It sounds complex, and it is. Even though we recognise this, we often still approach organisational change in a planned and linear way. Tell us what to change, in what order to do it, and when we will finally be agile. Do you see the contradiction?

Just like product development and innovation, complexity is best addressed through an empirical approach: inspect and adapt. Take a step toward your goal, validate your assumptions, and decide on the next possible step. Look at your organisation as it is today: its structure, its processes, its habits. Identify which elements help and which ones hinder.

Which factors positively influence an environment that enables individuals and interactions, working solutions, collaboration with customers, and responding to change? Use those elements, strengthen them, and learn from their success.

Which factors hinder self-organisation, short feedback cycles for value delivery, creative solutions, and experimentation? Make these elements explicit and use the collective intelligence of the people doing the work to find better and simpler alternatives.

Learn by doing

Simplifying your organisation step by step and learning from each step is key to making change stick. Large-scale change is unsettling. We do not know exactly what the outcome will be, and we know we will encounter problems along the way. It is therefore entirely understandable that we look for certainty in the face of uncertainty. However, seeking that certainty in a large, thoroughly analysed, and detailed plan will not provide the assurance you are looking for.

As with product development, the way to deal with this uncertainty is to focus on making small, short-cycle changes rather than attempting everything in one big bang. So how can you learn more quickly what works and what does not when changing your organisation?

I prefer a controlled experiment guided by a few principles:

• go deep and narrow rather than broad and shallow
• combine top-down and bottom-up change
• work with people who are willing to take the lead

Start with a single product. Remove it from the existing organisational structure and decouple it from current procedures. Give the team space to experiment and ensure that the lessons learned flow back into the wider organisation.

The pitfall of Agile as a mindset

In many transformations, we see a strong focus on changing people’s mindset. The assumption is that if people start thinking in an agile way, their behaviour will follow. We train them, which is a good thing, and expect them to bring that knowledge back into the organisation. But if you do not also change the system they operate in, what results can you realistically expect?

It is like telling your children not to smoke while being a heavy smoker yourself. Or sending a child into a candy factory and expecting them to resist temptation.

People behave according to the ecosystem they live in. Habits and ways of working are largely shaped by the triggers and context of their environment. If that environment is designed to minimise risk, enforce strong silo ownership, and rely on process-driven decision-making, how much self-organisation can you truly expect? How able are people to work empirically when contracts are tightly fixed? And how much collaboration can realistically emerge?

Yes, train your people. And then start organising for simplicity and speed. Create an environment that supports individuals and interactions, where focus on fast validation is encouraged and rewarded.

The usual suspects

Every year, various institutes publish meta-studies on Agile adoption. They share data on the most commonly used frameworks, the level of Agile adoption within organisations, and the benefits achieved. These reports often include a section on “what hinders further Agile adoption”. I have grown inclined to skip that section, because year after year the same issues keep resurfacing.

Across these studies, the same insights appear time and again. The usual suspects causing pain are, not necessarily in this order:

• the ability to change organisational culture
• leadership support and behaviour
• general resistance to change
• adding Agile on top of existing methods or frameworks
• lack of knowledge, skills, and experience with Agile

Of course, with change of this complexity, there are no obvious or one-size-fits-all solutions. Still, some things simply always need to happen:

• invest in training and education
• hire for competencies that fit an Agile way of working
• simplify the organisation
• clearly communicate urgency and objectives

Perhaps the most challenging question remains: how do we effectively influence organisational culture and the role of management? And what patterns help increase the chances of success?

Respect comes first

Those managers… sigh…

They are often the loudest voices shouting “Agile”, yet they are frequently the biggest obstacle to adoption or transformation. Management, often middle management, can feel like a ball and chain. As a Product Owner, I should be having the key conversations, yet there is still a manager making the real decisions. As a Scrum Master, I am supposed to support the team in continuous improvement, yet there is still a manager assigning individual tasks and rewards when it comes to personal development.

Let us not forget that most managers reached their current positions because they were very good at what they did. They were rewarded and are still valued for being decisive, goal-oriented problem solvers. Let us also not forget that these people helped get us to where we are today, because we needed exactly those behaviours and strengths at the time.

Agile is not just a different way of delivering work, it is also a different paradigm for managers. And like any paradigm shift, it hurts. As Gandhi famously said: first they ignore you, then they laugh at you, then they fight you, then you win.

For managers, Agile brings uncertainty as well. Their roles often change the most, or they fear that their role may disappear altogether. That deserves respect before we expect them to change. So if you are acting as a coach or Scrum Master, ask yourself this question: do you treat managers as the problem, or do you treat them as people who are part of the change?

Theory X or Theory Y

One more thought on management. There is a lot of discussion about what managers should no longer do. I also feel that they are not always given enough guidance on what they can do instead. In times of uncertainty, such as during an agile transformation, we tend to fall back on what we know. In many cases, that means stepping in to solve the problem and taking firmer control of the wheel.

Managers have long been rewarded for exactly this type of behaviour. On top of that, a significant portion of the management practices taught in MBA programmes is rooted in Theory X. The assumption that employees generally dislike responsibility and require constant direction and external rewards. Our organisations are also structured around Theory X. They are designed for control and for minimising change.

So for a manager in an organisation that suddenly decides to start working “agile”, this can be genuinely frightening. All of a sudden, a new paradigm emerges, one based on Theory Y. A way of thinking in which employees are intrinsically motivated, want to make decisions, need autonomy and initiative, and require far less direction. This is not how most managers have been trained.

So to all agile coaches advocating Theory Y in organisations where Theory X has always been the norm: pause and reflect first. Look for the positive intent and the common ground. Try to understand before you try to convince.

Manage the system not the people

Looking back on my experiences with agile transformations, I am comfortable making one fairly strong claim: everyone wants to be useful to the organisation. This applies across all levels and roles. Yes, there is resistance at times. Yes, people sometimes appear unwilling to move along. But whether we are talking about C-level executives, middle management, or people in teams, very few individuals intentionally display obstructive behaviour.

There are, of course, exceptions to this rule. When that happens, treat them as exceptions. Most managers are simply looking for the right levers to “do their job”. Within the organisational system, they are still held accountable for a large part of the results. Even with Product Owners, cross-functional teams, and Scrum Masters in place, their scope and responsibilities have often not truly changed. The behaviour they show is largely a product of the system they operate in.

From that perspective, I believe most people in these roles are more than open to coaching and guidance. Help them by holding up a mirror when things are not going well. Help them by looking out the window when things are going well. Listen to their struggles with the shift toward self-organisation. Support them in creating the context in which teams and customer focus can thrive. Help them by making obstacles to value delivery explicit and addressing those obstacles structurally.

Culture equals the default choice

Perhaps the greatest obstacle in an agile transformation is the ability to change culture.

Yes, Agile is a mindset. New ways of thinking should lead to new behaviour. To enable this “new” behaviour, structural changes and a different approach to management are often required. When this behaviour is practised consistently over time, a different culture emerges.

This creates a paradox. On the one hand, an agile culture is part of the solution to addressing organisational complexity. On the other hand, the ability to influence culture is also one of the biggest barriers to becoming agile. That can feel like a real struggle.

Does your current culture work against innovation, self-organisation, and fast, early delivery? And if so, are you willing to change it?

As a change agent or leader, start by identifying behaviours that are not aligned with agile principles. Rather than judging them, explore their positive intent and the underlying values behind them. Ask yourself which habits, rules, procedures, or incentives enable or reinforce this behaviour.

These elements provide a strong starting point for cultural change. What would better alternatives look like, or which elements could be removed altogether? Begin influencing your organisational culture step by step.

Lead by Example

Some people say that culture cannot be changed at all. I believe culture is a manifestation of values and beliefs expressed through behaviour. Culture is shared, systemic, and therefore difficult to influence. At the same time, culture is learned, dynamic, and displayed within a specific context.

If something can be learned, it can also be unlearned. If it is dynamic, it can evolve. And if it is shown in a particular context, that context can be changed. When structure changes, culture follows. If structure does not change, culture is far less likely to change.

Another important aspect of cultural change is modelling the desired behaviour. Especially those in leadership positions must practise what they preach. Be the change you want to see in your organisation. The most senior leaders set the tone for behaviour. People watch what you do, what you promote, and what you tolerate.

For everyone else, do not wait for others to change their behaviour. Do not wait for someone else to set the example. You do not need a management position to show leadership.

Radical Candor

When it comes to leading by example, your own behaviour is only one side of the coin. The other side is how you respond to the behaviour of others. Especially as a leader, this may be just as important. It is about what you allow, what you embrace, and what you actively encourage.

In the past, I often worked closely with my former colleague Guus. What I truly value is how openly we hold each other accountable in our work. When I come across as too strict during a training session, he tells me so on the spot. When he moves too quickly past a participant’s question, I immediately point out that the question has not been answered.

To some people, this might come across as direct, blunt, or even intrusive. But when Guus gives me feedback, I know it comes from the best intentions. He cares about me, and we both want to deliver the best possible training. In the same way, he is not offended by my feedback. He appreciates it because he knows it helps him grow and improve.

This concept of radical candour, challenging directly while genuinely caring personally, is something I would love to see more often. It may require a certain level of trust to practise. At the same time, radical candour is also a powerful way to build that trust in the first place.