How do you make an agile transformation succeed?
By Geert Eggens
Organisations have high hopes for their agile transformation. Yet after the initial successes, many organisations often find that their agile transformation gets stuck. The enthusiasm among employees, management and customers disappears. Improvement stalls or things even get worse. In this article, our experience of what often goes wrong and how to prevent it.
Traditional organisations work and manage hierarchically as shown in the lower left quadrant. In the hierarchical situation, it is the managers who tell the employees on the shop floor what to do. This can work well in itself, but organisations today already have to react faster. Hierarchical organisations struggle here. Because contact with the practice takes place precisely on that shop floor. The hierarchical machine simply runs too slowly to first detect these changes, take decisions on them and then direct them on the shop floor. Moreover, the larger the organisation, the more management layers, the more hierarchy and thus the greater this delaying effect. Commercial and government organisations thus get into serious trouble. The solution direction: more of the decision-making should be delegated so that the shop floor can organise and decide more itself. Agile design principles offer this by forming self-organising teams that can make their own decisions. An agile transformation transforms a company from hierarchical departments to such teams.
For the purpose of transformation, many organisations focus on setting up agile teams. In a few months, teams learn the basics of agile working forms like Scrum or Kanban from hired coaches, for example. After that, they "work Agile". Surely the shop floor now does everything in the Scrum guide?
But although operational teams were then formed in this way, no changes were made in the governance of the organisation. Annual plans continue to be made in concrete by the top. Decisions still run along the line and are made in steering committees and meetings outside the teams. Managers still have all the resources at their disposal and can use them to set the direction as much as possible. Project leaders have power that overrides that of product owners and scrummasters. Architects and other specialists make decisions for teams rather than with teams. Very little of the desired fast decision-making on the shop floor gets off the ground.
Control and management hierarchy is still unchanged. As teams grow and already get better at applying agile working, this tension is already increasing. So you end up in the top left quadrant of the diagram: an organisation with agile teams but with an unadapted, still hierarchical control system. This leads to even more frustration and conflict within the organisation. What is a team allowed to do and what not? Who is in charge of what? How much freedom is there really? Do we really take teams and self-organisation and agile values and principles seriously? This is already leading to more friction between working and governing. The transformation gets stuck, does not deliver the desired faster response and tensions rise in the organisation.
A second transformation approach is precisely to go "agile" very quickly. Based on principles such as facilitative leadership, management wants to start empowering the shop floor as soon as possible. They deliberately give a lot of freedom and quickly abolish the old steering mechanisms.
What happens? Architects are quickly stripped of their powers and the architecture board disbanded, project leaders are retrained and management henceforth says "come up with a proposal yourself" or "sort it out yourself" for every question from teams. But ... the fresh agile teams are not at all ready for this independence.
What is the consequence? Teams experience a lack of direction. What are they supposed to do? How are they supposed to do it? There are suddenly no more frameworks that give direction, anything seems to be allowed! Nor are there any more support people to ensure quality, coordinate matters or oversee the whole. The teams go in all directions. This may give a lot of flexibility, but the quality of products and services deteriorates. There is little or no synergy. Inefficiency is rapidly increasing. There is unrest because people experience a lack of direction.
This second form of stalled transformations follows precisely the horizontal route in the figure, i.e. transformations that end up in the lower right quadrant. There is a lot of flexibility, but it is not transformed into productivity, quality and shared direction. The organisation loses track and is in danger of "falling apart".
So how do I transform successfully?
To successfully go through an agile transformation, both agile teamwork and agile governance need to be adapted in relation to each other. The organisation always takes small steps that allow it to grow in both directions:
- Vertical: increasing self-organising ability of teams - change from hierarchical working to agile working
- Horizontal: increasing facilitative leadership - from hierarchical management to agile management.
But how to do it?
A vision and strategy and associated frameworks are the basis from which a transformation can start. A transformation map recognises steps in both agile working and agile governance.
As a next step, agile learning can be used. Teams are formed and first learn the basic tricks of agile working. Then pieces of the governance are adapted and placed more on the teams. For example, simple projects and low-impact architecture decisions can be left to teams. As the teams' experience progresses, more and more responsibility falls to the teams and the steering adjusts accordingly. Matters such as portfolio management, project management, account management, resource management, security and architecture, for example, lend themselves to being done more and more together with the teams, with steering taking on an already more facilitative form.
In all of this: measuring is knowing! A regularly conducted 'agile transformation assessment' offers a solution here. Measurements are formulated on both agile working and steering, to check where one is on the axes. Fine-tuning the speed at which this happens can also be done precisely in consultation with the teams.
So a successful transformation pays attention to maintaining a continuous balance between agile working and matching agile governance and makes incremental steps in this. Easy to say, but certainly not easy to do. A good understanding of change management, agile working and agile governance are essential ingredients for a successful agile transformation. Experience from others helps enormously in this respect, but ... every organisation is unique and needs to find its own path.