Background

Last year when I was looking for new opportunities, I applied in a central support function of a medium-size company in Germany for the position of an Agile Coach. The department head interviewed me and put me to the test by asking how I would start an Agile transformation. I replied that at first, I would start with redesigning the organization and create cross-functional teams. His eyes became wide open, and I could read the sheer unbelief of my statement. Well, it went down the drain from there onwards, and I am happy since the next assignment was more about real change.

My latest coaching assignment was a project that was a product line called project in a big insurance company in Germany. I faced the fact that the organization was already designed by management to reflect their understanding of a well working agile organization when I joined. The management made a true effort to create cross-functional teams (design, coding, testing) but ended up with system-component teams. Each team also had one Product Owner. This transformation was already a "difficult" step for the organization since they had to let go the traditional structure.

First Impressions

Almost immediately when I joined the organization, I could observe a strong local ownership of each team for their system-component. This and the fact that the work-items in the "product backlog" (a list of tasks, functionalities, things to-do in Jira) that could be mapped to system components. All this led to a situation that each team did their job and none of the teams took responsibility for the cross-cutting features and overall product - the global system. In fact the off shore testing team, doing mainly manual testing, that discovered cross system-components faults in the product.

Of course the functionality worked on local machines and in a subset of the automated product testing framework however due to the dependencies between the system components, the functionality was not there even though the teams claimed that they are "done".

Luckily the testing department was in place. Finding those faults brought up another weakness in this organization. Those faults were bouncing around in the organization like ping-pong balls. The typical first reaction was that the faults found from offshore testing were ignored. Then, once a team picked up a fault for analysis, it was quickly realized that this team cannot fix the fault but it has to go to another team. Since the teams had a strong local identity they did not take in "work" from the other teams. The faults were escalated to Product Owners, Scrum Masters, managers and so on.

The fault coordinator (he brought in the faults from the offshore testing team) had an almost impossible task to be heard by the teams. Management saw that nothing comes out, got slowly inpatient and some of the managers started searching for someone to blame. Faults typically made a few rounds before they got finally fixed. It was slow, it was tiring, it was frustrating.

One of the mechanisms to bring some kind of control in this coordination chaos was to establish a strictly facilitated Scrum of Scrums with strict policies (no SM, no PO represents a team). All teams as well as other functions (e.g. architecture, test environment, test tools) were represented in that session. It had a clear focus, the status of the issues was tracked and items got resolved. It was hard work and took time to get it working. Yet, in the end it was working somehow with the main focus on the handling of faults.

Another observation was that measuring progress, as used to in a "normal" Scrum way with burn- down/up charts, was not possible. Instead a heat-map was used where the Product Owners gave their indication of the status in traffic light colors (and % done). As the release date came closer, this heat map was updated on a daily basis by central release management. It was frustrating. It was a mess. And a significant amount of effort was spent daily in just reporting that did not bring the product any closer to releasable status.

As a summary, the set-up with cross-functional system-component teams led to a situation in which:

• No/weak owner ship for the entire product

• No potential shippable product increment at the end of a sprint

• Fixing product faults was very cumbersome

• Measuring progress was not possible with standard agile method

Next Steps

As the release was coming to an end, the planning of the next release started. Now this time, there was no significant pre-analysis work done, no design work was ready, and thus the organization had to start from a pretty clean table by creating the initial Product Backlog. Some slicing work was already started and it continued right where it left - a slicing into system components!

The level of frustration and the pain in management around the topic of team coordination was big enough, and the project manager gave the ok to redesign the team organization once more.

The goal of the redesigning workshop was ... to form cross-functional, cross-component feature development long-lived teams to support the product structure so that

• The work within one requirement area can be done as independent as possible

• The work of one team within a requirement area can be done as independent as possible

Since there were now Agile Coaches on board, self-designing team workshop was arranged. Self-designing team workshop borrowed some ideas from BMW case study (link: https://less.works/case-studies/bmw-group.html). Several experienced facilitators were in present to make this workshop successful. The redesign was only one of the building blocks. Besides that, the initial Product Backlog needed to be created and the initial release plan needed to be established for the communication with the customers.

The organization found suitable dates for all the events and we pulled them through like this:

• half day for redesign the organization

• one and a half day for initial Product Backlog creation

• half a day for initial Release Planning

Besides of these, a series of preparation actions were triggered by these events, and especially it was finally time to define the product and its requirement areas. (That was done before the self-designing team workshop). Furthermore it was obvious that the set-up of one Product owner per team was causing many problems and that needed to be changed together with the definition of the requirement areas.

There was a lot of doubt in the organization and by some Scrum Master that this redesign would ever work and that it would bring benefits at all. To the surprise for skeptics, almost all the goals of this redesign were achieved. The entire R&D organization of about 150 people self-organized within several hours into a new organizational design. Cross-functional, cross-system feature teams were formed in all the requirement areas.

After some initial confusion, the teams started to work pretty well within their requirement areas, and there was measurable progress on the overall product. Almost all the initial scope for this release was included, and the release went out smoothly whereas the anticipated peak of faults did not come.

Why Redesign

One of the key questions is to understand the motivation why to redesign in the beginning?

In the heart of the LeSS framework is Scrum and Scrum is a team based approach to software development. But not any kind of team makes teamwork meaningful. We need to have teams that can be real teams working with the whole team-task that is compelling and achievable. Scrum and LeSS approach to this topic is to form teams that are feature teams which can deliver end-to-end customer functionality. This functionality needs to add value to the customer.

Many organizations which are based on system component teams will have a hard time to deliver value to the customer like in the case I described here. I heard people talk about that redesigning the organization is equal to a "revolution". I wonder whether those people are afraid of the unknown? To me, it is only a natural step. A redesign is not only necessary; it is unavoidable if you really want to get speed and reach Agility.

Once this is understood, experienced and you look back, you will ask the question from the other side. How can you try to make a meaningful Large-Scale Scrum adaptation without redesigning the organization?