top of page

Scaled Agile Roles: Build Your Agile Environment With Intent

By Chris Maniates


Running a relay race and building a scaled agile team are very similar. When running a relay race, everyone has a role to play to ensure their team crosses the finish line as fast as possible. The order, or the runner’s configuration matters. The first runner needs to be quick off the blocks. The next two runners may need to make a strategic move, while the last runner may need to defend the lead their teammates earned for them – all the while holding the team’s baton. Agile roles are no different.


Agile teams want to move fast and deliver the right “thing” with the least amount of negative impacts. Each person has a purpose with responsibilities to others on their team and their organization. Each role serves and delivers value to other functions in multiple ways.


Like the relay racers, it is essential to understand who does what in a scaled agile environment. We find it simplest to identify roles by dividing all efforts into the following three categories:

  • What is getting built?

  • How does it get built?

  • Is it an operation or execution activity? (Does it facilitate the flow of value?)


Once you have your efforts grouped in the what, how, and execution/operation buckets, it is easier to see who will be doing what work. For example, in an Essential SAFe® configuration, the team and the System Architect are responsible for how to build the product.


The table below explores multiple SAFe configurations in what, how, and execution context and assigns the appropriate roles.


Agile Roles and Responsibility Matrix

Product Owner

Business Owner

Development Team

Scrum Master

Product Owner

Business Owners

Product Management

Development (technical or business) team

System Architect/Engineer

Scrum Master

Release Train Engineer

Solution Manager

Solution Architect/Engineer

Solution Train Engineer

Epic Owners

Enterprise Architect

Lean Portfolio Management

Agile Project Management Office (APMO)


Team of Teams


With a high-level understanding of scaled agile roles and responsibilities, we shift to combining those roles to make teams, or better yet, teams of teams.  

Most people have heard of a Scrum team, the most basic of agile teams. In Scrum, there is one team that consists of the Product Owner, Scrum Master, and the team (developing the value).



When there is a long-term need to coordinate and integrate multiple agile teams, then you need to scale agile. Agile teams using the Scaled Agile Framework® (SAFe) are the same as your traditional Scrum team with one differentiator: they may not all be technology-focused. Teams may be bringing value across the enterprise in areas such as marketing, compliance, regulation, training, or other areas of innovation. Work with your Agile Coaches to determine what configuration is right for your organization.


Essential SAFe Configuration


In an Essential SAFe configuration, several Agile teams are operating together as an Agile Release Train (ART). At this point, we add three ART-specific agile roles to support collaboration, maintain focus on delivery  within their ART and the enterprise:

  • A Product Manager (PM) takes on some Product Owner responsibilities to define and build products that meet customers’ needs. To help us coordinate multiple teams, the PM creates a roadmap for at least the next year of upcoming product enhancements. Business owners are more involved as there is more effort to coordinate with multiple teams.

  • A System Architect ensures fitness of use to support the teams’ integration and coordination across one shared architectural vision.

  • A Release Train Engineer (RTE), the Scrum Master of Scrum Masters, supports the heightened operational needs as the ART’s servant leader.



If you feel there is a demand to grow beyond the basic building block of an ART, run through a Value Stream Mapping workshop to confirm the need and provide the intent for the expansion. It will help you choose between the available scaled agile configurations.

Learn more about the role of a Release Train Engineer and how to excel in this servant leader role in our Release Train Engineer Starter Guide. 


Large Solution SAFe Configuration


In your Value Stream Mapping workshop, you may have identified reasons for a Large Solution SAFe configuration. Perhaps it makes sense to separate sub-system work and feature work (to enhance flow). Maybe you have a large value stream that requires multiple ARTs. Or it may be time to split your ART that has grown too large into two ARTs. Ideally, you want to keep each ART under 125 people. The goal is to minimize dependencies with other ARTs, support the teams, and ensure that each ART can stand alone to release value. If any of these scenarios match your environment, the following agile roles will be part of your Large Solution SAFe configuration:


  • A Solution Manager provides Solution context and vision across all ARTs to meet customers’ needs. As more teams need to coordinate, the Solution Manager develops a roadmap with a longer horizon, usually around three years.

  • A Solution Architect/Engineer focuses on systemic solution context, intent, vision, and standards (including non-functional) to ensure fitness of use.

  • A Solution Train Engineer, the Release Train Engineer of RTEs, supports the heightened operational needs as the Solution’s servant leader.


Portfolio SAFe Configuration


Your Value Stream Mapping workshop may have indicated a need for Lean Portfolio Management (LPM). A Portfolio SAFe configuration also builds on the Essential Configuration. It aligns strategy, operations, and agile funding across multiple Value Streams (development teams and systems). Lean governance over the funding and performance keeps the effort on a coordinated track. It also forecasts potential future efforts in a longer-term roadmap. If you are running a Portfolio configuration, your Enterprise Architect, epic owners, APMO, RTE, SM, and executives will handle these efforts.


Full SAFe configuration


A Full SAFe configuration will be built quite slowly over time and contains all the components mentioned above. This comprehensive configuration is for sizeable, integrated efforts, such as numerous product development streams over multiple years.


Responsibilities to Agile


Lastly, Agile is not the management hierarchy but rather a second hierarchy of competence. This second hierarchy works alongside the standard organizational hierarchy (CEO, senior managers, functional managers, team members). It does not replace an organization’s internal management.


In agile, each person has a shared responsibility to:

  • Respect others (their role, their work, and them) 

  • Stay in their swim lane to minimize flow delays


By respecting these responsibilities, or guardrails in Scaled Agile Framework® (SAFe®) vernacular, teams of teams work together smoothly while providing the best value in the shortest sustainable time without dropping the baton.

Note: SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile,

bottom of page