I have been working for some time now as an RTE i.e. Release Train Engineer. For people who are not familiar with SAFe (Scaled Agile Framework) you could call the RTE also an Agile Program Leader. The RTE role includes a number of responsibilities in a large agile program. As described in SAFe web pages: ‘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 relentless improvement’.
So, why I call the RTE an Agile Program Lead, and not an Agile Program Manager? Because there is a fundamental difference between these words. As a manager, your focus is on how to “get things done” and how to “control whether it is done”. As a leader, your focus is on helping your people to develop their skills while you trust they get the work done.
Every now and then, the RTE might also have to apply more traditional management methods. Why is this? Maybe the maturity in terms of an agile mindset is low in your organization when you start adapting SAFe. Teams might feel lost with too much empowerment in their hands. In such cases RTE might be required to provide more guidance for the teams.
I feel the word “adapt” is the key here, not only in terms of leadership, but also in terms of practices. As we know, values and principles “beat” practices. A RTE must understand, which “lever needs to be pulled” and so that the program can execute successfully. This might be dependent on many aspects such as market situation, maturity of the teams, solution lifecycle etc.
Let me give you an example. In my ART (Agile Release Train), I had to change the length of the PI (Program Increment) from 10 weeks to 5 weeks. That sounds odd, right? Why to change from a standard 10-week increment to half the length? The decision was based on the amount of waste created when planned objectives became meaningless after just the first weeks of the PI, due to a fast changing environment. So, because we were not able to prepare and stick to 10 week objectives we split the PI in half. This allowed us to commit to a shorter timeframe with more stable targets.
Another example is about a team not being able to plan two weeks ahead because of lack of understanding of the technical environment. The solution was to reduce the feedback loop by taking Kanban in use. Using the Kanban board with strict WIP (work-in-progress) limits, the team started by implementing just one story at a time, which helped both the team spirit and spreading of the knowledge across the team. Eventually, the ”one piece flow” approach not only shortened the cycle time, but improved the cycle time predictability a great deal.
So, the RTE needs to have many skills. Besides being an effective “Scrum-of-Scrum Master”, the RTE needs to understand how to adapt the SAFe principles for your teams. Having an RTE with a servant leader mindset and strong knowledge on the SAFe values and principles, not only practices, is probably the most crucial thing for a successful SAFe implementation.
Learn more!
FREE Webinar 17 November 2017:
Release Train Engineer’s role in SAFe 4.5
Course 3 – 5 January 2017
SAFe® Release Train Engineer (RTE)
Rolf Läderach
The author has a 20 years history in the development of information systems in the IT, Telecommunication, Banking and Transportation sector. He had been working 10 years in traditional projects as project, program and product manager. In 2007 Rolf took the responsibility for a project in “crisis”. As a project lead he was able to make the turnaround of the project by applying Agile methods. That was the turning point in his career. From now on he started to focus on Agile where he was also involved in several Agile transformations, as well as working as a Scrum Master and Agile coach. Rolf has graduated in 2011 with a MBA and works currently as an SPC in the role as the RTE of a large software development program.