Five mistakes in Scaling Agile

Large companies are particularly looking for quick and easy ways to make the transition from traditional to agile development. The faster a transition should take place, the more dangerous are the pitfalls that are overlooked. Agile development relies more on sustainability than simply getting things done quickly. Therefore, management has a great responsibility for the success of the agile transition. On the outside, the transition looks successful, but on the inside, the benefits of the transition are not.

Here we have summarized five common mistakes on the way to an agile organization:

1. Fundamental Agility

The transition to agile processes is easy. You deregulate a little and send some people into training. After that people can “do Scrum” – or choose another agile approach. But seen as a whole, you may have reached 1% – 99% of the way is still ahead. The journey is still long. At the heart of agility is the Inspect+Adapt process.

To make it work, you need a special mindset. Everyone has to relentlessly question what’s happening – and make changes when things go in the wrong direction. In order to anchor Inspect+Adapt meaningfully in the organisation, two things are needed:

First, the existing way of working must be detoxified. Elements of the corporate culture that discourage developers from taking ownership of their processes must be removed. To do this, many Command+Control processes have to be thrown out and the management of developers has to be fundamentally rethought. Change will only happen if it is allowed!

After that a healthy way of working must be created. You need a management system that encourages developers to take responsibility for their own actions, decisions, changes, failures and successes. This requires the creation of structures and processes that honestly value the individual contribution of each person – regardless of whether management is satisfied with the direction in which they are going or not. People will only make their contribution if you let them!

Until the foundation for agility is laid, there will be no agility. Teams without fundamental agility will neither benefit from nor contribute to agile scaling.

2. Tools and Techniques

To introduce the ceremonies of Scrum takes just one day, including training and the decision. This gives you the basis for “agile work”. Short-term planning, regular updates of the plan, product feedback and incremental improvement in the process are essential. Over time, the developers can find out the optimal way to work. You just have to plan a lot of time for optimization if the engineering practices are not yet established. Developers need to be familiar with concepts such as version control, continuous integration, test automation, emergent design, TDD, BDD, pairing, code conventions – and much more that XP has to offer. They must consciously decide which of these practices are helpful to them in the current context. As long as the developers are not familiar with these practices, they may very well be “ritually agile”, but not practicing agility. A team without the right tools can even slow down the implementation of scaled development.

3. Team spirit

The team spirit, often smiled at as esoteric, is immensely important for systemic improvement in agile scaling. Many managers think that personal targets (up to stack ranking) are helpful to get high performing employees. Agile scaling, however, primarily serves to build a complex, adaptive system in which many people contribute. The need to contribute to the big picture is far more important than contributing to your own goals. Here, “team spirit” means that individuals must always subordinate their own interests to further the mission of the company. Team spirit is less about “doing fun things with others” (e.g. team events such as rafting, go-karting or paintball). It is primarily about having fun doing things that help to move forward together.

Developers need two things to do this: First, they need to know how they can contribute. Because this depends very much on the individual case, the contribution is primarily self-organization and intrinsic motivation. Secondly, they must know that helpfulness is worthwhile. Anything that creates a personal disadvantage in helping others to achieve a common goal must be removed. A classic example of “team spirit” is football: we have often seen that the game is not won by the best player. The winner is the best team. It’s the same in development: aces that outdo each other don’t win. You win by combining forces, pooling ideas and moving forward together. Groups of developers without team spirit waste their energy on “employment”. A scaled group that is not a team uses only a fraction of its potential to achieve the common goal!

4. Transparency

Many organisations fail due to a lack of knowledge of the overall system. They cannot optimize globally. Classical obstacles to transparency exist at all levels: From the developer who does not know how a colleague’s work affects him or her to the manager who cannot say what the Absolute Prio 1 is. This lack of transparency leads to many problems. It starts with the developer, who unconsciously torpedoes the work of his colleagues, and extends to whole teams working on the wrong things. None of this is desirable and the more often something like this happens, the more critical and important it is to increase transparency.

Some organizations waste almost all of their capacity to manage problems caused by lack of transparency. In such situations, “drudging” is probably a more accurate description than “scaling”. There are many levers for increasing transparency to the point where scaling makes sense. Some of them are:

• Put on a Kanban – that everyone can see!

• A central backlog from which all teams help themselves

• Collective Code Ownership as a basis for “communication through code

• Andons: Build Monitoring and “Stop the Line” based on automated tests

• Joint planning and joint reviews in which only the integrated product is shown

Transparency is anti-proportional to overhead and problems. In other words: With agile scaling, transparency is proportional to ROI. Agile teams that lack transparency do not make a meaningful contribution to the business goals.

5. Focus

In many organizations, one of the main problem is a wrong focus on workload: you manage work and bring tasks to employees. The basic assumption here is that you create value by keeping everyone “busy” to the maximum. In an agile organization, it’s the other way around: we bring people to work that is worth doing. We know that there is no positive correlation between value creation and workload. We focus on delivering a usable product – getting things done. A classic problem in many organizations is that by trying to get people working to capacity, many things are “in the works”: This requires task switching and coordination. But even in the most trivial scenarios, the resulting loss of focus leads to massively reduced ROI and significantly increased lead times: We spend too much time trying to figure out why nothing is finished – and too little time trying to get something finished.

The main idea behind focus is: It costs much less to do the wrong thing first and then the right thing afterwards – than to do two things at the same time. As trivial as this sounds, it is difficult to implement: The entire organization needs a clearly sorted list of goals, and each goal must be clearly prioritized. There is exactly one single Priority 1. Next, “Work in Progress” must be strictly limited. Focus requires managers to fundamentally rethink their attitude: accept that “idleness” costs less than overload. Nor can you get everything at once. Unfocused teams may be “well utilized” but are highly ineffective. The less focused, the longer they take to create value.

Summary

“Agile scaling”, which does not care about the aforementioned traps, will most likely become a cargo cult. On the outside, the transition looks successful, but on the inside, the benefits of the transition are missing. For successful agile transitions, a common approach is to bring on board experienced experts who have “fought on the front lines” and already know the traps.
To avoid the traps in a scaled environment, we recommend:

• Management support for the transition. To close the traps, some things in the organization have to be turned upside down. This requires full support from management.

• Build an Agile Transition Team (ATT) in which both managers and developers are involved. The ATT has a clear change backlog that everyone is working on together.

• Executive Coaching for the key people in the transition. This includes line managers as well as product owners and scrum masters. The external coach needs experience in agile scaling!

• Technical Coaching helps the teams to get the right tools faster: This pays off very quickly with a higher quality product!

• Hire a consultant to lead the transition. This person must know exactly what he or she is doing and must work without compromise. He must have the power to push through even unpopular changes.

• Training for all in agility. In a safe training environment, the impact of the transition is much easier to communicate.