The automotive industry is currently undergoing a disruptive change. Driven by electrification, automated driving, and connectivity, the classic vehicle is being transformed into a software-defined internet-of-things (IoT) device.

Elektrobit (EB) has been a global supplier of embedded and connected software products and services for the automotive industry for more than 30 years. EB’s software powers over 1 billion devices in more than 100 million vehicles. Since 2015 Elektrobit is part of German automotive giant Continental AG.

After working as a CTO for a successful start-up for several years and having developed a DevOps mindset, I (Roman Pickl) joined Elektrobit in 2018 shortly after it had reorganized to become a Product Company (Project to Product). As technical project manager in EB Assist, which provides state-of-the-art hardware and software products to successfully develop, test, visualize, validate, and build ADAS and automated driving functions and systems, I’m is in charge of a distributed 30 person product development team and part of the company wide DevOps Community of Practice.

The main business problem we faced is delivering value in a flexible way, at speed and high quality to our internal and external customers. We were hindered by long development cycles, 6 month budgeting periods, high workloads and priorities that were often changing. A full cycle of building and testing one of our software and hardware products took more than 24 hours. So when you did something in the afternoon, you sometimes didn’t get feedback at the following day, but the day after. It had a negative impact on developer moral and felt like quicksand: the more we fought it, the more it pulled us in. We knew there must be a better way.

Applying the 3 Ways of DevOps, especially by experimentation and by identifying bottlenecks in the build and test run, we were able to cut the full build/test cycle by a factor of 3 in the first few months of 2018. Moving our code to a git mono repo and containerizing our build environment in 2019 allowed us to provide feedback to our developers on every commit within minutes, not hours. Furthermore, automating our delivery allowed us to provide a new version of our software with the click of a button. This was great and we felt happier and so freaking agile.

Briefly after moving to a new office in 2019, and knowing about the importance of making work visible and after having learned about the Flow Framework, I implemented a dashboard using an open source solution (smashing) which automatically gathered and visualized, among others, Flow metrics (Flow Load, Flow Time, Flow Efficiency, Flow Distribution, Flow Velocity) for our value stream. After putting in countless hours eliminating waste, improving the deployment pipeline, investing in automation and deploying new technologies, I wanted to answer a fundamental question: “Are we really moving faster?”

It took me a while, and listening to Beyond the Phoenix Project and reading The Goal, to understand:

-We were creating a lot of inventory.

-We had a fast lane for fixes, but it still took us too long to ship features.

-We delivered more often, but the new bottleneck shifted to testing.

It became clear that we were trapped in local optimization (now described by Jon Smart as the Local Optimisation & the Urgency Paradox), we had a limited system focus, and needed buy-in to influence the process up- and downstream. At the same time the organization identified three focus programs to improve flow: Delivery Performance, Organizational Development and Empowerment which will be rolled out in 2020.