Achievements and Lessons Learned Introducing Large Scaled Agile Development
•Download as PPSX, PDF•
0 likes•262 views
Presentation given at the Agile Austria Conference 2017 in Graz. Track: Scaling Agile "Achievements and Lessons Learned Introducing Large Scaled Agile Development" Speakers: Stefan Wunder & Robert Dietze
Recommended
Recommended
More Related Content
Similar to Achievements and Lessons Learned Introducing Large Scaled Agile Development
Similar to Achievements and Lessons Learned Introducing Large Scaled Agile Development (20)
Recently uploaded
Recently uploaded (16)
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
- 2. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 3Public INTRODUCTION
- 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!
- 28. Robert Dietze, Stefan Wunder | ITS-I / I_Q | 28 Juni 2016 | 29Public CONCLUSIONS
- 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
Editor's Notes
- 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