When dealing with software development in the automotive domain there are several things to consider. Automotive SPICE (based on SPICE – ISO/IEC15504) and functional safety (ISO26262) were the two main concerns of the past few years. Due to the fact that OEMs put a lot of pressure on their suppliers to adhere to those processes, Agile software development was neglected for quite some time. Even worse, one of the things you often hear when talking about Agile and Lean practices in the automotive industry is, “We have to follow ASPICE, so we can’t go agile.” But is this really the case?
As written in my previous blog post, it is possible to use agile methods within the automotive domain and be fully compliant to ASPICE. It does not even matter if your development team writes C code, does model based design or uses any other method to develop the software. The interesting aspect of agile/lean software development is that it is first and foremost about culture and the way people interact with each other rather than a specific process. Furthermore, as INTACS, the organization behind SPICE, writes in their whitepaper: “Contexts vary, so do ‘best solutions.’ In this respect, this paper has shown that SPICE and Agile complement each other so practical solutions should combine and exploit both sources.”
Sounds good, but how does this apply in practice? Scrum, for example, is rather rigid in the way it is described and ASPICE defines ISO/IEC12207 (Waterfall/V-Cycle) as the standard software development process. Although this seems to make Agile and ASPICE development mutually exclusive, this is actually not the case. Both ASPICE and Agile attempt to do the same thing: continuously improve the development process.
Businesses can have the best of both worlds get the best out of both models by finding compromises and best practices. These include:
- Long-term planning: A release/feature plan does not only provide the customer (internal or external) with a feeling of safety, but it is also a good way to set goals and expectations for the team by providing a high-level roadmap.
- Short development cycles: As long as automated testing and continuous integration are used, releases can be kept very short without much additional effort. This does not only increase the quality through fast feedback but also creates trust with the customer.
- Quality checks: By having Acceptance Criteria (test cases) and a Definition of Done in place it is ensured that all the quality checks are done right away (black box and white box tests, MISRA checks, code reviews, etc.). This improves quality, reduces rework later on and again builds trust and recognition with the customer.
- Daily stand-ups: Getting all team members aligned each day helps cultivate a team feeling, allows them to communicate issues and share knowledge. This way even remote team members feel actively involved and problems can be avoided instead of dealt with later on with additional effort.
- Modular architecture: Starting the development off with a modular architecture allows team members to develop independently. It also provides great support for late requirement changes, overall maintainability and these modules can be easily re-used for future similar projects.
- Kanban: This allows a team to start the agile journey without the need to change the development process significantly. By making the work visible and using continuous improvement processes that are adapted accordingly, quality and efficiency will improve.
Based on my experience of doing ASPICE assessments on Agile teams, I strongly believe that these two worlds can work together and benefit from each other. The key is to focus rather on values than on the strict adherence of methods and to follow a greater vision of making development better and teams happier.
I look forward to your comments on whether you agree or disagree as open discussion will only help us in the long run – and that’s what we are all striving for.