Large product software houses have many dependencies, especially architectural, that have developed over time, sometimes many years.

For most people this is seen as cross-team dependencies from one application team to another. Occasionally there will be teams that rely on multiple teams. A classic example is the portfolio management team of a core-banking platform that is reliant upon the work of many teams.

Less transparent however, are the architectural components, such as output systems, interfaces, libraries and user interface frameworks.

It is the teams responsible for the underlying components which we need to focus on. In fact these dependencies need to be addressed before any Release Planning takes place, otherwise the application teams in the Agile Release Train may derail, if these common component teams are not prepared appropriately.

Reducing Dependencies

We have to reduce dependencies on common component teams. We can do so in two ways.

First is to move individual components back up into the application teams. Again using banking as an example that maybe an interface for a specific stock exchange and responsibility for that interface should be given to the stock exchange team. They then have full responsibility and capability with no dependencies on the common component teams.

Second, there maybe some components that are shared between two or three application teams. In this case the component is given to one application team with the others being organise by association as a Guild, similar to that explained in the Spotify white paper.

With regards to SAFe’s Release Planning, these underlying common component teams still need to take part so that they know when to deliver to the other application teams.

When it comes to how they work, they need to use Kanban. This allows the team to react quickly to unidentified requirements that were missed during Release Planning. This will at least give the application teams a greater chance of fulfilling their Sprint commitments.


Synchronisation of DSDM SAFe and Kanban Teams
(Click on image to enlarge)

Creating Common Component Teams

Setting up the component teams is best done as follows (using an example of 25 team members):

  • Organise them into, for example three teams. The people in the teams are selected for their ability to function best as a team
  • Give each team a “purpose”
  • Ask the team members to “pull” the components that they think they own

In one example, we had 103 components. The teams pulled the components that obviously belonged to them. There were approximately 20-25 components that were unclear. These were then assigned under the premise that the distribution would be reassessed after six months. Often developers will argue that one person knows it, so has to go to that person’s team but that then conflicted with the team’s purpose (they can get themselves into a real knot here!). However, this is not the best option, as know-how transfer has to take place anyway.

Common Component Teams with a  Hidden Danger

Beware of the teams that are distributed, yet have different technology stacks and dedicated know-how carriers. Such teams have no flexibility as there are no deputies. Such teams have to build up know-how first. This will slow down responses and could slow down releases. Thus, in this situation, the reduction of dependencies is even more strategic.

As such, make sure this issue / risk is transparent to such an extent that the rest of the enterprise appreciates the issue.

Release Planning Dependencies

In an enterprise that is running three or more Release Planning sessions for one product, clashes will occur.

This is not only in facilities, but also key people. Therefore, the enterprise must run Release Planning sessions in sequence, running them in parallel will be logistically hard. With an “Innovation & Planning” (IP) sprint at the end of a release, it means that realistically only four two-day Release Planning sessions can be executed in two weeks, with 1 day gap in-between.

This is when we start to see the limitations of SAFe as a scaling solution.

Want to continue? Then click here to discover why we use SAFe

Are you considering SAFe?

Want to know more about our experiences? If so, then contact us. We’ll be more than happy to hear from you.