System teams – why, who and how?

Scaled agile framework suggests that each agile release train has its own system team. Usually there is some confusion around the benefit of making such investment in resources and also how to capitalize on it. Here are a few pointers to why, who and how in regards to system teams.

What is a system team?

According to scaled agile framework a system team assists the agile teams in the agile release train with activities like:

  • Create and maintain the continuous delivery pipeline toolchain, including continuous integration, automated builds, automated build verification testing, and automated deployment
  • Create platforms and environments (which may be cloud-based – PaaS) for development, solution demos, and user acceptance testing
  • Facilitate the technical aspects of collaboration with third parties, such as data or service providers and hosting facilities

This is clear on WHAT the system team should do. But until you have actually experienced a great system team it is hard to know WHY a system team is a good idea.


The main reason to have a system team is to have a capability available to constantly increase the velocity of the ART, without competing with the endless pressure of product priorities. Much like a pit stop crew that makes the formula 1 car run fast on the track. No one would ever consider re locating that crew to push a broken car down the track to win the race. It is obvious that stopping the car in the pit lane and fix the problem is a better strategy.
A well oiled agile release train is like a race car, it will not run manually. It depends heavily on automation and interconnected tooling to deliver demands to solutions with speed. That is why a system team is as essential as the pit crew to win the race.


A great system team is a truly cross functional team with representation from core infra, development, testautomation, devops tooling, monitoring and plattform experts. A great system team has a product owner that is peer with other product owners so that activities are planned in collaboration between products and ART capabilities. A great system team have some members that are supportive and service minded and some that are capable of building complex solutions like different deployment strategies, integration test automation, automatic release note generation.

A great system team is able to balance between standardisation for the benefit of the whole and variability for local requirements and innovation. The former is the hardest. Having agile team comply with standards and restrains requires authority. The system team need members who naturally has such authority.


Find members that are willing and dedicate them 100% to the team (no exception). This team really need to be able to solve problems that are more complex that any individual are able to solve.
Come up with a clear vision to get aligned and started. This is crucial in the beginning to bring all competences in the team together and start acting as one. The cultural journey that need to happen in the organisation to bring silos together will happen at smaller scale in this team.
Construct steering so that it is connected to product development and truly based on demands from agile teams in the ART. Focus and prioritisation is key especially when improvements can be made everywhere.
Have the system team run frequent demos to open up for feedback and discussion.
Start with the low hanging fruits, deliver improvements often and iterate.


Mon 30
Mon 30

SAFe DevOps 5.1

May 30 - May 31
Jun 07
Jun 13
Sep 20

SAFe Release Train Engineer 5.1 in Stockholm

September 20 - September 22
Oct 04

Leading SAFe 5.1 in Stockholm

October 4 - October 6
Oct 10

Lean Portfolio Management in Stockholm

October 10 - October 12