21. 28
Key Program Level Roles
Product Management
Release Train Engineer (RTE)
System Architect
System Team
22. 29
Product Management
Product Management is the „content authority“ for the Release Train
Continuously interacts with customers and
stakeholders for solution definition and
feedback
Owns the Vision
– Works with stakeholders to establish and
articulation Vision
– Defines statement, positioning, and solution
economic model
Drives the PSI/Release
– Defines and prioritizes Program Backlog
– Participates in Release Planning and I&A
Communicates the Roadmap
23. 30
Release Train Engineer (RTE)
Facilitates release planning readiness and
the Release Planning Meeting
Assists program execution and tracking
Facilitates Scrum of Scrums
Ensures collaboration within and across
trains
Escalates impediments and helps manage
risk
Helps drives program-level continuous
improvement
The RTE is the „Chief Scrum Master“ for the Agile Release Train
24. 31
System Architect
Helps to maintain a high level
understanding of system requirements and
NFRs
Evaluates design alternatives and performs
cost benefit Analysis
Presents the technological Vision during
Release Planning
Helps the teams make appropriate design
decisions during implementation
Establishes test automation strategies
Works with Enterprise Architects to
establish Architectural Runway
The System Architect plays a unique role in helping teams
efficiently implement stakeholder needs
25. 32
System Team Integrates and Evaluates
Build/supports development infrastructure
and manage environments
Assist with test automation strategies and
adoption
Provide/support full system integration
Perform end-to-end system and system
quality (NFRs) testing
Stage and support System Sprint Demo
The System Team provides process and tools to integrate and
evaluate assets early and often
31. 38
Program Level Events
Release Planning
Scrum of Scrums
System Sprint Demo
Community of Practice (CoP)
HIP Sprints
Inspect & Adapt
32. 39
Release Planning Meeting
Two days every 8-12 weeks
Everyone attends in person if at all possible
Product Management owns feature priorities
Development team owns story planning and high-level
estimates
Architects, UX folks work as intermediaries for
governance, interfaces and dependencies
Result: A committed set of program objectives for the
next PSI
33. 40
Scrum of Scrums
The Scrum of Scrums is
a meeting for Scrum
Masters and the
Release Train Engineer
to gain visibility into
team progress and
program impediments
It is typically held twice
per week
It is timeboxed but is
followed by a “Meet
After” for problem-
solving
Programs continuously coordinate dependencies through
Scrum of Scrums
34. 41
Continuous Inter-team Coordination
Agile team members
may visit other team’s…
Backlog grooming: to
see what’s coming next
sprint, request
adjustments
Sprint planning: request
adjustments
Daily standups: follow
up on execution
Team Demo: summarize
current stage
Agile Teams self-manage dependencies and resolve risks
35. 42
Fortnightly System Sprint Demo
A demonstration of the
integrated software
assets.
For business owners
and other program
stakeholders (many of
whom could not attend
every team demo)
Happens after the team
sprint demos (may lag
by as much as a sprint,
maximum!)
Every sprint, the System Team/Product Management demonstrates
the solution increment to the program stakeholders
36. 43
CoPs Support Continuous Learning
Typical CoPs:
– Architecture and Design
– Automated Testing
– Continuous Integration
– Etc. …
May meet multiple times per PSI/Release
Session example:
developer from ‘Transformers’ Team shows others how
to use mock objects in real examples
Agile Teams share new expertise and experience
via Communities of Practice (CoPs)
37. 44
HIP Sprints
Hardening: Some system test, product and regulatory
validation, and documentation may not be practical
every sprint.
– BUT not an excuse to build up technical debt!
Innovation/Improvement:
– Opportunity for innovation spikes, heckathons, and
continuous education
– infrastructure improvements
– Inspect&Adapt Workshop
Planning: Readiness, Release Planning
Hardening/Innovation/Planning (HIP) sprints
enable cadence and delivery reliability
38. 45
Inspect&Adapt
I&A has three parts:
Part 1.
The PSI demo of the solution’s current state to program
stakeholders
Part 2.
Quantitative measurement (Rel. Obj., Velocity, Quality)
Part 3.
The problem solving workshop
Attendees:
teams and stakeholders
Timebox:
3-4 hours per PSI
Inspect and Adapt (I&A) is to a Release Train what
the sprint demo and retrospective are to a team
44. 51
Komplexität, Einfachheit & Selbstorganisation
Simple, clear purpose and principles give rise to
complex, intelligent behavior.
Complex rules and regulations give rise to
simple, stupid behavior.
Dee Hock, Gründer und CEO VISA
Dee Hock.The Birth of the Chaordic Age
46. 53
LeSS als Organisations-Design-Framework
Larman‘s Law: Cuture follows structure
beginnt damit Standard Scrum zu verstehen und
in einzelnen Teams anwenden zu können,
führt beim Skalieren zu tiefgreifenden
organisatorischen Veränderungen und
benötigt daher das volle Verständnis und die
Unterstützung des Senior Managements.
47. 54
Die ideale Produktentwicklungs-Organisation
Scrum Feature Teams
Area
Product Owner
Produkt
Manager/Product
Owner
CXO CPMO
Produkt A
Area x Area y
Feature
Team 1
Feature
Team n
Feature
Team 10
Service &
Support
Produkt
B
...
48. 55
Von Spezialisten Teams zu interdisziplinären
Teams
IT Spezialisten Teams Interdisziplinäre PD Teams
Lead
Designer
Designer
Designer
Lead
Arch.
Architekt
Architekt
Lead
Dev
Developer
Developer
Developer
Developer
Developer
Developer
Test
Lead
Tester
Tester
Tester
50. 57
Von funktionalen Silos zu Communities of Practice
Funktionale Silos Communities of Practice
Leiter
Design
Designer
Team
Designer
Team
Leiter
Arch.
Architekten
Team
Architekten
Team
Leiter
SWE
Developer
Team
Developer
Team
Developer
Team
Developer
Team
Developer
Team
Developer
Team
Leiter
QS
QS Team
QS Team
QS Team
53. 60
Team Koordination
Durch gemeinsame Sprint Meetings mit Team
Vertretern
– Joint Product Backlog Refinement
– Joint Sprint Planning I
– Joint Retrospective
Interne Open Source, collective code ownership
Continuous Integration
Teamübergreifende Communities of Practice
(CoPs) z.B. für"
– Architektur
– User Experience
– …