Should you rotate the RTE role every Program Increment (PI)?

Since the inception of an Agile Release Train (ART) we have been working with for the past few years, there was a system in place to rotate the Release Train Engineer (RTE) role each Program Increment (PI) cycle. This construct provided each of the RTEs with a “break” from the role and associated responsibility for the delivery of work by the train. Unfortunately, it resulted in some negative impacts on the train which included confusion and inconsistency in communication for the teams as every 12 weeks the RTE would change. This relatively short time actively in the role also made it challenging to gain any traction on continuous improvement initiatives for the ART as the next RTE would change things to put their own slant on the role.  

Accountability and Transparency

We suggested to go back to the RTE role be a single accountable person. This brought a renewed focus on continuous improvement and getting back to the day to day fundamentals of the RTE role and how to facilitate PI Planning event and support Scrum Masters to integrate and collaborate across the Train. This foundation was then built upon to re-establish transparency with the introduction of a physical program board to provide a high-level delivery view of the train progress for the current PI. 

Inspection and Adaptation

Another key area that was brought back into focus was the Inspect and Adapt event held at the end of the PI. This is an event that is dedicated to identifying areas of improvement by the train. Whilst the event had been consistently held by the previous RTE team the improvement items that were identified by the train were rarely acted upon. This resulted in frustration and disengagement from the train members that were offering improvement ideas in the forum but saw limited progress on the addressing the items or removing impediments for the train. 

We focused on coaching the RTE on the importance of not only holding the Inspect and Adapt event but also investing time and effort into adequate planning to ensure the event met the outcome of identifying actionable items for improvement over the subsequent PI. The next step was to increase the transparency of these agreed improvement items so that members of the train knew they were actively being worked on. 

We also ensured that the RTE circled back to review the action items at the beginning of the next Inspect and Adapt meeting (12 weeks later). Providing an update on the outcome, or progress, of the action items from the previous Inspect and Adapt event demonstrated that these items were valuable and being actioned either by the RTE , leadership or train members themselves. 


Whilst the RTE role is a challenging role with a number of responsibilities across the train as well as for the program of work they are supporting for delivery, there is limited benefit in rotating the role each PI. Instead, ensure the focus is on the right things to promote incremental delivery and continuous improvements across the train at a sustainable pace. 

Since moving back to having a single person in the role, the agile teams have reported improved communication and follow up of action items by the RTE which has led to improved engagement, reduction in churn and confusion for stakeholders regarding who they should be going to for what information and when.

About the author

Related Posts:

How do I run a Retrospective?

The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works (including the Product Owner).


What Knowledge and Experience do you need to be an Agile Coach?

To be effective, agile coaches require deep, applied expertise and experience across multiple organisations, multiple projects and industries. As the organsiation scales, the Agile Coaching Development Pathway shows the focus of the role as it scales to more responsibilities beyond being a coach of a single team and provides guidance on what knowledge and experience is required to be an Enterprise Coach.


Improving Program Agility using Evidence Based Measures of Agility in OKRs

OKRs have been an established way to set objectives however the associated activities tend to focus on outputs and not outcomes and impacts. To measure Program Agility, we used Evidence Based Management (EBM) as a framework for OKRs to help shift metrics towards value of the investment to help them make strategic investment decision based on evidence to improve business outcomes.


Setting up a New Agile Team

When setting up new agile teams we have found that starting small with the basics and adding patterns as they start to develop capability has helped us get new teams up and running within 2-3 days and acheive a baseline of agile capability within 3 months