‍

Horizontal walls between teams result in reduced velocity

‍

The conversation on velocity can be traced back to the 1990s when agile software development first emerged as a solution for managing unwieldy waterfall projects. This approach helped companies streamline their development processes and minimize losses in the event of major changes to the project. 

Yet the historic focus on agility, when defined as time to respond to change, does not always translate to getting an outcome to market at the same speed as startups. Today velocity still remains a critical issue for larger organizations that lack the capability of startups to rapidly recognize, implement and evaluate change. 

One key advantage of startup architecture is small, close-knit teams that are able to make decisions locally. In larger organizations, there is often a wall between frontend and backend teams. Frontend and backend teams tend to execute their roadmaps independently on their side of the wall. 

Microservices architectures have tried to address this gap within backend teams by aligning cross-functional teams and processes around a business subdomain like registration or billing. For example, microservice teams own the code, domain logic, complexity, infrastructure, and decisions, and expose those solutions as API contracts on the API Gateway. The current challenge is to align frontend teams with this integrated vision.

‍

Leveraging tech to create vertical teams increases velocity

‍

Adapting the architecture of large organizations to accommodate local decision-making within teams is one powerful way to increase velocity. Small teams in startups tend to have a local understanding of the problem space and greater ownership of the roadmap, budget, and project timeline. When teams within larger organizations are empowered to take and execute decisions locally, objectives are accelerated and greater value can be delivered to the end-user. 

‍

In our work with our clients, leveraging tech has emerged as the foundation for creating truly vertical teams that can execute right through to the end-user. One example scenario is a company that needs to increase new user registration to its platform by 50% to hit its financial targets for the year. Enabling a vertical team to work on this project has clear advantages since there is a full range of competencies within the team to deliver results, ranging from frontend developers and growth engineers to UX experts and marketing professionals. 

In the section below we will explore in more detail how a solid technical foundation is the first step to ensuring greater velocity in large organizations. We will then examine how to create vertically-aligned teams that align with the company’s specific customer journey and goals. Finally, we will look at how cultural shifts regarding responsibilities and budgets can support these changes to enhance performance even further. 

‍

Three Steps to Greater Velocity

‍

‍

Step 1: Build a technical foundation that allows teams to act independently

‍

Large organizations can leverage tech to build in isolation between different subdomains in their platform. This enables teams to act independently without disrupting each others’ progression. 

‍

In most large software development companies, frontend teams build monolith Android, iOS or web applications. Android, iOS and Web teams work on creating different applications or sites. An alternative approach is microfrontend applications consisting of a shell application that loads in isolated, subdomain-scoped applications (see Fig.1). These applications are owned by a specific domain team that executes vertically. 

These microfrontends should be isolated from each other to enable them to evolve independently, communicating only with well-defined messages. Within these teams, ownership and responsibility are aligned, and onboarding time and training efforts are streamlined since greater understanding of that specific domain develops with each team.

A microfrontend architecture can be created by first creating one microfrontend from the legacy application. The next step is to extract a new microfrontend based on the domains that have been identified. Ownership is then migrated to the domain team. This process repeats until the original monolith ceases to exist.

‍

Step 2: Introduce vertically-integrated teams that independently own an entire customer journey

‍

Creating true multidisciplinary teams which incorporate frontend and backend capabilities, including all the relevant functions required in the domain, is another key to greater velocity. Once a solid technical foundation has been created, teams should be aligned with how the company’s specific customer journey works. In Fig. 2 we have included an example of a cross-functional domain team that incorporates the full range of capabilities required, and how that might fit into a domain-based architectural model.

‍

Step 3: Initiate cultural changes that give teams greater ownership and initiative

‍

Cultural changes within the organization can also support greater velocity by enabling teams to act locally and take greater ownership. Companies can achieve this by increasing openness about budgets, responsibilities, and accountability within the project. Exposing teams to this type of information empowers them to prioritize projects which deliver the most value to the company while also minimizing the financial risk of pursuing dead-end initiatives.

‍