Allgemeines zu SUP.1
Als letztes Beispiel nach den Engineering-Prozessen, möchte ich hier noch einmal auf die Qualitätssicherung eingehen. Hier gibt es oft Unsicherheiten, weil im agilen Denken, die ganze Qualitätssicherung im Team geschehen soll, Automotive SPICE aber eine unabhängige Qualitätssicherung fordert. Hier müssen wir den Begriff der Qualitätssicherung etwas auffächern. Zum einen geht es um die Absicherung, dass die vereinbarten Prozesse und Methoden eingehalten / angewendet werden, zum anderen geht es um die Absicherung der Arbeitsergebnisse. Beim zweiten Punkt ließe sich noch in das eigentliche Produkt (z.B. Verifikation von Anforderungen) und die Dokumentation (z.B. Review von Dokumenten) unterscheiden. Gerade der Aspekt der Verifikation des Produktes wird auch in klassischen Vorgehensweisen von der Entwicklung (beinhaltet für mich auch Test) und nicht von einer Qualitätsabteilung durchgeführt.
Bei agilen Ansätzen wird das Vorgehen hier ganz ähnlich sein. Die Tests werden in den Teams ausgeführt und eine Instanz außerhalb des Teams, bzw. des Team of Teams, stellt sicher, dass die Vorgaben bezüglich Vorgehensweise und Dokumentation eingehalten werden. Ist eine Qualitätsabteilung außerhalb der agilen Strukturen wirklich agil? Nein, aber es ist ein guter Startpunkt, um die Einhaltung von regulativen Anforderungen im Team of Teams zu prüfen und mit SUP.1 durch das Automotive SPICE Assessment zu kommen. Darauf aufsetzend, kannst du dich Schritt für Schritt in ein agileres Setting bewegen.
Diskussion der Base Practices
BP1: Ensure independence of quality assurance.
Dieser Punkt wurde damals mit der Version 3.0 etwas erleichtert, was die organisatorische Unabhängigkeit angeht. Die VDA-Guidelines erwarten hier dennoch starke Indikatoren für die Unabhängigkeit bezüglich Unabhängigkeit vom Projekt, Unabhängigkeit von Ressourcen und/oder Unabhängigkeit vom Budget. Sie machen aber auch ein Schlupfloch für sehr kleine Organisationen auf: Wenn die Unabhängigkeit aufgrund der Strukturen nicht dargestellt werden kann, sollen zumindest unabhängige Eskalationspfade zu den entsprechenden Management-Ebenen geschaffen werden. Da du vermutlich nicht in einer sehr kleinen Organisation arbeitest und ihr schon über eine Qualitätsabteilung oder ein Qualitätsteam verfügt, könnte diese Argumentation schwierig werden. Wie im Einleitungstext beschrieben, würde ich hier auf die bestehenden team-externen Strukturen zurückgreifen. Lege dir für das Assessment die Argumentation zurecht (Organigramme, Budgetverteilungen usw.).
BP2: Define criteria for quality assurance.
Nachdem die Strategien im PAM 4.0 auf Level 2 verschoben wurden, greift dieser Punkt auf, dass du für dich definieren musst, was Qualitätssicherung für dich bedeutet. Das ist zunächst einmal unabhängig vom Einsatz von Scrum. Dokumentiere hier, z.B. in deinem Wiki, welche Anforderungen und Normen hier hineinspielen (z.B. ISO26262) und leite daraus für dich bzw. deine Organisation ab, was angemessene Arbeitsprodukte und Prozesse ausmacht.
BP3: Assure quality of work products.
Arbeitsprodukte werden über Reviews geprüft. Hierbei gibt es verschiedene „Schärfegrade“, vom Peer-Review bis zur formalen Inspektion. Welche Methode wann zum Einsatz kommt und wann und wo, das unabhängige Qualitätsteam zum Einsatz kommt, sollte aus den Kriterien (BP2) klar werden. Du kannst also zum Beispiel, festlegen dass Dokumentenkategorie X in den Teams als Peer Review reviewt wird und dann stichprobenartig durch das Qualitätsteam abgesichert wird und Dokumentenkategorie Y über eine formale Inspektion geprüft wird, bei der immer jemand aus dem Qualitätsteam dabei sein muss.
In der praktischen Umsetzung musst du Nachweise bringen, also auch Peer-Reviews in den Scrum Teams kurz dokumentieren. Die übliche Praxis, in Review Sessions gleich die Findings zu beheben gibt für das Assessment eine etwas schwache Dokumentationslage. Überlege dir, wie du dokumentieren kannst, was gefunden wurde und wie es behoben wurde, idealerweise, gibt es zwei Versionen des Dokuments (vorher/nachher) und ein Protokoll des Reviews mit den Findings.
BP4: Assure quality of process activities.
Hier kann das Qualitätsteam mit einer festzulegenden Stichprobendichte überprüfen, wie Prozesse und Methoden eingehalten werden. Ein Teil hiervon sind normalerweise regelmäßige interne Automotive SPICE Assessments für einzelne Prozesse. Du kannst solche Einzel-Assessments über die Zeit verteilen, da sie schon etwas Zeit für die Beteiligten verschlingen und zum Beispiel alle x Monate ein internes Assessment im vollen Scope durchführen. Da das alleine gemäß den Guidelines nicht ausreichend ist, musst du auch in Stichproben die Umsetzung vorgegebener Methoden (z.B. FMEA) überprüfen oder auch die Umsetzung von qualitätsrelevanten Vorschlägen aus Retrospektiven.
BP5: Summarize and communicate quality assurance activities and results.
Dieser Punkt ist auch wieder unabhängig von Scrum. Du musst irgendwo dokumentieren, was an Arbeiten zur Qualitätssicherung durchgeführt wurde und entsprechende Metriken pflegen. All das sollte natürlich in Bezug auf die Qualitätskriterien stehen.
BP6: Ensure resolution of non-conformances.
Die Behebung von Problemen kannst du am besten über die Abarbeitung entsprechender Backlog Items nachweisen. Hier musst du natürlich über eine entsprechende Verlinkung in deinen Werkzeugen die Kette nachweisen können, inklusive der Überprüfung der korrekten Behebung. Die Guidelines erwarten ein Fälligkeitsdatum für die Behebung, füge also dieses zu deinem Backlog Item hinzu oder argumentiere über die Zuordnung des Items zu einem bestimmten Release.
Neben der akuten Behebung der Abweichungen, geht es hier auch um Maßnahmen zur Prävention. Hier ist in Scrum die Retrospektive die richtige Plattform, in der du die Themen bearbeiten kannst. Denke nur daran, dass du den Weg der Abweichung durch die Retro bis zur Umsetzung durch entsprechende Links oder andere Dokumentation nachvollziehen kannst.
BP7: Escalate non-conformances.
Für die Eskalation von Problemen ins Management muss zum einen die Vorgehensweise für alle klar sein, also z.B. im Wiki dokumentiert sein (wann wird eskaliert? wie? wohin?). In Scrum kannst du das zum Beispiel über die Scrum Master und ein Impediment Backlog umsetzen. Das größere Problem in Assessments ist manchmal, dass man keine Fälle nachweisen kann, in denen der Eskalationspfad benutzt wurde, weil alles auf Arbeitsebene geklärt wurde. Bei agilem Arbeiten, sollte aber schon ein gewisser Durchsatz bei der Beseitigung von Impediments zusammen mit dem Management sichtbar sein. Unabhängig von Automotive SPICE sollte es ja in deinem Interesse liegen, dass der Kanal für Eskalationen/Impediments mal „ausprobiert“ wurde und zuverlässig funktioniert.
Hinweise zu Level 2
Die Planung und Nachverfolgung von Aktivitäten zur Qualitätssicherung wird nicht durch die agilen Backlogs abgedeckt. Ebenso wie in MAN.3 musst du hier ein separates Backlog aufsetzen („Qualitätsteam“) oder die Items entsprechend markieren, damit sie aus den operativen Backlogs herausgefiltert werden können.