Scrum oder Kanban in der embedded Entwicklung? Geht das überhaupt? Hardwareentwicklung, funktionale Sicherheit, Automotive SPICE, … wie kann in einem solchen Umfeld agil entwickelt werden? Im folgenden findet Ihr eine der vielen möglichen Antworten.
Kanban
Ich möchte hier nicht auf die Grundprinzipien der Engpasstheorie und des Software-Kanban eingehen, sondern auf die Umsetzung in einer agilen Systementwicklung, d.h. mit Hardwareanteilen und unter bestimmten Constraints wie funktionaler Sicherheit oder SPICE.
Ist Kanban agil? nein. Kanban ist ein Werkzeug, das Bestandteil eines agilen Ansatzes werden kann. Kanban und die Engpasstheorie bieten eine Fluss-orientierte Prozessaussteuerung mit WIP-Limitierung. Die WIP-Limitierung ist aber zunächst mal das einzig agile an Kanban. Agile Kernaspekte wie die Einbindung des Kunden, häufige Auslieferungen, regelmäßige Feedbackrunden, Team-Empowerment müssen im entsprechenden Kontext um Kanban herum abgebildet werden. Dann ist Kanban auch agil. So. Das musste mal gesagt werden ;)
Die sanfte Agilität
Gerade in die Compliance Themen im embedded Bereich haben Entwicklungsorganisationen viel Energie investiert. Ein revolutionärer Ansatz à la Scrum würde das bisher Erreichte gefährden. Der Blick des Embedded-Agilisten fällt daher relativ schnell auf Kanban, lässt es doch bestehende Rollen und Prozesse (zunächst einmal) intakt. In der Tat, Kanban passt besser auf arbeitsteilige Prozesse wie sie in der embedded Entwicklung existieren, als andere agile Methoden wie z.B. Scrum.
Kanban verwendet den bestehenden Prozess und schafft durch die WIP-Limitierung zunächst einmal die Basis für Veränderungen: Transparenz und Freiräume. Doch genug geschwärmt, legen wir los.
Agile Hardwareentwicklung
Agile Hardwarentwicklung? Geht so etwas überhaupt? Die Antwort ist relativ einfach: nein. Hardwareentwicklung ist, das liegt leider einmal in der Natur der Sache, immer an einen recht wasserfall-ähnlichen Prozess gebunden: Schaltplan entwerfen, Simulationen durchführen, Platinen-Layout erstellen, Platinen produzieren lassen, Muster aufbauen, testen.
Die Frage muss anders formuliert werden: “Wie binde ich Hardwareentwicklung in eine agile Umgebung ein?” Der Schlüssel dazu ist der Fluss der Anforderungen. Bei allen agilen Skalierungsthemen landet man bei der Frage wie und wohin die Requirements fliessen, agil betrachtet also wie verschiedene Backlogs miteinander synchronisiert werden können.
Requirement-Flow
Zunächst muss festgelegt werden wie die Requirements auf verschiedene Disziplinen verteilt werden. Was zunächst noch als Kundenanforderungen oder Systemanforderungen zusammen in “großen Töpfen” geführt wird, muss ab der Partitionierung in Hardware und Software getrennte Wege gehen. So weit ist das noch nichts anderes als die Verbindung von mehreren Backlogs wie man sie aus reinen Software-Umgebungen kennt. Hier kommt jedoch die oben erwähnte Besonderheit der Hardware ins Spiel: In der Hardware kann kein Fluss von einzelnen Anforderungen durch die Entwicklung aufgebaut werden. Was soll nun mit den Software-Requirements geschehen, die auf einen entsprechenden Hardware-Gegenpart angewiesen sind? Diese können ebenfalls nicht in den Fluss gebracht werden. Eine Möglichkeit ist es, für die Software-Anteile von HW/SW Requirements einen Puffer, oder besser formuliert, einen Parkplatz einzurichten. Ziel ist es, diese Anforderungen erst nach Fertigstellung der Hardware in den Fluss des SW-Kanbansystems einzuspeisen. Dazu muss ein Trigger definiert werden, der die Entleerung des Puffers in das Software-Backlog auslöst. Als Trigger bieten sich Meilensteine innerhalb des Hardware-Wasserfalls an.
Der Requirement-Flow muss den aktuell gelebten Prozessen angepasst werden, im Folgenden zwei Beispiele für einen einfachen Flow im embedded Kontext.
Beide haben gemeinsam, dass eingehende Requirements zunächst aufgeteilt werden in reine SW-Requirements, kombinierte HW/SW-Requirements, und reine HW-Requirements. In beiden Beispielen gibt es einen SW-Entwicklungsprozess und einen HW-Entwicklungsprozess. Ob der SW-Prozess nun mit Kanban, Scrum, V-Modell oder sonstigem umgesetzt wird, ist zunächst einmal egal, wir gehen im folgenden von einem Kanban-Ansatz aus. Jeder Unterprozess erhält seine Anforderungen über sein Backlog.
Die beiden Beispiele unterscheiden sich in der Vorgehensweise bei HW/SW-Integration und beim Test: im ersten Fall (integrierte Teststufe), wird die HW/SW-Integration im Software-Prozess mit abgebildet. Dazu benötigt der SW-Prozess eine lauffähige Hardware. Dies ist bei der Auswahl des Triggers zur “Parkplatz-Leerung” entsprechend abzubilden.
Im zweiten Fall (dedizierte Teststufe), kann der SW-Prozess ohne Hardware ausgeführt werden, die HW/SW-Integration erfolgt in einem separaten Prozess, der die Ergebnisse aus SW-Entwicklung und HW-Entwicklung zusammenführt. Auch für die Aussteuerung des Integrations- und Test-Prozesses bietet sich ein Kanban-Ansatz an. Das Parken von Requirements und das Triggern der Entleerung muss in diesem Fall unter Umständen gar nicht umgesetzt werden, oder zumindest nur in dem Fall, in dem ein Teil der Anforderungen doch von der Hardware abhängt.
Timeboxes
Gemeinsame Timeboxes über die verschiedenen durch Backlogs ausgesteuerten Bereiche erleichtern die Synchronisation der Backlogs. Eine Verschieben von Übergabezeitpunkten würde das ganze Thema zu einer aufwändigen Managementaufgabe machen, die Skalierung des Scopes hingegen kann von den entsprechenden Einheiten untereinander abgestimmt werden. In der embedded Entwicklung bietet es sich an durch die langen Laufzeiten in der Hardwarentwicklung ineinander gestaffelte Timeboxes festzulegen.
Fazit
Wie auch bei der Skalierung von agilen Teams führt auch bei der Vernetzung von agilen und klassischen Teams und Strukturen der Weg zur Lösung über Timeboxes und die Definition der Requirement Flows. Zusätzlich muss eine Lösung gefunden werden, wie Anteile mit langen Laufzeiten, wie z.B. die Hardwareentwicklung in den Flow integriert werden, z.B. mit einem “Puffer-Parkplatz”. Es gibt leider keine Kochrezepte, die Lösung für eine spezifische Organisation muss mit zusammen mit den Beteiligten in dieser Organisation entwicklet werden. Aber auch hier gilt wie bei allen agilen Umsetzungen: Erste Schritte zu versuchen ist wichtiger als eine lange Konzeptionsphase vorzuschalten. Ah, und eines kann ich versprechen: Auch wenn man in der Konzeption alle derzeit bekannten Details berücksichtigt, das Konzept wird in 6 Monaten anders ausssehen als beim Kick-Off :)