Multiple Application Teams Working with Multiple Platform Teams

go to The FLEX Patterns     The Development Group Organization Patterns

A common organization of teams in medium to large companies is having several application teams depend upon several platforms that are also applications.  This occurs in Manufacturing Supply Chain IT in particular.

Figure 1 shows how application teams (top row) can have dependencies on platform teams (bottom row).

Figure 1: Multiple teams writing systems used by customers dependent upon platform teams.

The challenge with this structure of teams is that flow through the organization is slowed by delays between the teams involved. Some approaches merely lump all of these teams into one program, discover the dependencies between the teams and then plan for them. This is often the approach people doing SAFe take. This handles what we call ‘program flow’ but doesn’t deal very well with ‘inter-team’ or ‘intra-team’ flow. We describe these three types of flow here:

  • Program flow attends to what the program is working on. This often involves a large batch (called a program increment in SAFe) being worked on.
  • Inter-team flow attends to the flow between the teams that are working together. This provides much more insight into the delays present. It also provides insights into how teams should work together.
  • Intra-team flow attends to all little handoffs and delays in the workflow of an item. A common occurrence of this is when programmers finish their coding and move on even while the testers have not completed their testing. When testers find errors, they have to interrupt the developers to fix them. Not only does this delay cause extra work for the developer to find the work, the interruption also impacts the work being interrupted.

It is useful to see how these teams fit into the value stream, as shown in figure 2.

Figure 2: The teams in the context of the value stream.

We want to take whatever actions we can to minimize the delays it takes to complete MBIs.  It is good to know several options in order to pick the one (or a hybrid of more than one) that will work best for you.

One solution is to split the MBIs up and have the different teams work on them at the same time. This approach can be seen at How Can We Coordinate Multiple Teams? Sometimes this is the best we can do. But another solution is to find people on the platform teams that can temporarily embed themselves in the application teams. These people are indicated by the circles around the people in figure 3.

Figure 3: Identifying people who help the application teams.

While we still want these people to report to their current management, we want them to act as if they are on the teams they are supporting. This is shown in figure 4.

Figure 4: people on the component teams working with the teams that are dependent upon them.

While these people temporarily work on the teams they support, they still report to their current management. They also must attend the standups of their home team (the component team) since they must keep that team informed of any changes that their temporary new team requests.

This is often a good solution.  It sometimes isn’t, however. This is when people can’t be dedicated to the teams that need them. In this case, these people should have their own kanban boards that show their availability and from which they pull their work.