While technology companies worldwide have adopted agile and lean principles for software development, the automotive industry lags behind. The automotive sector norm remains delivering defined work packages by a specific deadline. With increased consumer demands for high-tech infotainment systems and the most up-to-date driver assistance technologies, this traditional, time-consuming software development approach doesn’t work anymore.
The Lean Development Model overcomes the challenge by combining various lean and agile development methods to create a shorter development cycle with less errors and the flexibility to adapt to new requirements and demands.
Customers nowadays have high expectations:
- Automobile infotainment systems that offer them the same features as smartphones and other mobile devices
- The latest technologies when they buy the car and throughout the car’s life cycle—with updates after purchase
Sequential development processes such as the waterfall approach and the V-model are limited, making it difficult or impossible to respond quickly and comprehensively to changes.
Keep it simple
The most practical approach is to develop software to the specific requirements of a project rather than to create a large, generic framework. Such frameworks put an excessive burden on computing power, result in obsolete and unnecessary code as requirements change, and are more error prone.
Software developed according to KISS (Keep It Simple, Stupid) and Clean Code principles is more maintainable in the long run and less susceptible to errors.
The Lean Development Model adheres to KISS and Clean Code rules, combining agile and lean principles—while being specifically tailored to automotive software development. The model consists mainly of Scrum and Kanban techniques, with additional methods from extreme programming (XP) to support the software development process.
Lean Development Model combines agile methods with lean software development principles.
From Scrum and Kanban to the Lean Development Model
In 2008 Elektrobit Automotive introduced Scrum to organize the development of features for an infotainment system. As the project went on and reached the maintenance phase, the team decided that applying Kanban software development methods would be more suitable for stabilization and optimization work. When new features were to be developed, the team combined the best of Kanban and Scrum. Additional refinements led us to the Lean Development Model approach.
In this approach, task tickets are combined into stories. Each story represents one feature of the system being developed, such as an infotainment system. Thus, the product is built based on stories, corresponding to individual customer features.
Lean Development Model principles
The Lean Development Model primarily follows seven principles:
Deliver as fast as possible
The goal is to move quickly and deliver early. Every member of the team is responsible for ensuring that there is no stagnation. Unlike in a traditionally managed project, work tasks aren’t assigned in advance by the project manager. Work packages are pulled by the team from a prioritized backlog. The team members are responsible for pulling them through the workflow steps (pull rather than push).
The team independently pulls the tasks into the next workflow step.
Activities that have commenced (i.e., tickets) have to be completed before new ones can be started. To encourage efficient work, breaks or pauses aren’t deducted from the “cycle time” (i.e., the time for task completion). For example, if a ticket is blocked awaiting customer feedback, the clock continues to tick.
This procedure enables daily deliveries to the customer at an early stage of the development process. That means the customer can provide early feedback for the continuous improvement of specifications and implementation.
Build in integrity
The Definition of Done (DoD) is crucial for quality assurance and is defined by the team at the outset of the development process. Changes have to be implemented by following all defined steps as well as being documented and verified by reviews. (See Fig. 3)
Description: A defined sequence of test steps guarantees the quality of new and modified code
This makes it easier to identify issues in a timely fashion. The high degree of automation results in finding bugs faster. Tests are scaled according to project phase and type of delivery:
- Daily smoke tests for the daily delivery
- Focused testing for engineering drops
- Integration tests for key milestone deliverables
- Long-term validation tests for the start of production (SOP)
- Continuous unit tests as an aspect of continuous integration
Automation is controlled by the Jenkins continuous integration tool. Integrated test frameworks allow the simulation of interactions and the proper presentation of results for the testers and developers.
Test parameters for successful testing are established at the outset. Design and architecture stability are improved by compliance with Design for Testability (DFT) and Test Driven Development (TDD) principles with re-factoring.
Decide as late as possible
In long-term software projects, there’s a high risk that the initial plan will be rendered obsolete by changing requirements and frameworks. To avoid this problem, at the beginning of each iteration, the team agrees on all requirements in terms of content so that the story teams can plan in detail. Requirements for future iterations are kept diffuse to ensure that the team can respond flexibly to changes.
The goal: avoid expensive dead ends and keep options open so that the system can be adapted when precise information becomes available.
Eliminate waste
The seven kinds of waste in software development.
To optimally use team resources, the team always concentrates on the feature set required at any given time. Work-in-progress (WiP) limits are set for every team member and each workflow step to prevent too many things from being worked on simultaneously. This reduces change times, hand-over losses, and the error rate.
Since errors can never be completely ruled out, work processes are geared to detect them at the earliest possible time. Equally important, the team identifies and discards features that are no longer required.
Empower the team
Teamwork is based on self-determination, motivation, and commitment to a common objective. The focus is on the individual and his or her competencies. The team continuously adapts the development process more or less independently.
Teams are interdisciplinary and include software architects, testers, and developers. Team communication is supported through a visualization of the workflow on a magnetic wall board. When the team members work at different locations, they have local boards that are synchronized with an electronic overview.
A 10 m² magnetic board supports team communication.
Personalized magnets prevent team members from taking on too much work.
At the daily stand-up meeting team members take turns to report on the story’s current status. This ensures that all team members are equally involved.
Amplify learning
During the daily stand-up meetings, the team addresses problems. Smaller groups discuss and resolve the issues later on. If necessary, the documented rules are adapted to prevent problems from reoccurring. The team retrospectives are used to review the course of the project and identify best practices as well as improvement measures.
Pair programming and reviews, plus an in-house wiki, enable the regular exchange of project knowledge and technical know-how. Furthermore Elektrobit has an in-house academy to support knowledge transfer where anyone can be a participant as well as a trainer.
See the whole
It’s the interaction of all components that creates the end customer’s impression of a product or feature. So, it’s important to test the software not only in a lab environment on development equipment but also in the car, and both on a test track and in everyday driving situations.
Conclusion
Using the Lean Development Model, the car manufacturer is far more involved in the software development process. Instead of receiving finished work packages on predefined dates, the customer gets daily insights into the development progress and can propose adaptations or suggest new ideas at any time. The final infotainment system is more up to date and responsive to market, customer, and business needs, resulting in a superior system.
Christian Hausner
Project Manager at Elektrobit Automotive GmbH. He is a certified Scrum Master and has managed projects for various automotive manufacturers. He supports international projects in applying agile project management methods.
Martin Dusch
Team Manager at Elektrobit Automotive GmbH. He has been a developer and project manager and has worked in quality and knowledge management since 2002. As a certified Scrum Master, he has been involved in agile software development for more than five years.
