Beim RE kommt man nie umhin, auch über Anfragen für weitere Anforderungen zu sprechen. Hierbei geht es jedoch nicht um späte Anfragen für Änderungen nach einem Design-Freeze oder nach Serienreife, welche über ein Change-Control Board laufen, sondern um Anfragen, die bestenfalls bereits in einer frühen Entwicklungsphase berücksichtigt werden sollten. Warum ich heute über Kanban schreibe ist, dass diese Anfragen strukturiert, visualisiert, nachvollziehbar und transparent im Team dargestellt werden müssen.  Hierfür eignet sich beispielsweise Kanban. Wie stellt man also sicher, dass Entwicklungsprojekte Anfragen von Kunden umfassend dokumentieren und umsetzen?

Dazu gehören:

1. Anfragen beschreiben
2. Hintergründe darstellen
3. Technische Machbarkeit aufweisen
4. Verantwortliche informieren
5. Entscheidungen festhalten

Für die Umsetzung von Kanban gibt es verschiedene Möglichkeiten

Für Kanban können Tools wie z.B. Excel, im Einsatz befindliche RE-Programme oder einfach nur Postits verwendet werden. Excel und RE-Programme müssen aber für diesen Zweck vorbereitet, Vorgehen abgestimmt und gelebt werden. In der Praxis ist Kanban z.B. mit Hilfe von Postits oft schneller umzusetzen.

Nachdem bei meinen Kunden bereits Excel und DOORS im Einsatz waren, wurde entschieden, diese Tools auch für Kanban zu verwenden. Und so hatte ich bei meinem letzten Kunden die Möglichkeit Kanban zu erleben und zwar auf Projektmanagementebene zur  Projektsteuerung. Hierzu wurden Kundenanfragen, Herausforderungen und unterschiedliche Themen auf Projektleiter-Ebene und den verschiedenen Vertretern aus den Fachbereichen notiert, den entsprechenden Bereichen zugewiesen und wöchentlich verfolgt: z.B. Themen aus der Fertigung, Entwicklung oder Materialbeschaffung. Im Hinblick auf die unterschiedliche Standortverteilung hat sich die elektronische Abbildung des Kanban-Boards bewährt und ich hatte die Möglichkeit mich für die Nachverfolgung der Änderungen direkt an das elektronische System anzuhängen.

Jedoch zunächst einmal kurz zurück zu Kanban. Kanban kommt aus dem japanischen und heißt „Karte“ oder „Beleg“. Taichi Ohno hat Kanban für Toyota 1947 entwickelt. Ziel war es die schlechte Produktivität des Unternehmens nach den Nachkriegsjahren zu verbessern.

Gerade zu Beginn bei Entwicklungsprojekten sind viele Anforderungen noch nicht klar, und innerhalb der zulässigen Phase darf und muss viel diskutiert werden. Wir haben alle Kundenanfragen auf elektronischen Karten aufgelistet und nach den oben beschriebenen Punkten möglichst umfassend definiert.

Das Kanban-Board ist in 3 Spalten aufgeteilt:

In Evaluation: die Anfrage wird vom Team auf Auswirkungen auf bestehende Anforderungen geprüft. Solange keine Entscheidung über die technische Machbarkeit möglich ist, verbleibt die Karte in dieser Spalte.
In Progress: eine technische Machbarkeit dieser Anfrage wurde vom Team gezeigt. D.h. die Anfrage wird bestätigt und kann als Anforderung spezifiziert bzw. modelliert werden. Die Betrachtung von Kosten wurde übrigens an anderer Stelle geprüft. Die entsprechende Änderung der Anforderung erfolgt durch eine entsprechende Referenz auf diese Anfrage (z.B. URL).
Done: die Anforderung wurde nicht nur in die Spezifikation übernommen, sondern auch von den Beteiligten in einem Review geprüft und freigegeben. Einfachheitshalber wären auch abgelehnte Anfragen mit einem entsprechenden Vermerk hier abgelegt worden.

Innerhalb des gesamten Teams hatte jeder die Möglichkeit sich über den Stand aktueller Anfragen zu informieren. Auch über kontinuierliche Termine konnte das Team selbst Feedback zu einzelnen Punkten geben. Änderungen an Anforderungen konnten einfach nachvollzogen werden.

Durch das Pull-Prinzip, bei dem die Karten nachgezogenen werden, kam die wesentliche Eigenschaft von Kanban zur Geltung: Visualisierung und Optimierung des Informationsflusses.

Auf die Verwendung der sogenannten WiPs (Work in Progress) wurde bei diesem Einsatz von Kanban verzichtet.

Kanban bei entwicklungsbegleitenden Messungen

Eine andere Einsatzmöglichkeit von Kanban ist, aktuell entwicklungsbegleitende Messungen in Klimaschränken für das Team transparent darzustellen. Hierfür kann ein Kanban-Board in der Nähe von Klimaschränken abgebildet werden. Die geplanten Messungen werden in der “todo” Spalte aufgelistet. Hierfür werden die Tests in einzelnen Karten abgebildet und vom Team nach Wichtigkeit priorisiert und entsprechenden Klimaschränken zugewiesen. Wird eine Messung durchgeführt, wandert die Karte in die Spalte „in progress“. Abgeschlossene Tests kommen in die Spalte „done“. Mit dem Pull-Prinzip erhält das Team einen visulisierten Überblick über anstehende, laufende und abgeschlossene, entwicklungsbegleitende Messungen in Klimaschränken.

Lesen Sie in diesem Blog-Beitrag über weitere Szenerien und Beispiele zu Kanban. Wenn Sie noch mehr über Kanban und agiles RE wissen wollen, nehmen Sie an unserer Schulung CARS teil.