1. Kay-Ulrich Scholl Applying agile SW development methods in a non-agile friendly environment. May 22, 2014 - Agile and Lean Development Conference 2014

2. Content Environment: an automotive business project Phase I: First attempts to apply agile methods Phase II: Issues and how we solved them Phase III: Further improvements (applied for development of next product generation) Lessons learned / best known methods Next steps to do (Phase IV) 2

3. In-Vehicle Infotainment System 3

4. Automotive Spice Processes and tools over individuals and interactions Comprehensive documentation over working software Contract negotiation over customer collaboration Following a plan over responding to change 4 Automotive Spice appears as a contradiction to Agile

5. Already given by defined project & environment Complete feature set already acknowledged Feature release plan (waterfall model) Delivery was not SW only Startup environment very new site in Karlsruhe and organisation Many teams located X geo 5 Defined Project boundaries conflictive to SCRUM/sprint approach!

6. Expert Teams and their Domains 6 Core Services Infra- structure Utilities Board Support Package Connectivit y MediaSpeech Update Diagnosis Expert teams on stacked layers instead of vertical slices.

7. AGILE ? 7 Had some good experience in Agile

8. Phase I: Apply agile Installed a build environment and server infrastructure (repository, continuous build and test) Installed all necessary tools to ensure additional SW quality (static and dynamic code analysis), created a coding style guideline Defined multiple SW development teams + 1 integration team and trained them on Scrum Used an online scrum tool Installed a daily standup on manager/product owner level to raise issues Installed an architectur core team to discuss X-team architecture issues 8 Just started to apply Agile!

9. Phase II: Issues and we solved them „Scrum does not work for us!“  Discussed issues with experienced persons X-team issues  Scrum of scrum Sprint plans very often had to be adapted during the sprint because of heavy impacts (critical defects, change requests, direct customer support)  Found a process to deal with these changes. Backlog creation took much longer than expected and was quite unstable  not an issue, information still helpful Big bang integration  Staged integration 9 Agile can be adapted if you seriously work on issues when they appear

10. Staged Integration Timeline Stage-1 Stage-2 Stage-3 10 Sometimes some very special solutions are necessary!

11. Visualize progress: story points 11 Story point usage turned out to be useful and worked better and earlier than expected

12. Phase III: Further Improvements Closed loop in Software factory  very early integration feedback Additionally release a SW version every 2 weeks (after EVERY sprint)  customer benefits from early bugfixing and new features Create special feature branches on long-term X-team features  ensure stability of continous build and integration Defects are pre-evaluated and considered in sprint plan  significantly reduced exceptions with impacts on sprint plans 12 Agile process improvement never ends!

13. Continuous Validation Continuous Integration Continuous Build “Software Factory” = ASD Software Factory 13 Automatic processes are your best friends!

14. Lessons learned / BKM DO NOT APPLY SCRUM BY THE BOOK! Look into Agile Principles! Ask other teams to share experiences, even if you think you do not need help! Have tools & infrastructure in place (software factory, scrum tool) Have everything build automatically from your repository content (including documentation!) Do not forget to establish a clear defect and change managment 14

15. Lessons learned / BKM (cont.) Accept a negative impact on progress in the early phase. Negotiate with management! Establish X-team synchronization processes (e.g. scrum of scrum) Start with 2 weeks sprints. Collect issues during sprints rather than asking for input in the retrospective (at a central point where everybody has access)! Give every idea for process improvement a try. Don‘t change too much at once. 15 Maybe you do not end up using Scrum but you‘ll end up in a light weight process that works for you!

16. Next steps to do (Phase IV) Fill missing gaps for automotive spice: Document all processes throughout the organisation Tracability: Link requirements, change requests, bugs, stories, release changes, etc. Perform internal Audits to proof a certain spice level 16

17. Questions? 17

18. Legal Notices This presentation is for informational purposes only. INTEL MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. [BunnyPeople, Celeron, Celeron Inside, Centrino, Centrino Inside, Core Inside, i960, Intel, the Intel logo, Intel Atom, Intel Atom Inside, Intel Core, Intel Inside, the Intel Inside logo, Intel NetBurst, Intel NetMerge, Intel NetStructure, Intel SingleDriver, Intel SpeedStep, Intel Sponsors of Tomorrow., the Intel Sponsors of Tomorrow. logo, Intel StrataFlash, Intel Viiv, Intel vPro, Intel XScale, InTru, the InTru logo, InTru soundmark, Itanium, Itanium Inside, MCS, MMX, Pentium, Pentium Inside, skoool, the skoool logo, Sound Mark, The Journey Inside, vPro Inside, VTune, Xeon, and Xeon Inside] are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Microsoft, Windows, and the Windows logo are trademarks, or registered trademarks of Microsoft Corporation in the United States and/or other countries. Java and all Java based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Bluetooth is a trademark owned by its proprietor and used by Intel Corporation under license. Intel Corporation uses the Palm OS® Ready mark under license from Palm, Inc. Copyright © 2014, Intel Corporation. All rights reserved.

20. Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 20