When organizations embark on an agile transformation, at some point, they will have to think about forming agile teams. However, the starting point in individual companies or IT departments can be quite different. Therefore, how agile teams are composed and relate to each other can become a tricky challenge.
So I am often asked how the organization, which sometimes has a lot of teams, should set itself up with these teams. I recommend that organization orient itself towards what is stable. After all, you don’t want to rebuild your organization structurally because some circumstances have changed constantly. But what is stable in our world? This has changed quite a bit in recent years, to the surprise of some.
In the past, technologies were relatively stable!
As a result, there were frontend departments, backend departments, test factories, database teams, UI/UX teams, etc. Often these were not teams at all but whole departments. But, of course, you can’t work cross-functionally like that. Moreover, the technologies are constantly changing: yesterday Struts, today Angular or React, tomorrow vue.js, yesterday manual tests, today test automation, yesterday native iOS and Android, today React Native and Progressive Web Apps, and so on.
Also, of course, the themes, even the big ones, are constantly changing. DSGVO initiatives, extensive migrations at a bank, the introduction of mobile payment at an airline, new booking classes, and so on.
And finally, people are also changing, and staff turnover has increased. As a result, using offshore/nearshore teams has become more interesting for organizations; many works with external freelancers or service providers.
So what is stable? What is stable for an organization to align itself with? It is usually the product itself that is stable. But, of course, the product will change. It will be expanded and adapted to the market, constantly modernized and optimized. That is the whole point of the exercise. But it remains the product. Only when the product is wholly discontinued or replaced by a completely new one – e.g., a standard product – does the organization have to change fundamentally or even dissolve.
This settles the first question. After that, the product, i.e. the source of value creation, moves into the focus of our consideration, and the teams should align themselves precisely with it. Now, products are sometimes vast, and many agile teams with sometimes hundreds of employees are supposed to develop this product effectively. And these teams need to be orchestrated, so they do not create a tangle of interdependencies and get lost.
This orchestration is most easily done in verticals. Before I go into how we can do this, let’s reflect again on the difference between horizontal and vertical organizations. Using the tried and tested horizontal pattern when forming teams is tempting. However, the disappointment later when the “agile effect” fails to materialize is just as remarkable.
Horizontal organization
A horizontal organizational structure corresponds to the classic project methods and, thus, to the traditional implementation methods (waterfall).
It is very much designed to work efficiently (maximizing the division of labour) and therefore requires certain preconditions, in particular sufficient specifications that ensure complete planning of the process, stability of requirements over a longer product cycle, stable teams of experts, etc. However, preconditions are no longer given today because of shorter time-to-market cycles, risks from disruptive technologies, increased complexity of applications, etc.
Horizontal teams are organized along functions (not functionality) or technologies. Functions would be, for example, the operations team, test factory, backend teams, etc., already mentioned above. Technologies would be, e.g. .Net Team, iOS Team / Android Team, etc. However, the characteristics are always the same. Such teams are groups of experts for specific functions or technologies who highly efficiently take care of the parts of the product for which their skills are specialized.
They are not independent in terms of the product but separate in terms of their function or technology. For example, they can quickly 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 the value chain.
Vertical organization
In a vertical organization, the teams are oriented toward specific value chains, as mentioned above. This makes the teams cross-functional, combining all the skills necessary to implement value chain features.
Vertical organizations try to be effective (maximizing the focus on one topic), and the most significant effect is to create commitment capability when the prerequisites for efficient work are no longer fully available.
This should make an organization more flexible because new requirements (topics) can be analyzed and evaluated faster, as vertical (cross-functional) teams have a better overview of the end-to-end technical architecture of the product. In addition, the teams work independently with the product, as they are responsible for a specific area of the product end-to-end.
Establishing a strong DevOps culture, one of the essential goals of an agile transformation, is hardly conceivable without introducing cross-functional teams. However, technologically, the disadvantages that naturally result from this must also be compensated for by supporting horizontal structures (CoP, guilds, workgroups), which shows that vertical organizations do not have advantages only and without restrictions. Instead, they are a reaction to the changed circumstances mentioned above.
Cross-functional teams in verticals
Vertically oriented organizations thus like to form cross-functional teams.
For many organizations, this is already the end of the matter, but unfortunately, it does not solve the problem described above. The problem was how organizations with many hundreds of employees orchestrate these cross-functional teams. The answer is, of course, prominent and easy to guess: vertically. And yet, in practice, this is not so easy to do. Especially not if the product is an extensive monolithic application, i.e. a build with millions of lines of code. Because only if an organization adopts an agile approach will it not be possible to redesign the monolith into microservices, for example, completely.
For the teams to work more or less independently, they have to be orchestrated accordingly, which is easier in verticals than horizontally. Therefore, the large, monolithic product must be “cut” in verticals. Of course, “cut” does not mean cut technically because it is only a matter of assigning certain functional groups to teams. In this way, we have, for example, cut the mobile banking app of a large German bank into three verticals (SEPA transactions, investment and services) with about 100 developers in 12 agile teams. At a large insurance company, we are currently discussing a cut for an extensive monolithic application for motor insurance, a cut into two verticals for private and corporate insurance. At the end of this article, I attach a slightly more detailed case study for the bank.
The right cut is anything but trivial and triggers weeks of deliberation and sometimes heated discussions because the cut should follow a grouping of the leading value chains as much as possible but at the same time also do justice to the technical architecture of the application. And in many applications that have grown over the years, this is not necessarily a very harmonious relationship.
So we should do the proper tailoring in several phases, involving as many stakeholders in the organization as possible. So my recommendation would be the following steps:
Roadmap for vertical transformation
Step 1A: Definition of functional groups
The first step is to evaluate whether it is possible to set up verticals through the system. The first step is to identify functional groups. In this step, it is explicitly not yet a question of seeing whether we can also cut these functional groups into technically independent result types. Instead, this step aims to adopt a purely practical perspective that we can take as independently as possible from all technical constraints and considerations.
Since this step is fundamental to the whole process, as many parts of the organization as possible should be involved here, the leading role should be played by the business analysts of the organization because they should know the technical architecture of the application best and be able to describe all the business processes implemented in it best. It is conceivable that first, a list of all business processes is created and that these are grouped in a meaningful way in the second step. The number of groups is irrelevant for the time being because the groups can be further aggregated later.
Step 1B: Analysis of the technical architecture
Even though we should conduct the primary analysis in step 1 from a functional perspective, a study of the architecture can also be performed in parallel and initially independently of this:
- Even for an evolved monolith, we should analyze whether we can identify object groups in the architecture that we cannot better enclose even in the existing monolithic architecture.
- It should be analyzed what the software developers’ current skill and work structure look like, who specializes in what and who focuses on which topics.
- We can also conclude possible verticals from this; at least such information is urgently needed for the discussions in the follow-up cuts to find a consensus later on.
Step 2: First draft for verticals
The idea is to group similar business processes that interact closely into a vertical. These verticals should later become the responsibility of a group organized into one or more small cross-functional teams (in SAFe, this is called an ART-Agile Release Train). Depending on the issues, these verticals can vary in size and scale. It would, of course, be advisable to set the verticals in such a way that.
– The verticals are reasonably stable in perspective
– Represent the main business processes well, and the organization becomes familiar with them
– Most of the upcoming issues (requirements) can be assigned to a vertical.
Step 3: Review the verticals
Once the verticals have been formed provisionally and from a functional perspective, validation should occur within different parts of the organization. The verticals will become the home of teams and team members. At the same time, they will also become the structuring object of communication in the organization, which is why they should be as stable as possible. They will be seen as a reference for the requirements analysis, i.e. the entire demand management process, and we will map many KPIs on them. Therefore, a broad consensus is needed in the organization. And in perspective, they should also become more technically independent, which is why the architects and IT engineers also need to look at them. If necessary, we should adjust the verticals again in this step.
Step 4: Assigning the teams to the verticals
Now that the verticals have been defined, the teams should be assigned to the verticals. There are different procedures for this; employees may apply for verticals, or they are determined administratively, or whatever. The former would, of course, pay off in terms of the members’ commitment, but there may also be reasons for the other variants. In any case, the teams should follow an agile pattern, i.e. they should be cross-functional, with no more than nine members, who are assisted by a product owner and a scrum master.
Step 5: Establish the workability of the verticals
Defining and setting up the verticals is not the end of the story. Now the verticals have to become workable. There are still a few points to be considered and set up. An analysis in phase 3 should reveal exactly what these are. First, however, we should clarify the following questions: – Does a vertical have a business owner (or chief PO, or whatever he is called)? My recommendation: Yes – How are the still existing technical dependencies of the technological artifacts dealt with? My recommendation: A request should be made from each vertical for a roadmap of the extraction of result types for their functional units – What will the demand management process look like in the future, and how can the verticals be effectively involved here?
Further questions can, of course, be added at will. However, then things can get underway. During the first PI planning sessions, the ART should regularly discuss and possibly adjust the structure until stability is found and all teams can work effectively with the organization.
Case Study: Introduction of Verticals in a Bank for Mobile App Teams
1. Initial situation
In the Digital Factory of the bank, approx. 80 to 100 employees (90% of whom are external) develop, among other things, the mobile banking app. This is connected to the core banking system in the backend and implements many use cases that are also mapped in the online banking app or branch banking. This resulted in significant technical and functional dependencies in other systems (e.g. technically in core banking, functionally in online banking). In addition, the mobile app was distributed across two platforms (iOS and Android), so there were two technical versions. The ART (Agile Release Train) “Mobile” had organized itself much more horizontally, i.e. there were separate iOS teams, Android teams, test teams, infrastructure teams, backend teams, system teams, and UI/UX teams. This led to significant problems in terms of performance, dependencies, production awareness and production support, release planning and quality, and forecasting capability for other essential features (e.g. DSGVO, ApplePay rollout).
2. Objectives
The introduction of verticals should essentially solve the following problems:
We should reduce the dependencies between the ART teams in that teams can take on vertical responsibility and implement features independently and end-to-end and cross-platform.
Despite many external employees (high fluctuation), we should build up sufficient domain knowledge in the teams to evaluate critical bugs or new functionality more quickly and facilitate the onboarding of new employees.
The cross-functionality of the teams in the verticals should strengthen the agile mindset, i.e. teams should be able to work in a more self-organized and self-responsible way.
3.Implementation
In the first phase, all relevant stakeholders (business analysts, architects, management, agile masters) across the ART tried to define technically feasible and functionally meaningful verticals. This definition phase took about six weeks until we found a workable compromise. Three verticals were explained:
SEPA transactions: All classic banking functions (account management, bank transfers, etc.)
Investment: All functions related to investment portfolios
Services: All functions dealing with general services (password change, change of address, settings, authentication, etc.).
Of course, there were still dependencies between the verticals, especially between SEPA and services or investment and services, which were both functional and technical. A close exchange of POs between the verticals had to be ensured (cross-team refinements, PI planning, etc.). Of course, there were also requirements (e.g. DSGVO) that affected all verticals simultaneously.
In the second step, we formed cross-functional teams. Cross-functional refers to the implementation of the user stories planned in a team. Each vertical consisted of 2 to 4 groups with a maximum of 9 members each. Each Team had iOS and Android developers, backend developers, and testers.
At the ART level, i.e. outside the teams, there was an upstream “ideation team” (business analysts) who prepared the topics for the upcoming stages and worked together with the POs of the teams to design the next PI planning (epics). This made the PI Planning much more effective, and the teams were better prepared for upcoming topics, which meant that we could implement the issues more quickly, but in particular, were already estimated in the PI Planning so that the management could make a clear prioritization.
In the third step, we tested the setup in a stage. In particular, the aim was to determine how the teams’ cross-functionality works.
Is it better to have a team with mixed iOS and Android developers in the vertical or an iOS and Android team? How are architects from the organizational level involved? How are dependencies between the teams resolved? How will horizontal structures in the form of CoPs and guilds work?
We discussed the results in each PI planning session. In addition to technical topics, the PI planning sessions also focused on issues relating to the Agile setup, infrastructure topics, HR topics, etc.
Conclusion
After the transition to verticals, we perceived a significant improvement, especially in output/performance, employee satisfaction, production awareness and forecasting ability. However, it has to be said that we adopted many other measures with the division into verticals.
The improvements cannot, therefore, be attributed to the formation of the verticals alone, and it is hardly possible to put a concrete figure on the share of the verticals.
