projekt MA N A G E M E N T aktuell 4/ 2014 l 43 P eter hat ein Problem. Peter weiß nicht, wie sein Projekt ausgehen wird. Peter ist Projektmanager und hat ein großes Projekt übertragen bekommen. Dieses Projekt hat viele Abhängigkeiten, jede Menge Anforderungen und natürlich auch noch Mitarbeiter, die das Projekt umsetzen sollen. Peter hat schon ein paar Iterationen über den Projektplan hinter sich, es kostet ihn aber jedes Mal einige Tage, bis der Plan wieder aktuell ist. Natürlich möchte sein Management wissen, ob er die Deadline halten kann. Mit den technischen Risiken, die auftreten, und den bereits erwähnten Abhängigkeiten weiß er das allerdings leider selbst nicht. Fast weiß er schon, dass er den Umfang reduzieren muss, um den Termin zu halten. Er möchte nicht dastehen wie ein Schwarzmaler, aber er kann auch nicht genau belegen, wie viel Umfang er streichen muss. Der Kunde wäre sicher nicht amüsiert. Durch Zufall trifft Peter auf dem Weg nach Hause in der U-Bahn seinen Kommilitonen Justin. Justin erzählt ihm von seinen Erfolgen mit Kanban. Zu Hause angekommen liest Peter in der Broschüre, die Justin ihm mitgegeben hat. Kanban besteht im Kern aus vier Prinzipien und sechs Praktiken. Die Praktiken heißen: 1. Visualisiere die Arbeit 2. Limitiere die Menge paralleler Arbeit 3. Messe und manage den Fluss 4. Mache Prozessregeln explizit 5. Entwickle Feedback-Zyklen 6. Erziele Verbesserung kooperativ und Entwicklung experimentell (mithilfe von Modellen und wissenschaftlichem Vorgehen) Das ist für Peter alles erst einmal sehr abstrakt. Er beschließt, Kanban einfach mal auszuprobieren. Denn Justin hat ihm eine höhere Vorhersagbarkeit, besseres Risikomanagement und zufriedenere Stakeholder versprochen. Und genau das benötigt Peter jetzt. Dinge sichtbar machen: Visualisierung Am einfachsten findet Peter die Visualisierung und er beginnt mit Justins erstem Ratschlag: Identifiziere die Arten von Arbeit, die bearbeitet werden. Gemeinsam mit seinem Team geht er die verschiedenen Arbeitspakete durch: Designs, Architekturaufgaben, Implementierungen, Dokumentationen und Tests. Hinzu kommen kleinere Bugs, die das Team auch noch beheben muss. Die Arbeitsschritte sind alle sehr unterschiedlich. Deswegen verwenden sie „To do“, „Doing“, „Done“ als Spaltenüberschriften für das Board. Dieses modellieren sie erst einmal etwas hemdsärmelig auf einem Whiteboard mit Karteikarten. Peter möchte so wenig Geld und Zeit in elektronische Tools stecken wie möglich. Wer weiß, ob ihm das Board wirklich hilft? Peter hat kurz vorher noch gelesen, dass es ein paar Metriken gibt, die man erheben sollte: Durchlaufzeit und Durchsatz. Diese beiden Zahlen soll das Team für die Arbeitspakete ermitteln. Er möchte auch gerne noch die Auslastung der einzelnen Mitarbeiter verfolgen, damit keine Arbeitszeit verschwendet wird. Als Letztes möchte er einen Bericht über den Fertigstellungsgrad der einzelnen zu implementierenden Anforderungen. Hierfür mes- Florian Eisenberg Projektgeschichten und Fallstudien Projektmanagement mit der Kanban-Methode unterstützen Kanban unterstützt mit Metriken und Visualisierungen das tägliche Projektmanagement. Doch die Kanban-Praktiken können noch mehr. „Kanban“: David Anderson schrieb 2010 das Buch „Kanban: Successful Evolutionary Change for Your Technology Business“ und definierte damit die Kanban-Methode. Diese Methode leitete er aus Modellen wie der Warteschlangentheorie, Risikomanagementmethoden und schlussendlich dem Toyota-Produktionssystem ab. Bevor er sie publizierte, erprobte er sie erfolgreich bei Microsoft, Sprint und Motorola. Mittlerweile hat er sie von einer reinen Change-Methode zu einem Kosmos von modernen Managementmethoden weiterentwickelt. Viele Projekte können von Kanban profitieren, indem sie die sechs Praktiken einsetzen. Visualisierung und Metriken helfen bei einer Fortschrittskontrolle und der Projektplanung. Die Praktiken erzeugen eine Transparenz, die Probleme wie Überlastung, Abhängigkeiten oder spezialisierte Ressourcen offensichtlich werden lässt. Besonders Work-in-Progress-Limits erzeugen den Zwang, diese Probleme nachhaltig zu lösen. Dem Projektleiter winken für die Lösung Vorhersagbarkeit, schnelle Durchlaufzeiten und eine konstante Implementierungsqualität. Dabei ist Kanban nicht nur in Softwareentwicklungsprojekten, sondern auch in Betrieb, Sales, Marketing und ganz besonders im Produktmanagement anwendbar. +++ Für eilige Leser +++ Für eilige Leser +++ Für eilige Leser +++ PM_4-2014_1-80: Inhalt 22.08.2014 10: 46 Uhr Seite 43 sen sie die fertiggestellten Arbeitspakete pro Feature und machen noch eine Restaufwandsschätzung. Elektronisch oder lieber an der Wand? In der Visualisierung kommt es darauf an, möglichst viel so zu visualisieren, dass es einen Nutzen generiert. Hier können verschiedene Dringlichkeiten, Arten von Arbeit, Arbeitsschritte und auch Mitarbeiterzuordnung dargestellt werden. Natürlich muss hier immer im Blick gehalten werden, wie viel Nutzen eine Visualisierung im Vergleich zu ihren Kosten bringt. Die Frage, ob elektronische Werkzeuge dem einfachen „Papier an der Wand“ vorgezogen werden sollten, wird immer wieder heiß und emotional diskutiert. Die Erfahrung zeigt allerdings, dass die Verwendung physischer Boards mehrere Vorteile hat: 1. Sichtbarkeit für alle Beteiligten - Das schließt auch den Vorgesetzen ein, den man frühzeitig über entstehende Probleme informieren möchte. 2. Veränderbarkeit - Gerade bei neuen Kanban-Implementierungen ändert sich die Strukturierung des Kanban-Boards anfänglich sehr stark. Häufig klären sich Arbeitsabläufe erst, wenn bewusst mit ihnen gearbeitet wird. Elektronische Tools sind beim ersten Aufsetzen häufig sehr flexibel, bremsen dann aber sehr stark, wenn etwas am System verändert werden soll. 3. Zentraler Interaktionspunkt - Gespräche über den Status des Projektes und was zu tun ist, passieren häufig vor dem Board, weil hier viel notwendige Information zentral bereitsteht. Elektronische Werkzeuge neigen dazu, Informationen sehr bequem dezentral für jeden zugänglich zu machen. Damit steigt die Hürde aber, miteinander über die aktuelle Situation zu sprechen. Trotz dieser Vorteile kann es für viele Teams und Projekte sinnvoll sein, zu einem Zeitpunkt auf ein elektronisches Werkzeug umzustellen. Diese Werkzeuge erheben die typischen Metriken automatisch und erfordern im Allgemeinen nur noch ein Filtern auf relevante Daten. Ihre Vorteile können die Werkzeuge besonders dann ausspielen, wenn verteilte Teams Kanban einsetzen wollen. Es existieren zwar Techniken, um physikalische Boards an verschiedenen Standorten zu synchronisieren, die meisten werden bei mehr als zwei Teams aber zu aufwendig in der Koordination. Echten Fortschritt feststellen Nach ein paar Tagen reflektiert Peter mit seinem Kollegen über das Kanban-Board. Ihm hilft das Board, stellt er fest. Er kann sehr genau erkennen, welcher Mitarbeiter an welchen Paketen arbeitet und was noch offen ist. Allerdings ist es auch ziemlich unübersichtlich. Es sind sehr viele Zeilen auf dem Board und jede Menge Zettel. Peter kann jedoch erkennen, dass die Architektur für alle Features abgeschlossen ist. Alle Arbeitspakete der Architektur sind bereits in der „Done“-Spalte. Das Design ist noch nicht abgeschlossen. Dummerweise hat er aber die Entwickler schon ab nächster Woche eingeplant. Er muss also überlegen, wie er jetzt die fertigen Design-Arbeitspakete mit den Implementierungs-Zetteln verknüpft. Abhängigkeiten! Wie soll man bitte die auf einem Board verknüpfen? Er liest im Internet etwas über Wollfäden. Das kann ja wohl nicht deren Ernst sein. Denn jeder Design-Zettel hat einen Implementierungs- Nachfolger. Und jeder Implementierungs-Zettel hat einen Integrations- und Test-Nachfolger. Da hat er ja ein ganzes Wollknäul an der Wand hängen. Im Gespräch mit seinem Team finden sie heraus, dass ein ganz typisches Muster existiert: Eine gesamte Anforderung läuft immer durch Architektur, Design, Implementierung, Integration und Test. Sie haben die Tickets also falsch geschnitten. Sie modellieren ihr Board um und schreiben neue Zettel mit einzelnen Anforderungen. Die Spalten bilden dann die einzelnen Schritte im Arbeitsfluss ab. Jetzt sieht Peter, dass einige Features hinter der Architektur warten und einige vor der Entwicklung. Es ist aber noch nichts fertig. Kundenwert statt Aufgaben Kanban orientiert sich generell an „werthaltigen“ Einheiten - also Dingen, an denen echter Fortschritt festge- 22 l projekt MA N A G E M E N T aktuell 4/ 2014 44 WISSEN Abb. 1: Echter Fortschritt ist auf diesem Board schwer abzuschätzen Abb. 2: Das Kanban-Board nach der Umgestaltung PM_4-2014_1-80: Inhalt 22.08.2014 10: 46 Uhr Seite 44 stellt werden kann, bzw. die Endkunden oder Stakeholdern einen wirklichen Wert bringen. Mit diesem Wert kann dann eine Priorisierung nach verschiedenen Kriterien stattfinden. Peter identifiziert für seine Priorisierung zwei Dinge: Kundennutzen und technische Risiken. Diese beiden Kriterien muss er mit unterschiedlichen Gruppen absprechen. Das Resultat führt er dann aber zu einer gemeinsamen Priorisierung zusammen. Anforderungen, die technische Risiken bergen, werden von ihm bevorzugt behandelt. Ist die erdachte Architektur so umsetzbar? Passt die Business-Logik zur Datenbank? Ist das Framework für die Benutzerschnittstelle performant genug? Legen wir den Fokus auf werthaltige Einheiten und betrachten nur diese auf dem Kanban-Board, stellt sich meist die Frage, wie mit den sonstigen Aktivitäten umgegangen wird. Hier zwingt uns Kanban in eine interessante Diskussion: Welche Dinge sind oder unterstützen wertschöpfende Arbeit? Welche tun es nicht? Warum führen wir diese Aktivitäten durch? Viele Teams versuchen aus Transparenzgründen, auch die nicht primär wertschöpfenden Aktivitäten auf dem Board darzustellen. Das führt meist aber nur dazu, dass sie als gegeben oder notwendig akzeptiert werden. Rückläufer schmälern den Durchsatz Mittlerweile ermittelt Peter den Durchsatz und die Durchlaufzeit von ganzen Anforderungen. Er stellt irgendwann fest, dass der Durchsatz echter Features immer weiter sinkt. Die Menge implementierter Funktionalität pro Woche wird also weniger. Dabei wollte er doch schneller werden! Er sieht sich die Situation auf dem Board an und vergräbt sich in den Metriken und Daten. Als er eine Stunde später wieder auftaucht, hat er das Problem gefunden: Es gibt zu viele Rückläufer! Das ist auch auf dem Board sichtbar, denn Bugs haben einen kleinen aufgedruckten Käfer auf dem Zettel. Peter spricht mit seinen Testern über die Käfer. Sie bestätigen seinen Verdacht: Die Tickets sind Qualitätsprobleme in der neu erstellten Funktionalität. Um die notwendige Geschwindigkeit zu erreichen, hat das Entwicklungsteam Qualität geopfert. Ein wenig Recherche bringt Peter auf die Idee, die Rückläufer nicht als neue Tickets zu betrachten, sondern als „nicht fertiggestellte Funktionalität“. Die Tickets laufen also nach der Entwicklung in den Test und bekommen dort eine Markierung, falls sie nicht erfolgreich getestet wurden. Die Tickets verharren dann in der Testspalte des Boards. Zusätzlich führt Peter eine Beschränkung ein: Bereits bestehende Funktionalität wird erst einmal fertig gemacht. Die Tester dürfen also keine neuen Aufgaben anfangen, wenn nicht bei allem anderen die Qualität gesichert ist. Doch schon bald haben die Tester nichts mehr zu tun - ihnen geht die Arbeit aus, weil kaum etwas fertig getestet werden kann. Natürlich möchte Peter nicht, dass Mitarbeiter untätig herumsitzen, und er erhöht die Menge an Arbeit, die sich in der Testspalte befinden darf. Mehr und mehr nicht fertiggestellte Funktionalität häuft sich im Test an. Irgendwann schlagen die Tester Alarm. Denn wenn das so weitergeht, werden sie Überstunden und Wochenendarbeit zum Projektende einschieben müssen. Work-in-Progress limitieren Kanban verwendet sogenannte Work-in-Progress-Limits, um Feedback über Probleme in späteren Phasen eines Prozesses schnell zu den früheren Phasen zu propagieren. Die Menge an paralleler Arbeit wird für einzelne Arbeitsschritte limitiert. In der Praxis treten neben Spaltenlimits auch Zeilenlimits, Systemlimits und Personenlimits auf. Die verschiedenen Limits haben unterschiedliche Auswirkungen. Beim Design des Systems müssen also die Bedürfnisse und Anforderungen speziell berücksichtigt werden. So helfen Personenlimits - jeder Mitarbeiter darf also z. B. nur an drei Dingen gleichzeitig arbeiten - Überlastungen zu erkennen und zu vermeiden. Aus Sicht des Arbeitsflusses können Personenlimits aber hinderlich sein. Verwenden wir Work-in-progress-Limits, tritt der sogenannte Slack auf. Das ist Zeit, in der beispielsweise die Tester nicht in ihrer Spezialisierung arbeiten können. Dieser Slack kann verwendet werden, um Prozessverbesserungen voranzutreiben oder um andere Kollegen zu unterstützen. Erst das Auftreten von Slack ermöglicht es vielen Firmen, wirkliche Verbesserungen in der Zusammenarbeit voranzutreiben. Projekt Ernte Fahren Sie jetzt Ihre Ernte ein! Schillstraße 150 · 86169 Augsburg Call: +49 (0) 821 - 815-6548 Fax: +49 (0) 821 - 815-1993 Mail: info@dynamis-web.com Web: www.dynamis-web.com Termine: Level C/ B GPM/ IPMA in Augsburg Start am 27.09.2014 Prüfung am 06.12.2014 Level D GPM/ IPMA in Leipzig Start am 06.11.2014 Prüfung am 14.03.2015 Level C/ B in Augsburg Level D in Leipzig Bild: fotolia.de A l l e K u r s e a u f u n s e r e r W e b s i t e ! Mark Reuter Personalmanagement & Projektmanagement GmbH Anzeige Abb. 3: Tickets mit Fehlern werden markiert PM_4-2014_1-80: Inhalt 22.08.2014 10: 46 Uhr Seite 45