Just like any change, the road to agility presents organizations with many questions and doubts. To counter any uncertainty that may arise, many transformation owners exchange thoughts and ideas amongst themselves. They compare their approaches in order to gain new insight they can apply to their own projects. One of the main comparisons is how transformations are being realized. This can include, for example, the number of teams following a scrum approach, the existing hierarchy levels or the quality of the Kanban boards hanging on the walls of their office. The problem: the progress of agile transformation is often measured in numbers that reflect a method, instead of goals trying to be reached.

Since agility itself refers to an organization’s ability to flexibly adjust to customer and market demand, agility maturity should, in turn, be measured based on customer and market data. Companies can do so by figuring out exactly which market challenges they are trying to master through agility and which challenges posed by specific target groups can be resolved in doing so.

Nowadays there are numerous frameworks and case studies all suggesting that the implementation of agility can be planned and that there is a right way to do it. In reality, however, the number of influence factors is so high that you cannot actually plan which action will lead to a specific reaction. Models and calculations rarely provide certainty. Instead, a trial and error approach is gaining traction.

That is why agile transformation should not simply follow some off-the-shelf plan, but should be systematically implemented in an agile manner as well. This can be achieved, for example, by describing your vision of the future. You can then get closer and closer to that vision through iteration, meaning: try, review and improve.

Agility is often equated with the introduction of agile methods, like scrum. As soon as typical roles and work principles are implemented, companies suddenly start talking about successful transformation. However, that is when the real work starts. Agility is not just a work method, but a question of mindset and since it is often contrary to traditional workflows, conflicts can arise. A few examples include

• Once teams start working together cross-functionally, at some point the question arises as to whether organizational structures need to undergo even more change.
• If, for example, scrum teams are introduced that begin working according to the new methods, the traditional understanding of leadership is often critically questioned.
• As the focus turns more and more toward team performance, any individual goals that have been set may become less and less important.

Consequently, companies need to think multi-dimensionally if they want to achieve agility. Any time a change is made, attention should be paid not just to the agile processes, but to how the change affects the structure, strategy, management and HR tools.

“That doesn't work with my people!” This is a common excuse when agile transformation comes to a standstill. Delegating more responsibility and decision-making power to teams initially makes sense to everyone involved. If, however, decisions are not made or are made poorly, there is often an impression that employees did not want to or were unable to take on the responsibility. To understand the problem, it is important to view the situation from their perspective: why were they unable to make a decision? Often times, the cause is not simply an inability to make a decision, but is the result of external influence factors. In such cases, the framework has to be changed so that the behavior can change.

Companies should ask themselves if employees have enough room to grow and can delegate the responsibility that has been assigned to them. It is also a good idea to check whether employees have all the information they need to make a business decision.