Presentation given at the Agile Austria Conference 2017 in Graz.
Track: Scaling Agile
Achievements and Lessons Learned Introducing Large Scaled Agile Development
Stefan Wunder & Robert Dietze
Achievements and Lessons Learned Introducing Large Scaled Agile Development
1. Robert Dietze
Stefan Wunder
AVL List GmbH
(Headquarters)
JOURNEY TO ALASKA
Achievements and lessons learned introducing
large scale agile development
3. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 4Public
RESEARCH &
DEVELOPMENT
10% of turnover in-
house R&DEXPERIENCE
65 years !
GLOBAL PRESENCE
30 engineering
locations with 220
test beds
45 affiliates
STAFF
8,600 employees
65% engineers &
scientists
AVL LIST GMBH
TURNOVER 2016
1.4 billion €
Passenger Cars Racing2-Wheelers
Construction Commercial VehicleAgriculture
Locomotive Power PlantsMarine
Powertrain Engineering
Simulation & Testing
Development Platform
ITS –
Instrumentation
& Test Systems
4. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 5Public
INSTRUMENTATION & TEST
SYSTEMS (ITS)
ITS-I
Integration
Software
Products
5. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 6Public
ITS-I FACTS
6 Development Centers 46 Agile Development Teams
½ to 2 Year Release Cycles20 Software Products
6. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 7Public
AGILE JOURNEY TO ALASKA
Q3 / 2011
Introduction of agile teams
2012
Agile Development Center Zagreb
2013
More teams switch to agile, experiments
with scaling in product context
May / 2014
Kickoff Definition of ALASKA
Oct / 2014
Roll-out of ALASKA
Nov / 2014
Start of Agile Programs
Dec / 2015
First year of ALASKA, Kick off ALASKA Wave#2
Improvement Project
Today
11 Program Iterations
done
ALASKA = AVL‘s Lean and Agile Software Development Process with Kaizen
7. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 8Public
WHY ALASKA (AND NOT STOP AT
SCRUM)?
Mount Mc Kinley (Denali) 2012 061 by agmur is licensed under CC BY-ND 2.0
Coordination of 250 developers
in 46 teams
Common portfolio vision necessary
Alignment of system releases and
development teams regarding
value, content, and schedule.
Management of work instead of
management of resources on all levels
of the organization
8. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 9Public
ALASKA IS TAILORED SAFE 3.0
5 agile release trains (programs)
Additional role in product management
Fixed cadence for all teams and programs
5 program iterations (PI) per year
1 PI has 4 development and 1 IP sprint
2 week sprints
Adapted terminology
ART = Agile Program
RTE = Agile Program Manager
PI = Program Iteration
Scrum Master = Agile Master
+ Agile Coach
+ Customer project co-ordination
+ Maintenance co-ordination
+ Test Center for System Validation
9. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 10Public
THE CHANGE PROJECT
Alaska RR by Ron Reiring is licensed under CC BY 2.0
10. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 11Public
THE CHANGE PROJECT
Process Definition Communication
Implementation Lessons Learned
Oh what a beautiful morning by JLS Photography - ALASKA is licensed under CC BY-NC-ND 2.0
11. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 12Public
THE CHANGE PROJECT
Process Definition
Central Sharepoint documentation
15 work groups with experts for
different process areas including
~ 75 participants
Oh what a beautiful morning by JLS Photography - ALASKA is licensed under CC BY-NC-ND 2.0
12. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 13Public
THE CHANGE PROJECT
CommunicationRegular information meetings
Bi-weekly internal newsletter
&
Enterprise Social Network
Branding: Posters, Flyers,
Stickers, Planning Poker cards
Oh what a beautiful morning by JLS Photography - ALASKA is licensed under CC BY-NC-ND 2.0
13. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 14Public
THE CHANGE PROJECT
Implementation
Role-based trainings Staffing
Content preparation
Oh what a beautiful morning by JLS Photography - ALASKA is licensed under CC BY-NC-ND 2.0
14. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 15Public
THE CHANGE PROJECT
Oh what a beautiful morning by JLS Photography - ALASKA is licensed under CC BY-NC-ND 2.0
Lessons Learned
Involve all stakeholders early Make sure tools are available
Do not be afraid of change in
the change project
15. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 16Public
ALASKA IN PRACTICE
16. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 17Public
Backlog Items
ALASKA ON TEAM LEVEL
Agile Team
Development
Team
Development
Owner (DO)
Agile Master
(AM)
DO Dev
Team
DO
AM
Team
Team Backlog
User Story
Architectural Story
Defect
Spike
17. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 18Public
Program Iteration
(10 weeks)
Program Iteration
(10 weeks)
ALASKA ON PROGRAM LEVEL
Program Backlog Grooming
Release
Planning
Preparation Release
Planning
Meeting
Program Iteration Progress
Inspect &
Adapt
Meeting
Program
Increment
Done
On Demand: Prepare
Market release
Product
Management
System
Architect
Agile
Program
Manager
Program
Steering
System
Team
Feature
Team
Component
Team
Program
Backlog
18. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 19Public
DISTRIBUTED RELEASE PLANNING MEETINGS
Communication with India Draft Plan Review
Planning Board
Breakout Session
Final Plan Review
19. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 20Public
INSPECT & ADAPT MEETINGS
Program RetrospectiveSolution Demo
20. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 21Public
OUTCOMES OF IP SPRINTS
Virtual Testbed Testbed Data on Mobile App
21. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 22Public
IMPLEMENTATION OF KAIZEN
Kaizen-2.svg by Majo statt Senf is licensed under CC BY-SA 4.0
22. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 23Public
CONTINUOUS IMPROVEMENT
Organizational Level
Team Level
Coaching of Agile Teams
Assessment of Team Maturity
Program Level
Problem Solving Workshops
ALASKA Wave#2 Project
23. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 24Public
COMMUNITIES OF PRACTICE
Agile Master Agile Testing Code Quality
Architecture Xray
The Noun Project by Edward Boatman is licensed under CC BY 3.0
24. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 25Public
AGILE TESTING &
CODE QUALITY COP OUTCOMES
Doncaster Knights by Alan is licensed under CC BY-NC-ND 2.02014-04-05_06-58-01 by Jakob Hürner is licensed under CC BY-NC-ND 2.0
Standard Tools Package Software Quality Trainings
Software Quality Baseline Dev Cafes
25. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 26Public
AGILE MASTER COP
Agile Master Exchange Regular Book Reviews
Book Club Discussion by Alper Çuğun is licensed under CC BY 2.0
Share Practices
iron filings tracing the magnetic field of a bar magnet by Dayna Mason is licensed under CC BY-NC-SA 2.0
Aligment
Retrospectives
Retrospectives
26. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 27Public
Peer Group Coaching
Every 2-3 months
COACHING PROCESS
Meeting Checkup
Every 6-12 months
Monthly AM Coaching
Initial Meeting
Checkup & AM
Coaching
AM as AM Coach
27. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 28Public
Project Leader
Development Project
DECENTRALIZATION OF
RESPONSIBILITIES
Scope
Management
Work
distribution
Budget
Duration
Product
Release
Dependencies
Staffing
Annual budget for
products fixed is based
on team size
Fixed development
cadence and releases
planned every 10 weeks
Team assignement and
sizes relatively stable
Teams organize their
work based on backlog
priorities
Product Owner
Hierarchy: Product
Manager, Content
Manager, Development
Owner
Development Teams,
System Team, Test
Center, Release
Coordination Meeting
Release Planning
Meeting, Scrum-of-
Scrums, Release
Coordination & Program
Steering Meetings
We don‘t
need a
single hero!
29. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 30Public
LESSONS LEARNED
Fix terminology early in order to prevent
discussions later
Communication, training and coaching
never stops
Doncaster Knights by Alan is licensed under CC BY-NC-ND 2.0
Communities of practices foster
collaboration across boundaries
20th July 2013 Berlin Mini Game Dev Jam by Iwan Gabovitch is licensed under CC BY 2.0
Use information radiators with meaningful
metrics
30. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 31Public
PERCEIVED IMPROVEMENTS
More frequent releases Higher transparency of development process
Better alignment of overall output More Focus on results instead of metrics
UPS parcel route driver by MobiusDaXter is licensed under CC BY-SA 3.0 Transparency by HonestReporting is licensed under CC BY-SA 2.0
31. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 32Public
CHALLENGES AHEAD
Change of culture & mindset towards agile
enterprise
Systems Engineering
Release in-time and in-quality on system level Establish cross-product roadmaps with
unambiguous priorities
ALASKA Logo muss sichtbar sein -> auf den Folien Master?
20 software products
Stand-alone products sold directly to end customers
System products delivered to internal customers to build test systems
Release & life cycles:
SW product releases vary between twice a year and once every 2 years depending on product
Life cycle of products between 3 years for office products to 20 years for test bed automation
6 development centers:
Austria (Graz), Croatia (Zagreb), India (Gurgaon), US (Detroit), Germany (Bensheim / Gaggenau), Belarus (Minsk)
46 agile development teams with around 250 developers
Typically 6 developers (incl. Integration and test)
Cross-functional, but some are still more component than feature-oriented
1. Coordination of 250 developers in 46 teams with various dependencies in
Strategy
Technology
Product interfaces
Customer projects (= solutions)
2. Alignment of customers and stakeholders regarding development content priorities and expected results on portfolio level
3. Development programs align
Product / system release view with development view
Development teams regarding customer values, contents, schedule & milestones, dependencies, risks
5 agile release trains (programs)
1 release train = 1 value stream
Own hierarchy of product management to reflect market product and technical solution view
Fixed cadence for all teams and programs
1 year has 5 program iterations
10 week program iterations with 4 development and 1 IP sprint
2 week sprints
Own terminology based on introduced concepts, e.g.
ART = Program
RTE = Agile Program Manager
PI = Program Iteration
Scrum Master = Agile Master
Process definition: 15 expert work groups contributing to process involving ~ 75 people
Communication:
Regular management and all-employee meetings
Internal Newsletter (bi-weekly) with regular column on ALASKA
Facebook-like broadcast and feedback medium (we used Salesforce Chatter)
Branding: Name, Logo, Sticker, hand-outs, posters, team-name stands, Planning poker cards
Company-wide public SharePoint with process information & FAQ (taken from feedback)
Training: role-based, practical examples, agile mindset, re-train Scrum concepts! (estimation, DoD, …)
Staffing: Team roles, Program roles
Content preparation before 1st program iteration:
Definition of Ready / Done for all requirement & result levels
Readiness check before Release Planning Meeting (RPM)
RPM dry-run before 1st RPM with real life examples
Lessons learned
Process definition: 15 expert work groups contributing to process involving ~ 75 people
Communication:
Regular management and all-employee meetings
Internal Newsletter (bi-weekly) with regular column on ALASKA
Facebook-like broadcast and feedback medium (we used Salesforce Chatter)
Branding: Name, Logo, Sticker, hand-outs, posters, team-name stands, Planning poker cards
Company-wide public SharePoint with process information & FAQ (taken from feedback)
Training: role-based, practical examples, agile mindset, re-train Scrum concepts! (estimation, DoD, …)
Staffing: Team roles, Program roles
Content preparation before 1st program iteration:
Definition of Ready / Done for all requirement & result levels
Readiness check before Release Planning Meeting (RPM)
RPM dry-run before 1st RPM with real life examples
Lessons learned
Process definition: 15 expert work groups contributing to process involving ~ 75 people
Communication:
Regular management and all-employee meetings
Internal Newsletter (bi-weekly) with regular column on ALASKA
Facebook-like broadcast and feedback medium (we used Salesforce Chatter)
Branding: Name, Logo, Sticker, hand-outs, posters, team-name stands, Planning poker cards
Company-wide public SharePoint with process information & FAQ (taken from feedback)
Training: role-based, practical examples, agile mindset, re-train Scrum concepts! (estimation, DoD, …)
Staffing: Team roles, Program roles
Content preparation before 1st program iteration:
Definition of Ready / Done for all requirement & result levels
Readiness check before Release Planning Meeting (RPM)
RPM dry-run before 1st RPM with real life examples
Lessons learned
Process definition: 15 expert work groups contributing to process involving ~ 75 people
Communication:
Regular management and all-employee meetings
Internal Newsletter (bi-weekly) with regular column on ALASKA
Facebook-like broadcast and feedback medium (we used Salesforce Chatter)
Branding: Name, Logo, Sticker, hand-outs, posters, team-name stands, Planning poker cards
Company-wide public SharePoint with process information & FAQ (taken from feedback)
Training: role-based, practical examples, agile mindset, re-train Scrum concepts! (estimation, DoD, …)
Staffing: Team roles, Program roles
Content preparation before 1st program iteration:
Definition of Ready / Done for all requirement & result levels
Readiness check before Release Planning Meeting (RPM)
RPM dry-run before 1st RPM with real life examples
Lessons learned
Lessons learned:
Involve all stakeholders:
Directly affected
Process interfaces, internal customers
Controlling
Worker Council
Tools
Tools for performing the process are available, especially when previous process was well supported by tools
Adapt
Do not be afraid to change plans or activities
Learn and fail fast during early iterations
Focus on rituals
Setting:
Most participants in Graz
Satellites in Germany, Croatia, India, Belarus
Same time, same place (planned for whole year in advance)
Excellent IT infrastructure incl. backup network, cameras & microphones, recording capability, separate infrastructure-only guy monitoring communication quality
All common activities (Product vision, Preliminary & Final Plan Reviews, Risk Management, Voting) are streamed live to all participants
Communication „islands“ (outside of team room) for small ad-hoc teleconferences
For near shore teams – get representatives on premise (DO, AM/or other developer)
Not done yet: Program Planning Board (online, visible for all)
PL-DP – Project Lead Development, responsible for Development Projects: Scope Management, Staffing, Budget, Duration, Project Success, Dependencies to other projects,Tasks in addition to pure development (release focus, quality/bug fixing / stabilization)
1. Communication & training never stops! Re-train agile values!
2. Simple metrics in the I&A and at the information radiators help to create awareness for problems
Meaningful metrics
BIG information radiators – feature burn down slow improvement
Reduce metrics in I&A „Quantitative Measurement“ part to a few relevant metrics (where are problems, which are change indicators)
3.
Check impacts on organization
Is a reorganization necessary?
When changing role assignments / job descriptions -> HR topic (titles, remuneration, …)
Staffing the roles takes a lot of decisions and typically longer than expected
Especially finding the right people for Agile Masters, Agile Program Managers
System team vs team level testers & integrators
Architectural component teams function teams
4. Fix the terminology early, people get used to terms very fast and it is hard to change later
5. 4 CoPs established (AM, Testing, Code Quality, Architecture) – more to come…
---
Involvement of business people can be difficult, if business & development are far apart invite them to RPM to give presentations
2 releases per year instead of one release per year for our big products
The whole development process is much more transparent
Everyone in the organization can see who is working on what project, feature, story,… (e.g. Daily Stand-ups, Jira)
Problems are detected and communicated earlier (e.g. technical problems, scope changes, dependencies)
Better alignment / communication between projects / products (dependencies are earlier addressed, duplications are prevented) -> less waste
Increased portfolio focus (instead of product focus) -> better alignment of overall output
More focus on results (working software) instead of metrics
1.
Commitments: Over-commitments part of culture, no consequences, RPM commitment stronger than real results
Bad finisher-culture, (cross-)team-thinking must increase, responsibilities need to be fully taken over by team, DO, CM, PM, AM
2. Automation of tests and integration are needed on system level in order to be able to create PSI every sprint
Dependencies between component teams