It is a misuse of our power to take responsibility for solving problems that belong to others.
Release Train Engineer and Solution Train Engineer
The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the major events and processes, and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive continuous improvement. The Solution Train Engineer (STE) plays an equivalent role for a Solution Train, facilitating and guiding the work of all ARTs and Suppliers in the Value Stream.
Although (ARTs) and Solution Trains are composed of self-organizing and self-managing teams, trains don’t drive or steer themselves on auto-pilot. That responsibility falls to the Release Train Engineer and Solution Train Engineer, respectively. RTEs and STEs are typically experienced program or development managers and operate most effectively as servant leaders. They have a solid grasp of how to scale Lean and Agile, and understand the unique opportunities and challenges associated with facilitating and continuously aligning a large development program.
The Release Train Engineer and the Solution Train Engineer facilitate Agile Release Train and Solution Train processes and execution, respectively. They escalate impediments, manage risk, help ensure value delivery, and help drive continuous improvement. Many also participate in the Lean-Agile transformation, coaching leaders, teams, and Scrum Masters in the new processes and mindsets. They help configure SAFe to the needs organization, standardizing and documenting practices.
RTEs and STEs typically fulfill the following responsibilities:
- Manage and optimize the flow of value through the ART and Solution Train using various tools, such as the Program and Solution Kanbans and other information radiators
- Establish and communicate the annual calendars for Iterations and Program Increments (PI)
- Facilitate PI Planning readiness via fostering the preparation of Vision and Backlogs, and via Pre- and Post-PI Planning meetings
- Facilitate the PI planning event
- Aggregate Team PI Objectives into Program PI Objectives (the RTE) and publish them for visibility and transparency
- Aggregate program PI objectives into Solution PI Objectives (the STE) and publish them for visibility and transparency
- Assist with execution and Feature/Capability completion tracking (see Metrics)
- Facilitate periodic synchronization meetings, including the ART sync at the Program Level and the VS sync for Solution Trains
- Assist with economic decision-making by facilitating feature and capability estimation by teams and the roll-up to epics, where necessary
- Coach leaders, teams, and Scrum Masters in Lean-Agile practices and mindsets
- Help manage risks and dependencies
- Escalate and track impediments
- Provide input on resourcing to address critical bottlenecks
- Encourage the collaboration between teams and System and Solution Architects/Engineering.
- Work with Product and Solution Management, Product Owners, and other stakeholders to help ensure strategy and execution alignment
- Improve the flow of value through value streams using the Continuous Delivery Pipeline and DevOps
- Help drive the Lean UX innovation cycle
- Report status to Lean Portfolio Management (LPM) and support related activities
- Understand and operate within Lean Budgets
- Facilitate System Demos and Solution Demos
- Drive continuous improvement via Inspect and Adapt workshops; assess the agility level of the ART/Solution Train and help improve
- Foster Communities of Practice and the use of engineering and Built-In Quality Practices
SAFe doesn’t prescribe a reporting structure, but the RTE and STE typically report to the development organization or an Agile PMO, which, in SAFe, is considered a part of Lean Portfolio Management. For enterprises with existing PMO organizations, a program manager often plays this role.
RTEs and STEs Are Servant Leaders
While new RTEs and STEs typically have the organizational skills to perform the RTE/STE duties, they may need to learn and adopt Lean-Agile Mindsets. They may need to transition from directing and managing activities to acting as a servant leader. Servant leadership is a leadership philosophy that implies a comprehensive view of the quality of people, work, and community spirit . In the context of the RTE and STE, the focus is on providing the support needed by the teams, ARTs and Solution Trains to be self-organizing and self-managing. Characteristic servant leader actions include:
- Listen and support teams in problem identification and decision-making
- Create an environment of mutual influence
- Understand and empathize with others
- Encourage and support the personal development of each individual and the development of teams
- Persuade rather than use authority
- Think beyond day-to-day activities; Apply systems thinking
- Support the team’s’ commitments
- Be open and appreciate openness in others
As Robert Greenleaf, the father of servant leadership, said, “Good leaders must first become good servants.” Just as there are Lean-Agile transformational patterns for the LPM function, there are also transformational patterns for a traditional manager moving to a servant leader. The “from” and “to” states are:
- From coordinating team activities and contributions to coaching the teams to collaborate
- From deadlines to objectives
- From driving toward specific outcomes to being invested in the program’s overall performance
- From knowing the answer to asking the teams for the answer
- From directing to letting the teams self-organize and hit their stride
- From fixing problems to helping others fix them
Learn More See Servant Leadership at http://en.wikipedia.org/wiki/Servant_leadership.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Trompenaars, Fons and Ed Voerman. Servant-Leadership Across Cultures: Harnessing the Strengths of the World’s Most Powerful Management Philosophy. McGraw-Hill, 2009.
Last update: 22 May 2017