In a development project, you risk falling into chaos if you have too little structure and process. But if you overcompensate and add too much structure and process, you risk getting stuck in bureaucracy instead. We need to add just the right amount of structure and process so that we avoid chaos and not get stuck in bureaucracy. We can call this the “minimum viable bureaucracy”. In my opinion, combining Automotive SPICE with an agile mindset can be the way to minimum viable bureaucracy.
Automotive SPICE, often shortened to A-SPICE, is a reference process model that was defined by the automotive car manufacturers. The development process of a project can be assessed against the reference process and be given an Automotive SPICE level* between 0 and 5. Most car manufacturers have a demand that their suppliers reach a certain A-SPICE level.
Some people see contradictions between an Agile development process and the demands that Automotive SPICE puts on the process. Two groups of people can be heard, where one group says that Agile development is chaos and can never produce quality, and the other group says that A-SPICE only works in waterfall projects and cannot be combined with agile development.
I am not part of any of these groups. I do not see any contradiction between Agile and A Spice. On the contrary I see that Agile and Automotive SPICE fit really well together. And since it is a demand from our customers that we shall strive to achieve Automotive-SPICE level 3, we have no option to disregard the demands that A-SPICE puts on our process.
When you see the V-model in the Automotive SPICE reference model, you might confuse the V-model with a waterfall process. In a waterfall process you need to do things in a certain order. E.g. you need to finish the system requirements before you start writing the system architecture. Or you need to finish the detailed design before you start writing the code. However, A-SPICE does not make demands on in which order things should be done. A-SPICE says what shall be done. But not how, or in what order. One the other hand Agile development processes does just that, defines the how. That is why A SPICE and agile goes so well together.
The agile development concepts of Definition of Ready and Definition of Done fit very well together with A SPICE. The Definition of Ready says what need to be completed before you start working on a task. Definition of Done defines what you need to complete to consider a task to be done. You can take the content, “the what”, from Automotive SPICE and add it as components of Definition of Ready and Definition of Done. E.g. for a SW development task the Definition of Ready can contain that the software architecture needs to be in place. And the Definition of Done can contain that the code need to be constructed, the unit tests written and the design documents updated.
Another part of agile development is the practice of built in quality where you build in quality into the process to ensure that quality standards are met. One example of this is to use a software version control system like GIT, where you make it possible to add new software only if you have done a code review. Doing like this, you will “force” the developers to fulfill part of Automotive SPICE.
And a third area where agile connects well to Automotive SPICE is measurement and risk management. Transparency is one of the core values of Agile. Burndown and/or burnup graphs are used to report the progress of the teams. The teams also have meetings, including daily team meetings and sprint planning that help stakeholders to get a view of the progress. On these meetings the team can raise impediments and risks to stakeholders and the team and the stakeholders together have a chance to adapt and improve.
So, instead of putting Agile vs A-SPICE, I would like to combine the two. Take the what from Automotive Spice + the how from Agile development methods and get a minimum viable bureaucracy and say that:
Agile + A-SPICE = ❤
*Automotive SPICE levels:
0: Incomplete process
The process is not implemented, or fails to achieve its process purpose
1: Performed process
The implemented process achieves its process purpose
2: Managed process
The previously described performed process is now implemented in a managed fashion (planned, monitored and adjusted) and its work products are appropriately established, controlled and maintained.
3: Established process
The previously described Managed process is now implemented using a defined process that is capable of achieving its process outcomes.
4: Predictable process
The previously described Established process now operates predictively within defined limits to achieve its process outcomes. Quantitative management needs are identified, measurement data are collected and analysed to identify assignable causes of variation. Corrective action is taken to address assignable causes of variation.
5: Innovating process
The previously described Predictable process is now continually improved to respond to change aligned with organizational goals.