Becoming a Release Train Engineer: First impressions

I became an interim Release Train Engineer recently; it’s been an intense, raw and beautiful journey not lacking challenges. But my! what a ride! It’s kept me away from this blog for a while… and now it’s time to reflect on the learnings so far.

The first question is: what is an RTE? Yes, we all know the official definition by the SAFe framework, but we also know that roles are just labels, and that every organisation performs the role in a different fashion. Roles are liabilities in disguise, and we normally are far more than what our job role says about us.

For me, an RTE is a Scrum master at Program level; a Principle Scrum master if you ask me. Someone who can look at all the different Scrum teams that compose an ART and is able to track and coordinate all dependencies, risks, goals and features that compose it. But more than that – The RTE should champion the Agile culture and promote it through the Scrum masters while enforces a second layer of communication and relationships between team members, Scrum masters, Product owners and Stakeholders.

That is, in a nutshell, what I’ve been doing in the last two months. And it might sound very corny, but despite the enormous logistical and mental challenges I’ve had to face, I’ve never been happier in my whole professional career. I just feel whole being proactive learning the bigger picture of what I used to do before and, most importantly, I’ve focused on people. Only within the area that defines our ART, we’re more than 90 professionals working towards a common objective. Keeping up with so many amazing guys is not easy, and I cannot know everyone to the same degree… but I try!

Arm is continuing the Agile transformation that started shortly before I joined as a Scrum master, and they’re still finding their identity as they/we move forward through this long-term journey. When I joined, the focus was within the Scrum level, the team level, while jumping into the SAFe framework in the shape of PI planning and programme boards. It did not take long until we had a team of excellent Scrum masters and a community of practice, on top of our Agile Centre of Excellence. And almost two years later, the challenges are still there in many forms, but everyone can now feel the change and what we now call the new normal.

And thus, despite some bumpy tough moments that I will not elaborate here for the sake of respect to my incredible colleagues whom I respect deeply, I had the privilege to be appointed as an interim RTE alongside with Sophie, one of the most extraordinary and smart Agile professionals I’ve ever had the privilege to work with, and inspires me every single day to becoming the best version of myself. We both are two sides of an RTE, and we share its many liabilities. The good news is… we make such a great team!

When I jumped into the role, and despite I had Sophie’s priceless help and support, it happened in a very abrupt way, and almost immediately we had to start working in the preparations of the next PI planning. But there were three constraints that made it very difficult:

• Preparing the next PI with a very short period of time to make it happen efficiently.
• Transitioning my Scrum master role as fast as possible, and that in itself was a full-time role (I cannot begin to thank my team for taking up the responsibilities of the Scrum Master themselves).
• Getting to understand and execute the mountain of responsibilities of the RTE role with immediate effect; and despite I think I’m a super efficient and proactive person, that isn’t something that can be done overnight.

After the PI planning, I was physically and mentally exhausted. I do believe we did a good job but this post doesn’t even begin to cover all we had to pull together. No wonder I left for a two-week holiday right after finishing the planning! I think I would be in a coffin now, otherwise. 

Now, halfway through my first PI as a Release Train Engineer, I can finally enumerate the main points of the responsibilities that define my temporary new role.

• Care for every single person within the ART. Of every team, of every dependent ally that needs to interact with us, keeping the PEOPLE, their professionalism and their feedback as the epicentre of our work.
• Coach, mentor and even lead all the Scrum masters / Project managers in the Agile practices in a consistent way so we all promote a sense of synergy within all the teams, reducing a the Silo effect.
• Keeping track of all the products and initiatives of the ART by complementing the work of the Scrum masters, understanding all the status of the goals, dependencies, risks and features from a program level perspective, while respecting the autonomy of each Scrum team and their culture. Each cell of an organism is independent, but they belong to a bigger picture.
• Lead all the Program level ceremonies: Scrum of Scrums, System demos, Inspect and Adapt sessions, and promote them within and outside the ART.
• Publish all the progress of the ART so everyone within the organisation and the customers understand exactly where the work is progressing, exposing dangers and constraints, and celebrating success where needed.
• Champion the consistency within the delivery process: conceiving features, defining them, work with the product owners to understand the priorities, the architectural work, the development process, the QA process, the release process, keeping a Lean and Economic view.
• Strengthen the relationship amongst Product owners, caring for them and talking to them regularly.
• Sync up with other RTEs of other ARTs in order to promote to the portfolio and organisational level that synergy, consistency in metrics and Agile practices, while acting as a representative of every professional in the development teams of their own ART.
• Have a clear view of people and training needs.
• Being available, knowledgeable, and close to anyone who needs them, but always ready to have difficult conversations, and no matter how much it hurts, being able to put the organisation and team needs into a constant status of flexibility and negotiation.
• I save the best for last: ENGAGE people and make their lives happier within the office walls so they can work within their best capabilities, as much as possible (it can never be perfect)

I could go on for hours, really. I feel incredibly excited at the world of possibilities that’s now open to me. I am still not peak performing but I am getting there, using all the tools I have at my disposal, but most importantly, decentralising the decisions and trusting all my technical leads, product owners, Scrum masters, QA engineers, developers and stakeholders with their choices, taking the definition of servant leader to the next level.

The RTE role is essential to the success of the program level of a SAFe framework and requires high resourcefulness, but it’s pure and plainly a senior servant leader. I guess my years of experience, and most importantly, my true commitment to the wellbeing of my colleagues make me a good candidate, but I don’t know what senior means anymore. I just know I love what I do, that I know I can do it well, and that I am able to influence my people as much as they positively influence me.

From now onwards I will focus in the specific details of my work as an RTE until I either become a permanent one or I come back to being a Scrum masters, and explaining the specific logistics and tools I use to track our ART. Makes sense. I love to put in words what makes me happy and whole professionally.

Some days I get home almost braindead, but… being an RTE is great! Because I can help even more people than before to reach professional excellence, while I learn a lot about myself.

See you soon in the next PI! Our seventh one!