Kanban for better life and teams

Es gibt Szenarien, denen ich immer wieder begegne, wenn Teams zusammen in der Entwicklung arbeiten:

• Das Team wünscht sich einen besseren Informationsaustausch.
• Das Team wünscht sich eine bessere Teamarbeit.
• Das Team wünscht sich mehr Transparenz der Aufgaben einzelner Teammitglieder.
• Das Team wünscht sich einen Überblick über anstehende Aufgaben und Ressourcen um eine bessere Abarbeitung zu gewährleisten.

Eine Möglichkeit diesen Wünschen gerecht zu werden, ist die Verwendung von Kanban. Im Folgenden will ich Ihnen kurz das ursprüngliche Kanban von der Produktion über die Verwendung in der Softwareentwicklung vorstellen und Ihnen zeigen, dass Kanban auch für den Einsatz in der Hardwareentwicklung geeignet ist. Des Weiteren werde ich Ihnen das Status-Meeting als bewährte Praktik darstellen:

Ursprüngliche Verwendung von Kanban

Kanban hat den Ursprung in der Produktion. Es wird verwendet um Lagerbestände zu minimieren und eine Just-in-Time Produktion sicher zu stellen. Das Prinzip funktioniert nach dem Pull-Prinzip und hat als wichtigen Bestandteil eine „Signalkarte“. Es gibt viel Literatur, in der das Vorgehen sehr ausführlich beschrieben wird. Daher werde ich im Folgenden nur anhand eines vereinfachten Beispiels erklären, wie dieses Vorgehen funktioniert:

Beispiel:
Stellen Sie sich vor, Sie bauen zu dritt Spielzeugautos zusammen.
Monteur 1 baut den Aufbau, Monteur 2 den Unterboden und Monteur 3 baut Aufbau und Unterboden zusammen.
Monteur 3 hat an seinem Arbeitsplatz 4 Behälter mit Karten: 2 Behälter sind mit jeweils einer Karte „Aufbau“ und 2 Behälter jeweils mit einer Karte „Unterboden“ versehen.
Ist nun ein Behälter „Aufbau“ leer, so baut Monteur 1 einen Aufbau. Sobald der Behälter „Unterboden“ leer ist, baut Monteur 2 den Unterboden.
Ziel ist dabei, dass nie mehr Aufbau oder Unterboden produziert und bei Monteur 3 gelagert werden als Monteur 3 überhaupt benötigt, damit wird also die Vorratshaltung minimiert.

Kanban in der Softwareentwicklung

In der Softwareentwicklung hat sich Kanban als Vorgehen etabliert. Die Methode weicht jedoch vom Vorgehen in der Produktion ab. Als Basis gibt es das Kanban-Board. Dieses wird physisch an einem Ort aufgestellt, der für alle Teammitglieder zugänglich ist. Auf diesem Board werden die Aufgaben, Tasks, aufgehängt. Diese Tasks können zum Beispiel auf Post-Its geschrieben und noch mit zusätzlichen Informationen, wie Endtermin, versehen werden. Diese Tasks durchlaufen verschiedene Arbeitsschritte zum Beispiel To-Do, In-Progress, Done.

Dabei wird die Anzahl an Aufgaben, die parallel abgearbeitet werden, limitiert: der sogenannte „Work in Progress“ (WiP). Ist zum Beispiel der WiP auf 2 Stück reduziert und sind bereits 2 In-Progress, darf erst mit einer neuen Aufgabe begonnen werden, wenn mindestens eine Aufgabe abgeschlossen wurde. Dadurch wird eine Transparenz erzeugt um den kontinuierlichen Durchsatz von Aufgaben(-paketen) zu erhöhen, Flaschenhälse, auch bekannt als „Bottlenecks“, zu entdecken und diesen entgegenzuwirken. Diese Vorgehensweise ist aber durchaus für die Hardwareentwicklung geeignet. Im Folgenden werde ich näher auf das Status-Meeting als bewährte Praktik eingehen und die positiven Effekte darstellen.

Status-Meeting als bewährte Praktik

Um nun dieses Board bzw. die Tasks zu verwalten, können verschiedene organisatorische Meetings vereinbart werden, zum Beispiel ein Status-Meeting. Das Status-Meeting kann täglich stattfinden um die tägliche Planung, die letzten Ergebnisse bzw. die störenden Faktoren durchzusprechen. Dieses Status-Meeting wird möglichst kurz gehalten und sollte maximal ca. 15 min dauern.

Jedes Teammitglied berichtet dem Team im Meeting, welche Tasks es seit dem letzten Status-Meeting erledigen konnte, welche Tasks es nicht erledigen konnte und warum, und welche Aufgaben es bis zum nächsten Status-Meeting vor hat zu erledigen. Den Einzelnen wird dadurch transparent gemacht, welche Ergebnisse und welche Hinderungsgründe es gibt und welche Aufgaben gerade anstehen. Auch Schnittstellen zwischen den Tasks von unterschiedlichen Teammitgliedern werden so ersichtlich. Durch die Transparenz verbessert sich daher der Informationsaustausch und die Teamarbeit.

Stapeln sich Tasks, die nicht abgearbeitet werden können, bei einer einzelnen Person, so muss den Hinderungsgründen nachgegangen werden. Es kann zum Beispiel sein, dass ein Flaschenhals entdeckt wurde oder dass die Tasks von anderen Problemen abhängig sind, wie Konflikten zur Nachbarabteilungen, die von einer anderen Instanz gelöst werden müssen. Oder es ist nur eine kurzfristige Situation, bei der andere Teammitglieder aushelfen und unterstützen können. Im Team wird entschieden, wer Tasks übernimmt und welche Tasks dafür herunterpriorisiert werden. Zusammen im Team werden somit die Ursachen ermittelt, Maßnahmen generiert und deren Umsetzung vorangetrieben, was in einem separaten Meeting, ähnlich wie eine Retrospektive im Scrum, geschieht.

Jedes Teammitglied arbeitet dadurch selbstständig an seinen Aufgaben, doch das Team arbeitet am großen Ganzen zusammen und entscheidet gemeinsam. Es wird intensiv kommuniziert, es wird zusammen an Problemen gearbeitet und es wird an einem Strang gezogen.

Fazit

Kanban ist daher meiner Meinung nach eine gute Vorgehensweise in der Entwicklung, auch von Hardware, um ein effizientes und effektives Arbeiten im Team zu erreichen und den oben genannten Wünschen entgegenzukommen.

Dieser Blog zeigt nur einen kleinen Ausschnitt zu diesem Thema. Es gibt noch viel mehr positive Effekte, die durch ein gutes Kanban-Vorgehen entstehen. Wenn Ihr Interesse geweckt wurde, dann kommen Sie gerne auf uns zu. Mit unseren Erfahrungen unterstützen wir Sie bei der Einführung und Umsetzung von Kanban in Ihrem Unternehmen.

Eva-Maria Meindl

Kontaktieren Sie Eva-Maria Meindl

Eva-Maria Meindl ist als Consultant im Bereich Requirements Engineering tätig. Ihre Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge wie zum Beispiel DOORS von IBM. Zu ihren Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, sowie die Erstellung von objektorientierten Modellen.