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!
As a result, we had front-end departments, back-end departments, test factories, database teams, UI/UX teams, etc. In many cases, these teams consisted of entire departments! Of course, this makes it difficult to work in a cross-functional way. And technologies are constantly changing.
Yesterday Struts, today Angular or React, tomorrow vue.js. Yesterday manual testing, today test automation. Yesterday native iOS and Android, today React Native and Progressive Webapps. You get the drift.
Even the topics, including the big ones, are constantly changing. GDPR initiatives, major migrations, introducing mobile payment at a bank, implementing new booking classes at an airline, etc.
And finally, people are also changing: employee turnover has increased, the use of offshore/nearshore teams has become more appealing to organizations, and many are working with external freelancers or service providers.
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.
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.
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?
The answer is obvious and easy to guess: vertical. However, this is not at all easy to achieve in practice. Especially if the product is a large monolithic application, a build with millions of lines of code. After all, only if an organization is agile, it won’t be immediately capable of completely redesigning the monolith, e.g. into micro services.
In order for these teams to be able to work more or less independently, they have to be coordinated accordingly, and this is easier in verticals than in a horizontal direction. The large, monolithic product thus also has to be “cut” into verticals.
Of course, “cut” does not mean in a technical sense, because this only concerns the assignment of certain function groups to teams. In this way, for instance, we cut the mobile banking app of a large German bank, where about 100 developers in 12 agile teams work in three verticals (SEPA transactions, investment and services).
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.
Introducing Verticals for Mobile App Teams in a Bank
- Initial Situation
In the bank’s digital factory with around 80 to 100 employees (90 % external), they develop the mobile banking app, among other things. The app is connected to the core banking system in the back end and implements significant use cases, which are also mapped in the online banking app or in bank branches. This resulted in large technical and functional dependencies to other systems (e.g., technical to core banking, functional to online banking). In addition, the mobile app was distributed on two platforms (iOS, Android), meaning there were two technical versions. The ART (Agile Release Train) “Mobile” had organized itself in a very horizontal way, i.e., there were separate iOS teams, Android teams, test teams, infrastructure teams, backend teams, system teams, UI/UX teams. This led to major problems in terms of performance, dependencies, production awareness and production support, release planning and quality and forecasting capability for other major features (e.g. GDPR, implementation of ApplePay).
The introduction of verticals aimed to solve the following problems:
– The dependencies between ART teams should be reduced by allowing teams to take vertical responsibility and implement features independently end-to-end and cross-platform
– Despite a large number of external employees (with a strong turnover), adequate domain knowledge needed to be built in the teams so that critical bugs or new functionalities could be evaluated more quickly, and the onboarding of new employees should be simplified.
Through the cross-functionality of the teams in the verticals, the agile mindset should be strengthened, i.e., teams should be able to work in a more self-organized and self-responsible way.
In a first phase, an attempt was made across the ART with all relevant stakeholders (business analysts, architects, management, Agile Master) to define verticals that are both technically feasible and, above all, functionally useful. This definition phase took about 6 weeks to find a workable compromise. Three verticals were defined:
– SEPA transactions: All classic banking functions (account management, transfers, etc.)
– Investment: All functions related to investment portfolios
– services: All functions dealing with general services (password changes, address changes, settings, authentication, etc.)
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.
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.
cannot be attributed solely to the formation of verticals and it is virtually
impossible to quantify the share of the verticals.