I have been a Release Train Engineer in Arm for a year now, and I still struggle to explain what my role is or what I do. What is an RTE and what’s not? And most importantly: how does it fit within my company from a logistical, productive perspective but also a cultural one? I’ve gathered some thoughts during this year and here are my two cents about what being an RTE truly means. Always from my personal perspective!
A bit of context
I got officially certified as a SAFe® Release Train Engineer in June this year, after nine months effectively performing the role in a relatively big ART and while I did learn many details about the logistics and the position of my role within the SAFe® framework, I also understood a similar reality as when I became a Scrum Master: a three-day training doesn’t make you a Scrum master. You need to go through a really tough and exciting path of learning in order to being able to live and enjoy such an exciting role.
What is a Release Train Engineer? No more and no less than a Scrum master at the program level. That’s it. There is no need to complicate it further. You’re not (completely) a program manager. You’re not just a Scrum master: you’re a Scrum master of Scrum masters. An Uber Scrum master, like my boss Rob likes to say. But precisely because you’re placed in the program level and not at team level, things become exponentially more difficult when it comes to direct interactions with the teams.
Because you no longer are placed within a team, it is a lonely job. You need to isolate yourself a bit to be able to work around everything that is affecting them without being part of them. Most times, they won’t be able to see your actions. And that can be tough for your ego and recognition, but once you get over that little detail, you just crack on with your responsibilities and try from your position to influence your Scrum masters (again, as a Servant Leader yourself, the most rewarding bit of it all) while you work on the ART management with passion and determination.
The RTE life
This is what being an RTE is supposed to be according to the standards of my company, which reflect how we see the role:
The RTE is an enabler of outcomes by means of servant-leading and coaching following Agile lean practices, efficiently releasing value through ARTs, handling dependencies between teams, risks and escalation of impediments. Makes sure the PI is always up to date with its inputs and outputs, and facilitates all the program level meetings such as Scrum of Scrums, System demos and Inspect & Adapt. All of the above seen from a truly Agile mindset, always able to provide support and coaching to product owners, Scrum masters, stakeholders, and team members where applicable. Must excel in understanding technical terminology, systems thinking and end-to-end knowledge of their teams. Must promote team collaboration, solve problems and blockers, soft-skilled with empathy and compassion while supporting flexible working practices and being able to persuade and influence without being authoritative. Most importantly, the RTE needs to be open, encouraging and appreciating openness in others.
Do you understand now why I struggle to explain what I am? It’s not easy to explain in a single line so many liabilities. And while this descriptions is quite an accurate reflect of what I am, it is more than that. Take for instance:
- Who am I and how do you work with me? The person, not the role, has routines and good practices that need explanation. This is something I learned from my boss Rob, and it was an eye opener: do you read long emails? Do you prefer Skype to email? Do you have specific working patterns? How can you have a healthy relationship with me?
- What an RTE is NOT: It is really good to clarify what I can do, but the problem is that by having such a diverse list of responsibilities, people might believe you are liable for things you’re not. Make clear you’ll always be willing to help, but draw a clear line on things you don’t really need to do. Divide and conquer. Remove yourself as a single point of failure, especially in a role like this.
- Weird practices and people-centric culture: You do need to drive your train, but you need to keep things weird (I knew this already, I confirmed it during my latest Scrum Alliance conference in Austin). Your ART is driven by your teams, you’re just the compass. Trust your teams. Give them independence. Defend them when you have to, make them liable when they need to. Have no Ego, accept constructive criticism. Give yourself room to failure and be humble. And make your ART a place not only productive, but also fun and a cool place where people want to stay.
- Your personal development matters: never put your personal development and well-being as an individual due to your responsibilities. Make a plan of development. Spend time trying to make things weirder while still being productive and diligent with your ART management. Handle your time efficiently but allow yourself to be spontaneous. Lead by example.
A PI is a Product Increment as per the SAFe® framework. It’s the piece of work that takes place within a quarter (give or take – six sprints) and every time a PI finishes, a new one kicks off with a two-day planning event called PI planning. I don’t know about your company, but… man, in Arm it’s massive. And as head of an ART, as an RTE you will need to do lots, lots of work. Listen up!
- End-to-end features readiness: during the ongoing PI, you need to sync-up with the relevant people not only on the progress of the ongoing features, but the readiness of the ones pre-proposed for the next PI planning. This requires a massive work of coordination and, most importantly, transparency. Not only features need to be ready, but also communicated with enough notice to the teams. I’ve seen the terrible effect of not negotiating with the team members pre-PI planning. The event itself should have no surprises and be focused exclusively in drafting the plan of execution, but the end-to-end features must be ready in their basics: explanation, definition, drafted user stories, spikes, architectural design and non-functional requirements. As and RTE, you must not lose track of this and promote communications at all times.
- PI objectives: Features and plan are one of the outputs of PI planning, but what are the objectives of your ART? In my case I have seven sub-teams and each of them come up with their goals (releasing seven features doesn’t mean they have seven goals)… but how does that align to the whole ART? What are we trying to achieve? What value are we bringing to our customers? The RTE needs to help facilitating this agreement between POs and stakeholders, and communicate these goals to the business. The goals can be committed or stretched depending on the confidence level of the teams.
- PI planning outputs: Log all the team goals, ART goals, dependencies, risks… and log them and map them accordingly. This can be a tough job, and it is ever changing. This will be the main focus of you, RTE, when it comes to management and tracking. You must be generous with the time you spend doing this.
What is written in the framework schoolbook is the basic, first-time planning. After nine plannings, believe me: it doesn’t resemble at all to that idealistic view.
I will focus, at some point, in the big list of readiness that will make the planning successful: A readiness template for teams, reviews of definitions of done for the teams, review of metrics and maturity levels from the previous PI, review and rationalise meetings for the next PI, creation of new tracking structures in our respective tools (I use confluence to automate and publishing anything related to the ART), define new goals, dependencies, risks, features etc… agree teams structure and changes, create a pack with the teams structure and proposed features, communicate achievements from the last inspect and adapt, request teams capacity, define physical spaces, review cadence of sprints, calendar of events such as platform freezes, national holidays… anything that could affect the productivity of your teams.
The elements that need facilitation or attention when executing a PI are really a lot, and being pragmatic and time-efficient is essential.
- Scrum of scrums: I do this now once per week (the cadence must be agreed by the attendees and can change anytime). I invite Scrum masters, QA leads, Business change people, BA leads, business partners and Service transition specialists. Normally, I like to invite team members. In this meeting, which doesn’t have a specific agenda, we review the progress of the ongoing features as an ART, discuss dependencies, and we foresee the next sprint, so we can have these talks into account for our next sprint planning. Normally, a set of actions is defined, and we review them in the next iteration of the meeting.
- Inspect and adapt: The event itself happens during the last sprint of the PI, also known as innovation sprint, and has as an output a list of actionable. The RTE must log them and track them, but as part of the Agile mindset, they must also make clear that changes are everyone’s responsibility. A single person cannot push a big rock. That would not make sense. This event will become part of the development of your ART overtime (I elaborate a bit below in the ART development section).
- Dependency management: the key is logging everything. And managing these dependencies are as much a responsibility of a team as another. The RTE simply pushes for their resolution, and it can be very tricky if these dependencies affect more than one team, there are communication problems, or even worse: they depend on another ART or an external party. The way these dependencies are tracked are again down to the teams, but the RTE must find agreement and compromise and coaching on best practices.
- Risk management: Probably the toughest task of all is handling risks. These can have different plans of action: accept the risk (what can we do?), mitigate it with a specific plan or own it. These risks can be mild or a real blocker. As and RTE, you must review them and do your best to remove them. This will require an enormous amount of resourcefulness and you will not always succeed, but you must be honest and open about it. Normally, Scrum masters and POs also review them, and sometimes they take their own initiatives to fix them. Do not worry too much or feel bad if this happens: they are their own masters. Focus on when you can actually remove a risk on your own. But you’re not a God.
- Third-party management: sometimes we do not pay much attention to the nature of our relationship with external third-parties that hold the key of one of the end-to-end processes: server infrastructures, data platforms… do they have access to our tools? Do they work in Agile? Are our interactions effective and timely? A plan of interactions and healthy communications is key when dealing with them, and requires the RTE to provide counsel on how to do this efficiently until the ART or team is happy enough, then this can just go on its own. But paying attention at the right moment is key, otherwise it’ll affect the productivity of your teams beyond repair in certain cases.
- People management: Oh yes, how could I forget? Did I mention how important it is to drive your ART through its people? The key, critical aspect of decentralising decisions? To understand that we all are individuals and must find a way to work together despite our subtle differences? Yes, that’s exactly what Agile is about. Revolutionise the workplace. Being productive and giving value to your employer while enjoying your work thoroughly, promote t-shaped teams, arguing through retrospectives, admitting our weaknesses so we can become stronger… all of that through the voices of our people. Sometimes, this emotional burden is a bit too much for some, but it is an exciting way of life and the proof that Agile works and at the same time it isn’t for everybody. Handling people means having into account their individual needs and career development, the importance of social events, having a coffee or team with them, remove the idea that there are levels of importance and a long etcetera. Being kind, being helpful, having fun doesn’t mean you’re not a serious professional. As an RTE, you must find a way to reach your people and listen to their needs, struggles, and support their ideas when the purpose is clearly oriented to a positive outcome. And most importantly, trusting them. Sometimes this means difficult conversations, and sometimes bitter outcomes… but the long term is always what matters. And when people start feeling comfortable and engaged at the workplace, that’s when the magic happens. Don’t forget, by the way, that there is a big danger in defining roles with no flexibility. Boundaries are necessary as long as they don’t become bottlenecks. I am an RTE, but I can be much more than that and if I want to do something outside my job description and I’m capable, I should be able to do it.
- Reporting: yes, every sprint there should be a report of the outcomes for each team. Did we achieve our goals? Our velocity trend? Did we solve our dependencies? Are we on track? Reporting is one of those elements where several books are written, and all of them provide good tips on really useful, relevant quality metrics, but it’s a company decision to define them. And as an RTE you must ensure the cadence of these reports is respected, and challenge the company on the structure of these reports, in order to achieve a meaningful, comprehensive report of progress. And most importantly, what it means for your ART and your maturity.
- Do not communicate, but publish!: What’s the point in sending lots of emails communicating ‘things’? There are so many ways teams can be in touch: MS teams, Slack, Confluence, etc. My idea of a fluent communication is the one that is available like a magazine for reading. My challenge is obvious: if I publish everything and someone doesn’t know about something, that someone needs to understand that it is as important to speak as it is to listen. Like with everything else, the RTE must find the most efficient way to talk to their people, and change things when they don’t work into more efficient models. But the main message is there…. do not communicate, publish everything! And in the DevOps spirit, automate as much as you can!
- Budgeting and economic views: in my case, I take care of reviewing the budget and forecasting of the money spent in my ART. This task is particularly tricky (and sometimes annoying, to be honest) but keeping your mind in economic terms will help you maximise the value of your ART. Have you ever, casually, wondered how much money does your company pay for a 30-minute meeting with a whole team? Maybe you should before you book that meeting and map the value of its outcome.
Development of your ART
Delivery isn’t only the purpose of your ART. As an RTE you must look beyond that and understand the journey your teams are going through. If you never take a step back to understand where you are in that journey, there will be no evolution. And you definitely want to treat your ART as a living organism that grows and evolves, and sometimes gets sick and need medicine. Sometimes you must address technical debt. Sometimes you need to put more focus in other areas. This can be achieved by having three elements into account:
- Develop a maturity model overtime: there are many maturity models out there to look at, and I’m not going to go through them here. Just find one that has the right metrics for your ART in agreement with your teams and company, and make sure you come back to it regularly.
- Value flow management: your ART should be a value stream for your company in itself, or contribute to one. If that is the case, managing the value flow is key to understand how much value you’re providing to your company. RECOMMEND BOOK.
- Managing your Inspect and Adapt: The event is just a few hours, tracking and updating and publishing the actions taken are an ongoing activity that must be done with a cadence. And then, start again, prioritising the elements that clearly affect the teams. Not all problems are as heavy as others, nor affect the same number of people. And we can be very selfish with our individuality when it comes to our problems. But a well-managed inspect and adapt will improve the happiness and efficiency of your release train.
Routines of an RTE
I am not going to go into a lot of detail with this: I’ll likely write another blog post in the future as this has been a journey for me, and not always successful. The key point here is that time management is essential when you have such a diverse list of responsibilities, all of them important. I will just say this: you need to define a clear routine of to-dos and be extremely cautious with overbooking yourself. I am now in the process of becoming more available and diligent, and it has been tough. These are some of my current routines that run in different cadences:
- Sprint cadence (every two weeks): Scrum of scrums, Risks review, PO sync-up, ART leadership review, QA practices review, Security actions, Social events, Update calendars, Personal development review, Sprint reporting, releases news review, recruitment updates, Timesheets review, 1:1’s with my team members, Scrum masters sync-up.
- Monthly review: Next PI readiness, finances and budget forecast.
- PI Cadence: PI planning readiness, end-to-end feature readiness, architectural map review, inspect and adapt, end-to-end system demo, SAFe® coaching and training for new starters.
- Others: availability on demand for 1:1s, seasonal/specific activities that need a cadence with tracking, a small break every quarter to recharge batteries, self-assessment on my own maturity level as an RTE.
On top of all the above, you need to pay a massive attention to coaching. After all, never forget that beyond all the framework activities you are a servant leader! Nothing more than a willing, helpful Scrum master. You are there to serve your people, your teams. Hence, please review these aspects when you are working alongside any person in your company:
- Agile anti-patterns: be knowledgeable and pay attention to toxic, anti-agile patters. From people that escalate by default, for ineffective communications, misunderstandings, unreasonable deadlines, people that won’t respond to needed actions, bullying, priming, and the very long etcetera that can make an amazing workplace a living hell.
- Cross-functionality: Today you are a tester, tomorrow you are a Scrum master. Our lives change all the time, and very likely what you do today is not what you’ll be doing in five years. Aim to have a team of people that do not constraint themselves to their job descriptions. Listen to their motivations. Help them make a plan. If you manage to have people who feel they have a future in their ambitions, you’ll have the perfect ART.
- Gaps management: If a proper maturity model is followed and the inspect and adapt actions are equally handled, it will be very easy to identify the real bottlenecks. Handling these gaps and prioritise its resolution depending on their priority is key for a Release Train Engineer. As usual, it will be key to know the flaws and work with the people who can make things happen.
- Functional management: Not everything are soft skills or project tracking or Agile coaching. The basic, functional management of people is also key if you are, like me, a manager with an incredible team that I lead. Nurturing the relationship with them, have meaningful 1:1’s, mid-year reviews, goals and objectives, etc, will need to happen in order to have a happy team. Like many other topics, functional management is one of those things where many books have already been written.
- Tools optimization: Do you use the best tools? Are they widely adopted? Not only you need to excel at the tools your teams use, but constantly look for optimization and changes. We use Jira and Confluence for documentation and tracking, and many other communication tools such as MS teams.
A bit more than a year ago I wrote a retrospective about what it meant to be a Scrum master in Arm. Reading it back, it brings memories and reminds me how truly passionate I am about Agile. No one would have prepared me then to become an RTE, and I did.
Since then, I believe I am doing a good job but with some obvious points to improve:
- Being an RTE is a very, very lonely job. You won’t be able to talk or spend that much time with the teams. This will make you, somehow, an unavailable person to a degree.
- You need to exponentially deal with all sorts of people, many of them old dogs with little room for influence.
- You have more power of decision, but this means precisely more opportunity to break the status quo and decentralise decisions even more.
- Extremely efficient time management and meeting is critical.
- You are expose in a window: you need to lead by example more than ever.
- You must never forget you’re a servant leader, not important at all. You live to help your team.
- You will not be able to get along with everyone, and someone won’t get you, your role or why you’re there. You must simply explain, be empathetic and continue your mission.
- I learned this the painful way: always put yourself first. Your life and health is more important than any job, no matter how much you love it (like me).
- Being an RTE is, despite the buts, the job where I’ve been more stressed but also happiest in my professional life. I feel I am myself and I’m making a difference. Not to mention the massive thick skin I’m developing with the constant challenges.
Last but not least: hope it is clear now what a Release Train Engineer does. Whatever I do next in the future, I will always remember the intensity and learning I’ve had this last year.