When scaling Agile at an enterprise level, coordination and alignment across multiple teams is challenging as whilst Agile teams are self-organising and empowered, someone needs to steer the train to keep it on the tracks to facilitate program level processes and execution, escalate impediment, manage risk, and drive program-level continuous improvement. In this presentation I share my experiences of being a Release Train Engineer on a transformational project across a large government enterprise and explore the challenges and lessons learnt. In particular, I will focus on the Scrum of Scrums and how the RTE is essentially the Master Scrum Master of the Release Train and how to ensure you have Scrum Masters working together towards achieving the goals for the Train's Product Increment.

1. Release Train Engineer - the
Master Scrum Master
By Mia Horrigan
• Partner 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/Delvery
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. What Worked Well

6. Focus on Incremental Delivery of
Business value

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. Business Involved with Teams
• Feature Owners working with Teams
• Product Owners Council
• Dev workshops with Feature Owners
• Business Owners and Executives at PI planning

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. Train Building
• Team choose their name
• PI planning as team building
• Awareness of other team and train goals
• Trained everybody on the train

12. 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

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

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

15. Managers off the Train
• Scrum Masters and POs 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

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

17. 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

18. 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

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

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

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

22. 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”)

23. Component vs Feature Teams

24. Feature Groups

25. Definition of Done
• Applied this at team, system and Release level
• Helped ensure quality standards adhered to
• 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. aka
Confessions of a Scrum Mom

30. I even have SMs email me as
Dear Scrum Mum……
• I tell myself its an affectionate term but wasn’t sure
• I feel protective of the team but was I stopping
them from succeeding and holding them back?

31. Angel Medinilla
Evolution of a Scrum Master

32. Scrum Dude• Rudimentary skills , very little experience
• Team secretary, lists impediments
• Black and White on process
• Results into low-performing teams

33. Scrum Mom
• Protective to their teams
• “Takes care of everything” to remove impediments
• Teams functional, but not challenged
• Results in stagnation

34. True Scrum Master
• Mentors, leads and develops high performing teams
• Address conflict and challenges the team
• Encouraging, collaborative and motivating
• Team able to learn and continuously improve

35. Agile Sensei/Coach
• Coaches, mentors, trains, facilitates and motivates
• Listens
• Asks why ( “5 Whys pattern”)

36. Circular Model of Scrum
Maturity
https://agileanecdotes.wordpress.com/2014/09/30/scrum-maturity-model/

37. Apply based Team maturity
• It takes time but It’s not a timeline
• Teams never stands still, maturity can be fragile
• If team is immature, they’ll need a Scrum Mom
• A True Scrum Master must be able to evolve as
team matures and be that Coach/Mentor/Trainer

38. Competencies of an SMS/RTE
Listen
Ask deep questions
Empower
Enable to Act
Increase Insight
Facilitator
• Owns process
• Independent
• Non judgemental
• Offers no advice
Consultant
• Advise based on skills,
expertise, experience
• Focus on problem

46. Framework

47. Product Manager and RTE
Relationship

48. RTE and Release Management

49. Schedules and Gantt Charts

50. Politics and Power Struggles

51. Managers off the Train

52. Quality

53. Feature vs Component Teams