At first sight, the SAFe framework seems very complex. However, it is very structured and there are many different SAFe roles, divided in different categories. This blog seeks to explain the different SAFe roles in a simplified way.
There are 3 levels of complexity of the SAFe framework:
However, in order to understand the different SAFe roles, the framework is divided into four categories (see figure below).
SAFe Essential defines the minimal set of roles, events and artefacts needed to continuously deliver business solutions via an Agile Release Train (ART). This is made up by the Agile team and the Release Train, defined in green and yellow in the above figure.
SAFe teams use Agile practices based mainly on Scrum, Kanban, Lean, systems thinking and quality practices derived from Extreme Programming.
Scrum is a lightweight, team-based process that promotes rapid feedback and rapid, iterative development of the solution. In Scrum, teams define, build, test (and if necessary, deploy) features in short sprints (iterations).
The first category, in green on the image, represents the Agile team, composed as a Scrum team.
Scrum Product Owner
Safe then integrates “Teams of Agile Teams” that work together in the ART (Agile Release Train).
Indeed, the second dimension of team competence and technical agility concerns Agile teams. Even with good execution, creating solutions usually requires more skills than a single Agile team can provide. Therefore, Agile teams operate as part of an ART, which is more or less a ‘team’ of long-term Agile teams.
In addition to the Agile team, the roles in yellow (see figure above) contribute to the successful execution of the ART:
Release Train Engineer (RTE)
The Release Train Engineer (RTE) has a very important role. He is the agile leader and coach at the Agile Release Train (ART) level. This is similar to the Scrum Master role in Scrum, a facilitator of the team level.
He/she will facilitate the progress of the train, the ceremonies (PI Planning, Inspect and Adapt), manage the dependencies, the systemic risks, etc. He/she also has a coaching role, as well as a role in the development of the project. There is also coaching included on the SAFe method and the Lean Agile framework, still at train level.
The Release Train Engineer (RTE) will also monitor the measurements, train level indicators, the whole planning and monitoring part of the Kanban at train level and will also provide support to the Product Manager (PM) role.
In the same way that the role of RTE could be similar to that of a Scrum master, the Product Manager (PM) is similar to the PO (product owner), but at train level. In this context, the Product Manager’s objective is to create the best possible product.
Safe talks a lot about “user customer centric”. The product manager’s mission is therefore to create the most efficient product. The one that provides the most value, the best for its future user. In this context, the product manager will have several roles and activities.
The first activity will be to define the right product, vision, roadmap and functionalities. In order to do so, certain techniques such as Design Thinking can be used. The Product Manager is the owner of his backlog (of a programme level), which contains the “features” and he/she is responsible for implementation and realization by the train.
System Architects/Engineers are responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART) to ensure that the system or solution being developed is fit for purpose.
Business Owners are key stakeholders in the ART and have ultimate responsibility for the business results of the train.
In addition to these critical ART roles, the following functions can often play a critical role in successful ART:
Systems teams typically help create and support the DevOps infrastructure for development, continuous integration, automated testing and deployment in the pre-production environment. In large systems, they can perform end-to-end testing, which cannot easily be done by individual Agile teams.
Shared Services are specialists (e.g. data security, information architects, database administrators (DBAs)) who are necessary for the success of an ART but cannot be dedicated to a specific train. All ART teams apply the same iteration cadence and duration to synchronise their work, so that they can plan, demonstrate and learn together.
SAFe Large Solution
“SAFe Large Solution”, represents the 3rd category in orange on the diagram. In addition to the team and programme levels, a new level called the global solution level has been incorporated into this framework. When large solutions and complex systems have to be designed or implemented, this level is used. Several ARTs synchronise and collaborate in this framework to deliver value.
“SAFe Large Solution®” in orange (see figure above), integrates 3 new main roles :
The equivalent of the System Architect/Engineer but at the Solution level. He/she is responsible for defining and communicating a shared technical and architectural vision across the solution train to help ensure that the system or solution being developed is fit for purpose.
This role is equivalent to product management but at Solution level.
This role is responsible for defining and supporting the creation of large-scale business solutions. It works closely with both the product management roles and the Solution Architect/Engineering. This is achieved by working with a wide range of people to identify and define customer requirements, understand the solution context and develop the solution vision, the solution roadmap and the capabilities needed to meet it.
Solution Train Engineer (STE)
Equivalent to the RTE but at the Solution level. The Solution Train Engineer is a servant leader and coach for the solution train, facilitating and guiding the work of all ARTs and suppliers in the value stream.
He/ghe prepares, leads and coordinates IP planning and large-scale solution delivery, measures results and proposes improvements.
The last level “SAFe Portfolio®” in red (see the figure above), integrates two main roles:
The Epic Owners are responsible for coordinating the portfolio epics through the Portfolio Kanban system. They collaboratively define the Epic, its Minimum Viable Product (MVP) and Lean Business Case and, once approved, facilitate the implementation.
The Epic Owners work directly with the Agile Release Train (ART) and Solution Train stakeholders to define the features and capabilities that realise the value of the approved Epics.
Enterprise architects establishe a technology strategy and roadmap that enables a portfolio to support current and future business capabilities. They drive the design, engineering, reuse, application of models and create Enabler Epics for the architectures that comprise a portfolio’s solutions. Based on continuous feedback, these architects promote adaptive design and engineering practices, and drive programmes and teams to rally around a shared technical vision.