A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.
Visteon Corporation
Agile in Automotive
Automotive SPICE® (ASPICE) of the Verband der Automobilindustrie (VDA, German Association of the Automotive Industry) is a methodology to evaluate an organization’s methods and capabilities to develop automotive projects. Following ASPICE enforces that – at least – certain work products are produced and best practices are followed.
The underlying idea of how a project should be developed, called the V-Model, looks similar to the well-known waterfall model, - however, a waterfall model is not the only way to implement the process.
For the tiniest possible ASPICE-compliant project at least two people are required: A quality engineer to check the work products of an engineer who creates everything. For any production, project far more engineers will contribute and work in parallel to be able to deliver a product in a few years.
The different processes are led by engineers who are using the input of the other skills and processes to complete their process. While ASPICE mainly focused only on software previously, the hardware and mechanical engineering processes are also covered today.
Visteon strives to follow ASPICE – recently achieving Level 3 compliance in a cluster project – and improve its methods to apply them company-wide.
Scrum
Scrum is an agile framework for managing development with an emphasis on software development although it can be applied to other disciplines as well. It is designed for small teams(3-9 people) to break their work into actions that can be completed within time-boxed iterations called sprints. Besides the development team members, Scrum the Product Owner and Scrum Master roles.
Visteon typically does not use cross-functional teams but uses tools and processes to flow work results from one team to another in the V-Model. Teams are generally focused on a particular ASPICE process or processes. For example, one team focuses on SYS.1 (requirement elicitation) and SYS.2 (system requirements) while another team works on SYS.3 (system architecture).
The Product Owner is in charge of creating and maintaining the backlog of work to be done by the development team. Within Visteon, this is structured hierarchically as discussed in the Vistway section.
At Visteon, the Scrum Master is typically one of the development team members. Their function is to help the development team schedule their work, remove any impediments to completing that work, and act as an interface between the Product Owner and the development team members.
Kanban
During the final phase of a project, the pressure on a development team is immense. The software must become stable and end-customer ready. This can mean that some features must be postponed or modified to be able to deliver the project in time. For maximum visibility, change requests and defects are tracked within a clear structure of Scrum teams working on them. Work items are created describing the work needed to fix the defect or implement the change requests which are then allocated to teams and individuals. Work items can be estimated in hours or story points and care is taken not to overload any one person per the estimations while maximizing the number of tasks being worked on in parallel.
LeSS Huge and Vistway
LeSS attempts to define the barely sufficient processes needed for large-scale development. It avoids adding additional roles, artifacts, or processes, as it realizes the drawbacks of these additions. Conceptually, LeSS Huge is LeSS scaled up further by having multiple (smaller) LeSS frameworks stacked on top of each other. Vistway refers to Visteon’s internal development processes based on LeSS Huge principles.
To develop a deliverable product, 200+ engineers are needed in the core team of an advanced driver-assistance system (ADAS) project.
The Project Management team creates and redefines Scrum teams and ensures the Scrum teams have everything they need to successfully complete their work.
The System Engineering team is in charge of eliciting customer requirements and deriving system requirements from those customer needs. During this process, the team finds and resolves requirement conflicts. Important properties, which have to be true and affect several system elements, are requested to be noted down as system requirements.
An Architects and Design Champions team, led by the system architect and including system, software, and hardware architects create the various architectures. They are supported by design champions and area experts from other skill areas.
The Software Management team consists of the software “Super” Product Owner and the Product Owners from the software engineering teams. This team is in charge of maintaining the overall software backlog. Visteon uses Work Packages as the root of all work; they are owned by an individual Product Owner. The Product Owner creates Epics for each involved team. The teams create stories and tasks depending on their impression of the complexity of the problem. Reporting tools summarize on Epic level, illuminating why a particular Work Package is delayed and identifying bottlenecks. This allows the Project Management team to implement countermeasures as early as possible.
Software Engineering teams, together with design champions, develop the software requirements together with the architects and system engineers, create detailed software designs and implement software including unit tests.
System Integration and Framework teams set up and maintain continuous integration environments for software. Work products are automatically collected, built, baselined, and integration tested. The teams also watch that the architecture is followed and unit tests pass through reporting code coverage and other metrics.
The System Validation team writes and performs software qualification tests on the integrated software products, both in simulation and on real hardware.
The Functional Safety team is independent, reporting to the directors in a separate reporting tree. They analyze the design to ensure it meets the safety requirements and help the architects and design champions to build a system which not only works but is also safe and fault tolerant.
The Quality Assurance team also reports independently. They audit work products produced by the other teams and highlight gaps to the teams and management.
Project Organization
For an ADAS project the organization has the following domains:
In contrast to classic electronic control unit (ECU)projects, an ADAS project adds vehicle integration and vehicle-level system requirements to the processes to be performed. Continuous integration and testing is often not possible with real vehicles as any change could lead to a disengagement.
Continuous Improvement
At the core of agile is continuous improvement. This is not only exercised after each sprint where the team reflects on what went well (and thus continued) and what went badly (and thus improved). It also applies to continuous integration. Visteon uses Jenkins continuous integration servers configured such that the code changes of any team are immediately integrated into the whole product and tested in simulated and real hardware environments. Integration engineers choose from these changes which baselines shall be used for integration into the product and shall be validated by the validation team.
Outlook and Opportunities
In automotive, the product generation process is increasingly based around the agile approach. Reasons for this include reduced product creation time, separation of hardware and software development - as well as late changes on features and functions. Also more and more automakers and partners contribute with their own software development towards product definition and develop within the product creation schedule.
Customers can see at any time the progress and status of a project. They can give close feedback, where improvements are needed and which features or functions should be improved. It is even possible for customers to embed their engineers into the Scrum teams, who can contribute directly to creating an even better product.
This agile development method also enables new business models. A whole eco-system of contributors can be included and agile-based contracts enable continuous improvements, changes and also late adaptations.
Perception of Agile
Customers appreciate the quick turnaround times of agile development. The details of a project don’t have to be set in stone at the time of sourcing but can be evolved during the course of development within reason. Employees appreciate agile, especially the Scrum aspects of equal measures of responsibilities and independence. Scrum and Kanban deliver quantAifiable statistics which can be used for long and short term planning of the current and future projects.
