The document discusses the role of a Release Train Engineer (RTE), who acts as a master Scrum Master to facilitate agile processes across multiple teams within a large organization. Key responsibilities of an RTE include coordinating delivery, removing impediments, and ensuring teams work together to achieve business goals. The document also outlines some practices, such as dedicated product owners, executive sponsorship, and visualization, that helped one RTE keep their release train on track during a large government IT transformation involving 8 teams. Challenges of scaling to many teams are also discussed.

1. Release Train Engineer - the
Master Scrum Master
By Mia Horrigan
• CEO - Zen Ex Machina
• @miahorri

2. So What is an RTE?
• Master Scrum Master
• Facilitates program level processes and execution
• Coordinates delivery at scale across an enterprise
• Team and Delivery focused to achieve Business
outcomes

3. What it is not
• Another word for Program/Release/Delivery
Manager
• Project Management at scale

4. Servant Leadership
• Provide support so teams can be self managing and
self organising
• Very different mindset to being a Program Manager
• RTE doesn’t decide where the train is going or how
to build the train, they are there to coordinates all
team efforts to the outcome

5. Context
• Started as Agile Coach
• Started with 3 backend teams
• Now, frontend, middleware and backend teams
• But still only Component teams
• Large Government Agency
• Now the RTE for 8 teams on the Train last 6 months

6. What Worked Well – what kept
the Train on the Tracks

7. Dedicated People on the Train
• People on the train are dedicated to the train no
matter what their reporting structure might be
• Product Owner and Scrum Master per Team
• Most co-located on same floor

8. Joined at the Hip - Product
Manager and RTE
• Key relationship
• Product manager and RTE working closely together
• Product manager focus – What and Why
• RTE focus – How to make this happen

9. Focus on Incremental Delivery

10. Program Increment Planning
• Evolved from disastrous first PI planning
• Greater opportunity for business and teams to
converse on features
• Two day session with all the train in the one room
• Huge energy, collaboration and communication

11. Business Involved with Teams
• Feature Owners working with Teams
• Product Owners Council
• Dev workshops with Feature Owners
• Business Owners and Executives at PI planning

12. Team/Train Building
• Team choose their name
• PI planning as team building
• Awareness of other team and train goals
• Trained everybody on the train

13. Executive Sponsor Support
• IT Service Delivery and Business Executive
Sponsorship and Vision
• Aligned to Organisation Strategy to “reinvent” the
organisation and “Getting IT Right”
• Director focused on what she could do to help

14. Visualisation
• Made the flow and work visible
• Team centred around Boards to discuss
• Communication to others of work in progress
• Kinesthetic learning

15. Program Impediments Board
• Make it really visible to the team and executives
what issues and impediments are happening
• Make sure it has who is responsible to clear the
impediment
• Track how long it stays in progress

16. User Focused
• Showcases are scenario based
• Story mapping to understand user journey
• Pragmatic personas and empathy maps

17. Managers off the Train
• Scrum Masters and POs were not team leads
• HR reporting lines different to Train
• Managers outside of train to deal with projects and
and documentation required by non Agile work
teams

18. What needs focus to keep the
Train on the tracks

19. Train’s Maturity
• Different team capability, 40 new people joined in R4
• Succeeding because we have a few smart and capable
individuals
• Don’t want hero work or burn outs

20. Line Managers struggled
• Still their HR manager but not part of the train
• Insisted on a overly burdensome QA process for
reviews that created bottlenecks
• Worried about their place in the new framework
• Went around the Train

21. Governance
• Escalation Point for Impediments and Risks
• Program Status Report
• Roles and Responsibilities need to be clear

22. Scrum of Scrums
• Not a status Report
• About alignment, communication and removing
impediments

23. Product Owner Council
• Escalation Point for scope and boundary changes
• Product Manager coordinates and makes the
ultimate call based on business value
• POs in each team with regular interaction with
feature owners

24. Coaches Council
• Coaches at Team and Program/Portfolio Layer
• Team coaches embedded with team full time
• Provide advice to Release Management Group
• Advocate for team (“Good Cop”)

25. Definition of Done
• Applied this at Team, System and Release level
• Helped ensure quality standards adhered to rather
than big checklists
• Definition of Ready so teams didn’t take on work
that was likely to change scope and design

26. Environments
• Not set up well for continuous integration or
release on demand

27. Push vs Pull
• Started with back end and team level
• Portfolio and program level not as mature
• Push work on team to keep them busy but feature
not ready for delivery
• Want to get to a stage where Teams pull work from
an ordered backlog – not there yet

28. Challenges at Scale
• Teams are self managing however still need
coordination and alignment across multiple teams
• Working together towards achieving the goals for
the Train's Product Increment
• 100 people on the train, 8 teams
• Hard to steer and keep it on the tracks

29. Remember: celebrate the wins
• Not going to get it right the first time
• First Release only happened with hero effort
• PI 1 Second/Third release was delayed and had 35
CRs, Release 4 happened with only but with a
smaller increment
• PI2 has started well

30. End