A-SPICE: Inherent Vice?

API-first Thinking for Processes

A-SPICE has nothing to do with spices. It is the acronym for Automotive  Software Process Improvement and Capability dEtermination. It receives some bad press recently and is often called guilty to slow development down. The thing is: it is not a process. It is not intrinsically bad. It just depends on the context and what you make out of it. No bashing of anything in this article. Here ideas in forward direction. You can replace “automotive” with any industry you like. I am 100% certain the concept is transferable.

My personal view:

Automotive processes do not need to be slow and overloaded. It depends on how you build them. Facts:

• Nobody ever said, automotive processes need to contain tools. Tools need to support what you are doing. Tools support methods. Nothing else is relevant.
• There is a natural food chain. Processes <– methods <– tools. Processes are supported by methods. Methods are supported by tools.
• Processes need to describe the outcome of the development process. Period.
• Nobody ever said, automotive processes need to contain methods. Methods describe ways to execute tasks that lead to outcome.
• Note: Output is not evil in itself. Sometimes outputs make sense for the execution of your method of choice. Metering output however is not a measure of success in general. In cases like Tayloristic workflows, it is, but it is not a global truth.

In consequence:

1. Separate the process from the methods that are used to deliver the process outcome. The process defines the succession of outcomes. Methods help us to generate the outcome.
2. Multiple different methods thus can lead to one process outcome. No more discussion of an “agile process” or “classical process”. The process can be the SAME, as the process defines outcomes, not outputs.
3. The process points to potentially different methods, leading to the same result. The process is method-agnostic.
4. The method now can be of “classical” or “agile” character. It actually does not matter at all.
5. Each of the different methods employed, uses tools to support the methods. Alternative tools are possible. The methods need to be tool-agnostic.
6. It is possible that two teams use different tools to deliver similar outcomes in the same process.

Yes, this is describing a tree. The process-method-tools landscape does not really need to be a simple graph, as one tool could support two different methods, but you get the picture. I do not want to overcomplicate things.

Therefore, if a tool is exchanged, the process does not need to change. Why should it? I can describe the process through the outcomes constructing the process. The output belongs to the method. i.e. it is method-internal. The same applies to the methods themselves. Why should the process change when I am using a new method to generate the same outcome? Makes no sense.

Think API-first in the context of the process.

You are thinking I am nuts? Maybe yes, but trust me, a process landscape like this is possible.

Use a general rule: No process step shall be more than three sentences long. English sentences, not German ones. It needs to be simple to read and understand. That is enough. Short and concise descriptors are the source of the API strategy. If I get tired reading the process, is it digestible for the developer? I do not think so. Put a bit of design thinking into the process development. Who exactly is the user of the process? What is the target? What does the user need right now? … Keep it simple and modular.

More points:

• Method descriptions shall be method descriptions and typically contain trainings or link to trainings. Sorry, if your developers do not know how to generate a process outcome, train them or better, give them access to training so they can learn what they need. It is not the job of the process to deliver knowledge and skill. Educating people is what line management (which also in agile setup exists, even if it is realized via self-managed teams) needs to do.
• Methods are supported by tools.
• You can model your process in a tool. Fine. It shall then lead the developer and project manager or product owner through the steps of the process. Understand that the process shall support product quality. It is not a flow chart for the activities to be executed by the developer or any other project member. The flow chart of the activities is call “method”. See above: not part of the process.
• Another word on tooling: The lifetime of a tool typically is short. Exchanging a tool is a big pain, unless your tool supports a standard interface. If there is a standard interface, I can exchange the tools. Anything else is a vendor lock-in strategy. “No problem, I will adapt my tool to your process.” I have my opinion on that. You might want to look at Data Centric structures.

If you let all of this marinade a bit, you will discover how to iteratively develop and improve a process including associated methods and supportive tooling.

A-SPICE is not evil. It is simply not always used in a smart way.