Agile Transformation

2. Route 1: How lost transformations get back on track

Perhaps you are one of the readers who thought to themselves in parts of Chapter 1: "Oh yes, we should have done that." If your company's agile transformation currently seems to have gotten stuck, the comforting news is: it happens very often. The really good news is: there are ways out of this crisis.

Failed attempts are rarely associated with gaining management's commitment to transformation- this is, in fact, the simplest task in many cases. After getting the green light from management, the typical path may be as follows: one department launches a large pilot project, which is prepared by a core group of agility enthusiasts together with management over the course of several workshops. Following the initial success experienced by the teams involved in agile working, it is agreed that the entire department should be set up in an agile manner. Cross-functional teams are formed, Scrum is the method of choice for operational work, and suitable meeting formats are established to facilitate exchange between the teams. The new structure looks something like in Figure 2.1.

What happens during this process? Departments are dissolved and employees are assigned to the individual products or have to decide on one of the product teams if they are involved in several products. These product teams each have one product owner and are of different size, as the products vary in complexity.

This is where the first difficulties begin to arise: if, like in Figure 2.1, there are teams with 20 members, this suggests that larger products were not consistently shared across several smaller teams. There are, of course, several experts, who should be working in three different teams due to their know-how but are only assigned to one product team. In addition to these professional discrepancies, there are different levels of knowledge when it comes to agile working because in previous years these methods were experimented with in an uncoordinated manner. Either the employees acquired the knowledge themselves, or they attended training sessions with different providers. This is why some product owners and scrum masters have a good command of their work, while others have less knowledge, as they have only just had to take on the new role. Time and again, discussions flare up between these groups about the "right" agile way.

Figure 2.1 Frequently encountered initial business unit structures in agile transformations

To make things completely uncomfortable, a strict timetable is set, and there are neither joint introduction training sessions nor team kick-off workshops. Now, the new product owners and scrum masters are really frustrated and overwhelmed. If anything, there is a town hall meeting at which the pilot project's importance for the organization is emphasized. The scrum masters begin to uncover obstacles so that they can be solved by management.

The transformation is therefore started with energy and enthusiasm, but after a couple of months it runs out of steam because there was nowhere near enough time to prepare. Instead of delivering, many teams are still focused on structures. Some teams, on the other hand, are achieving great results. Coordination between the teams and with management is time-consuming because cooperation is somewhat chaotic. Some get lost in unimportant details, while huge obstacles remain untouched.

The company's management starts to get nervous. Nobody can afford a setback. So, what now?

In this chapter, you will find out how you can

• bring order into the cooperation of several agile teams,
• manage dependencies,
• support people in various agile roles so they can carry out their roles well, and
• realign the agile transformation that has lost its way so that the process can go on.

2.1 Organization and structure

2.1.1 Adapting the scaling approach

How can we provide a better structure for the current set-up and counteract the perceived chaos? At the same time, we want to reduce the coordination efforts and the time they take.

Parallel development of one or more products with several teams at the same time is a highly complex matter in most large organizations. The teams have to coordinate what they are doing with many different stakeholders and stick to elaborate processes. What is missing in most cases is a structure-both technical and in terms of processes-that would enable teams to produce new products or make major changes independently. The simple rules of frameworks like Scrum do not suffice in such cases. This is why companies revert to scaling models, which provide clear guidelines for creating coordination structures. At the same time, these scaling frameworks also advocate the simplification of structures and the handing over of more responsibility to the individual teams (see Chapter 1).

Our rule of thumb is: as soon as more than three or four teams are involved in the process and one of the objectives is to transfer a similar structure to larger parts of the organization, it becomes increasingly complex. Two things are necessary so as not to lose control in this process:

• experience
• time

There is no "one-size-fits-all" model for making larger organizational units or whole organizations agile. Of course, there is no harm in seeking inspiration from one of the scaling frameworks mentioned in Section 1.2.3. However, scaling is a highly individual matter in every organization.

The most important thing is that there is an overarching group driving this change in every step, otherwise the organization will quickly lose its way. This group-we call it the transformation team- sets the common direction (more on this in Chapter 3). Its members define where to start and deal with difficulties that occur during implementation.

The coordination efforts between the teams as well as between the transformation team and management should not be too complex. Regular coordination meetings are ideal for addressing and solving potential team dependencies in a timely manner. Which meetings should be the first?

In a so-called scaled agile environment, where several agile teams should work together in a coordinated manner, it also makes sense for the representatives with the same role in each team to interact with one another. This means:

• The product owners meet to prioritize the deliveries and, if necessary, assign them to the individual teams.
• The scrum masters collect impediments, which impact the whole department, and work on solutions.
• The development teams meet to coordinate how they can deal with content-related dependencies and deliver together at the end of the sprint.

For example, in the structure we described at the beginning of this chapter, there are six teams which are dependent on each other. In this case, it makes sense to start with the Scrum of Scrums approach (see Figure 2.2).

The Scrum of Scrums approach includes a meeting which is also known as "Scrum of Scrums" (SoS): a scaled version of the daily stand-up (or daily scrum). While the latter usually takes place in individual teams, the SoS is extended to several teams.4 In an SoS, representatives of the individual teams address topics which are important for cooperation and can perhaps only be solved at this coordinative level. There are no guidelines as to how often an SoS should take place. However, as a rule of thumb: the greater the overlaps between the individual teams, the more often the meeting should take place. Teams working closely together meet daily in an SoS, but for others a meeting every other day or once a week is enough.

Figure 2.2 Scaling on a team level-start simple!

Product owners should also meet regularly. In many organizations, they gather in a product owner weekly to plan and coordinate the next deliveries. The meeting serves to update the release plan as well as the story map if necessary. The chief product owner (CPO) is just one of the people who attends this meeting to provide updates on the overall corporate strategy or the overarching product vision. Such information usually has a direct impact on the release plan, so everyone cooperates to change it transparently. This meeting can also take place several times a week or daily (product owner daily) if the need for coordination is very high. We recommend that the CPO attends these daily meetings to understand what the current obstacles are. This helps to clarify the ways in which the chief product owner, (top) management, and chief scrum master (CSM) can support the teams' product owners. The sooner the team achieves transparency across the board, the quicker decisions can be made, and the better the transformation progresses.

In the scrum master weekly, the operational drivers of change get together: the scrum masters. They collect the individual teams' problems and search for solutions across the organization. The source for this is the impediment backlog, a list of the obstacles encountered, which each scrum master keeps for their team. Once again, it may be a good idea to bring a scaled role on board, such as the chief scrum master or an agile coach, to secure the link to the organization. We have discovered that weekly intervals are ideal at the beginning. Just like the product owner weekly, the scrum master weekly can also...