When organizations embark on agile transformation, they will at some point have to think about building agile teams. The initial situation in individual companies or IT departments can be quite different; how agile teams are put together and how they relate to each other can turn into a tough challenge.

People often ask me how the organization should position itself with these teams, given the sometimes large number of teams working there. Here I recommend that the organization should focus on what is stable. After all, companies don’t want to constantly rebuild their structure due to changing circumstances. But what is truly stable in our world? In recent years, this has changed – and quite a bit, to the surprise of some people.

In the past technologies were fairly stable!

So, what is stable? What can an organization orient itself towards to gain stability?

As a rule, the product in itself is the stable factor. Needless to say, the product will change. It will be expanded and adapted to the market and continuously updated and optimized. That’s the entire point. But it remains the product. Only when the product is discontinued or replaced by a brand new one – e.g., by a standard product – the organization must change fundamentally or be dissolved.

This answers the first question. The product, i.e. the source of added value, is becoming the focus of our considerations, and the teams should align themselves with it. But products are sometimes very large and many agile teams, some with hundreds of employees, are expected to effectively improve this product. And these teams must be coordinated so that they do not create a tangle of interdependencies in which they get lost.

This kind of coordination is most easily done in verticals. Before I explain how, let’s take a look at the difference between horizontal and vertical organizations. There is a great temptation to use the tried and tested horizontal pattern when forming teams. Just as great is the resulting frustration when the “agile effect” fails to materialize.

Horizontal Organization

A horizontal organizational structure corresponds to the classic project methods and, as a result, to the classic implementation methods (Waterfall).

It is very much designed to work efficiently (by maximizing the division of labor) and as such requires certain conditions, in particular adequate specifications to ensure that the process can be fully planned, stable requirements over a longer product cycle, a stable team of experts, etc. These requirements can no longer be met today due to shorter time-to-market cycles, risks caused by desruptive technologies, the increased complexity of applications, etc.

Horizontal teams organize themselves by function (not functionality) or technology. Functions would be e.g. the operations team, test factory, backend teams, etc. mentioned above. Technologies would be, e.g., a .Net team, an iOS team or Android team, etc.

The characteristics are always the same. These teams are groups of experts for specific functions or technologies, who efficiently manage the parts of the product that they specialize in.

They are not independent in relation to the product, but they are independent in relation to their function or technology. For example, they can easily train new experts in their ranks. However, they do not have an overall view of the product or an end-to-end view of parts of the product; they only know a section of a value chain.

Vertical Organization

In a vertical organization, the teams are oriented towards specific value chains, as mentioned above. This makes the teams inevitably cross-functional. They combine all skills necessary to implement features of a value chain.

Vertical organizations try to be effective (maximizing the focus on one topic) and the most important effect is to enable the ability to commit when the conditions for efficient work are no longer fully in place.

This is meant to make an organization more flexible, because new requirements (topics) can be analyzed and evaluated faster, and vertical (cross-functional) teams have a better overview of the end-to-end functional architecture of the product. The teams work independently in relation to the product, as they are responsible for a specific area of the product end-to-end.

The establishment of a strong DevOps culture is one of the most important goals of agile transformation, which is virtually unthinkable without the introduction of cross-functional teams.

The disadvantages that result from this must of course also be compensated technologically by supporting horizontal structures (CoP, guilds, workgroups), which illustrates that vertical organizations not only have unlimited advantages. They are more a reaction to the changed circumstances mentioned above.

Cross-functional Teams in Verticals

Vertically oriented organizations like to build cross-functional teams.

For many organizations, this already settles the matter, but unfortunately, this does not solve the problem described above. Because one problem remained: How would organizations with hundreds of employees coordinate these cross-functional teams?

At a major insurance company, we are discussing cutting a large monolithic application for motor vehicle insurance into two verticals for private and corporate insurance. I will add the more detailed case study for the bank at the end of this article.

The right cut is anything but trivial and triggers weeks of consideration and, in some cases, heated discussions, because the cut should follow a grouping of the main value chains as closely as possible, but should also do justice to the technical architecture of the application.

And in numerous applications that have grown over many years, this relationship is not necessarily a very harmonious one.

The right cut should therefore be made in several phases, involving as many actors in the organization as possible. I recommend the following steps

Roadmap for a Vertical Transformation

Step 1A: Defining Functional Groups

The first step is to evaluate if setting up verticals is possible at all with this system. Initially, it is important to identify functional groups. At this stage we explicitly don’t want to see yet if the functional groups can be cut into technically independent result types. In this step, we want to adopt a purely functional perspective that can be assumed as independently as possible of all technical constraints and considerations.

This is fundamental to the entire process, so it is important to involve as many areas of the organization as possible. The main role is to be played by the organization’s business analysts, who should have the best knowledge of the application’s functional architecture and are best able to describe all the business processes implemented in it. One could also imagine first creating a list of all business processes and then grouping them together in a second step. The number of groups is not important at first as these can be aggregated again later.

Step 1B: Analyzing the Technical Architecture

Even if the main analysis in step 1 is performed from a functional perspective, an analysis of the architecture can be carried out in parallel and independently at first. Even for a mature monolith, it is worth analyzing if groups of objects can be identified in the architecture that cannot be more effectively encapsulated in the existing monolithic architecture.

Secondly, we should analyze how up-to-date the skills and work structure of the software developers are, followed by who is specialized in what and who focuses on which topics. This also allows us to draw conclusions for possible verticals. At the very least, this type of information is essential for the discussions in the following sections in order to find a consensus later.

Step 2: First Draft for Verticals

The idea here is to combine similar business processes – or business processes that interact very closely – into a vertical. These verticals will later be the responsibility of a group of people who organize themselves into one or more small cross-functional teams (in SAFe this is called an ART, i.e., Agile Release Train).

Of course, these verticals can be of different sizes, and depending on the topics at hand, they can also scale differently. We suggest, of course, that you set the verticals in such a way that

– the verticals are reasonably stable in perspective

– they represent the main business processes well so that the organization gets to know them

– most of the pending topics (requirements) can be clearly assigned to a vertical

Step 3: Validating the Verticals

If verticals have been formed provisionally and from a functional perspective, validation should be carried out within different parts of the organization. The verticals will become the home of teams and team members.

At the same time, they will also serve as a structuring object of communication in the organization, which is why they should be as stable as possible. They will be used as a reference for the requirements analysis, i.e. the entire demand management process, and many KPIs will be mapped to them.

For this reason, there has to be a widespread consensus within the organization. And in perspective, they should also become technically more independent, which is why architects and IT engineers also need to have a closer look. If necessary, adjust the verticals again in this step.

Step 4: Assigning Teams to Verticals

Now that the verticals have been defined, we can assign teams to the verticals. Needless to say that there are different procedures for this: employees may apply for verticals, or they are appointed by the administration, or any other way.

The first one would of course build the commitment of the members, but there may also be reasons for alternatives.

In all cases, the teams must match a real agile pattern, i.e., they should be cross-functional, with no more than 9 members, who are supported by a Product Owner and a Scrum Master

Step 5: Making the Verticals Functional

Defining and setting up the verticals is not the end of the story. Now the verticals need to become functional. In this context, there are still some factors to be reconsidered and set up. The analysis in phase 3 should reveal exactly what these factors are.

In principle, the following questions need to be addressed: – Does a vertical have a Business Owner (or Chief PO, or whatever this role is called)? My recommendation: Yes – How do you handle the remaining technical dependencies of the technical artifacts? My recommendation: Create a roadmap for the extraction of result types for their functional units from each vertical. What will the demand management process look like in the future and how can the verticals be integrated effectively?

More questions can of course be added at will. But then we can get started. The ART should discuss and possibly adjust the layout regularly during the first PI planning sessions until stability is established, and all teams can work effectively with the organization.

Case Study

Of course, there were still dependencies between the verticals, especially between SEPA and services or investment and services – both functional and technical. A close exchange among the POs in the verticals needed to be established and maintained (cross-team refinements, PI planning, etc.). There were requirements (e.g., GDPR) that affected all verticals at the same time as well.

During the second step, the cross-functional teams were formed. Cross-functional here refers to the implementation of the UserStories planned in a team. Each vertical consisted of 2 to 4 teams with no more than 9 members each. Each team had developers, backend developers, testers – both for iOS and Android.

At the ART level, i.e., outside the teams, there was an upstream “Ideation Team” (business analysts), which worked on the issues of the coming stages and prepared the next PI Planning together with the POs of the teams (Epics).

As a result, PI planning became much more effective and the teams were much better prepared for upcoming topics, which meant that the topics could be implemented more quickly, but above all they were already appreciated in PI planning, so that management could prioritize clearly.

During the third step, the setup was tested in one stage. Particular emphasis was placed on finding out how the cross-functionality of the teams works.

Would it be better to have a team of mixed iOS and Android developers in the vertical, or a dedicated iOS team and Android team respectively? How will architects from the organizational level be involved? How are dependencies between teams resolved? How will horizontal structures such as CoPs and guilds work?

The results were addressed in every PI Planning. In addition to technical topics, PI Planning also dealt with topics concerning the Agile Setup, infrastructure topics, HR topics, etc.

Conclusion

After the switch to verticals, we noticed a significant improvement, especially in the areas of output/performance, employee satisfaction, production awareness and forecasting. It must be said, however, that many additional measures were adopted with the division into verticals.

The improvements cannot be attributed solely to the formation of verticals and it is virtually impossible to quantify the share of the verticals.