Composing teams in Scaled Agility


Lukas Rüdlinger, Senior Consultant

Agility has arrived in companies. Either with Scrum or Kanban at the level of individual teams or with SAFe (Scaled Agile Framework) at the overall organizational level. However, especially when scaling agile teams, their formation poses a potential complication. It may not be visible at first, but sub-optimally composed teams represent one of the greatest challenges in the adaptation and successful implementation of scaled agility.

On the lowest level, putting together a team is rather obvious and uncomplicated. According to agile principles, a team must be cross-functional. In other words, it must have all the skills and capabilities needed to transform requirements into products and to ensure the quality, integration and delivery of the product. In most cases, teams are formed around a single application or service. If the organization decides to scale agility and integrate the teams in a larger context, the team configuration is often kept. This is frequently observed, for example, in the creation of Agile Release Trains (ART) in the context of SAFe. As a consequence, a scaled team construct is created, which represents an organizational map of the company’s service or application landscape.

Application teams are adopted and integrated one-to-one when scaling and adapting larger agile frameworks.

Applikationsteams

Graphic: Organisation of <Agile Teams> in Application-Teams

The composition of the teams based on the affected applications is obvious if they have already used agile methods on team level before. Teams with a focus on a single application can be successful and efficient in agile, scaled constructs. Often, however, the problem arises that the individual teams do not feel responsible for the overall product or service, but only for their application or part of it. This problem is certainly not limited to the agile context, but becomes visible early on due to the fast creation of delivery objects in agile methods. Typical symptoms are:

  • Inefficiency or problems in cross-team communication
  • Unnecessary or avoidable complexity of interfaces
  • Unforeseen complications in the integration of the individual components or services
  • A team becomes a critical bottleneck in the creation of delivery objects

If the scaled agility does not work with application teams, the end result is that you do not have a working overall product as quickly as you would like. This can lead to overwhelming costs or significant time delays, which nobody needs.

Forming Feature-Teams helps to establish an end-to-end focus, but involves a rethinking of the system organization.

When scaling agility, the underlying principles do not change, but the individual context of meaning does. In larger organizational structures, cross-functional also implies the ability to cover all steps of the service or customer journey from A to Z. The individual agile teams should ideally be put together differently than in the case of agility at the sole team level. If the focus is to be placed on the end-to-end value-added flow and the best possible flexibility of scaled agility is to be exploited, feature teams are inevitable. If these are put together correctly, individual product or service features can be implemented end-to-end by different teams. This not only increases flexibility in implementation planning, but also helps to avoid capacity bottlenecks through versatile employees. Each team can be interchangeable and independently deliver value to the customer.

Featureteams

Graphic: Organisation of <Agile Teams> in Feature-Teams

When putting together feature or product teams, it is important that know-how and skills from all affected applications or service components are available in the team – ideally by several people. A team must cover every process step to deliver added value to the customer. This prevents the problem of complex interface issues. As a counterpart, however, it must be ensured that sufficient time is given to the exchange of knowledge about the individual components beyond the teams. Otherwise the danger exists that the teams obstruct each other in the individual components and technical debts or unnecessary complexity are built in. In the beginning, this fundamental rethinking and restructuring of the teams may mean a loss of efficiency. In the long run, however, the forced exchange of knowledge through close cooperation within the team leads to individuals building a broader knowledge in the other components and being able to work more flexibly (T-Shaped Professional). Feature or product teams are not necessarily faster than application teams, but they reduce the risk of interface and integration problems and thus usually deliver the desired value earlier.

For scaled agile projects there is no golden rule for team formation. Nevertheless, it is worth giving this topic enough time and attention.

There are already many companies that have successfully implemented scaled agility and have the right organization and formation of agile teams. Because every context is different and brings its own unique challenges, there is no golden rule that can be applied always and everywhere. Nevertheless, it has been shown that if a company is consistently focused on the customer experience and its journey, an organization of the employees involved in feature teams promises the greatest success. What do you think about this topic? Is the problem familiar to you, or have you had good or negative experiences with it? We are interested in your opinion and would be pleased to receive your comments or contacts.

0 thoughts on “Composing teams in Scaled Agility”


Leave a Reply