Kennen Sie das? Die Planung ist abgeschlossen. Alles scheint durchdacht. Die Arbeiten im Projekt schreiten voran. Auf einmal häufen sich die Katastrophenmeldungen: “Wir können nicht liefern, weil uns wichtige Spezifikationsdokumente fehlen”, “wir können nicht spezifizieren, weil die Fachexperten nicht zur Verfügung stehen”, “wir haben zehn Entwickler, die nächste Woche nichts zu tun haben”… Oft erfährt die Projektleitung viel zu spät, dass etwas schief läuft. Es bleibt keine Zeit, um angemessen zu reagieren. Die getroffenen Maßnahmen können nur das Schlimmste verhindern, jedoch keine wirkliche Erleichterung bringen.
Wäre es in einer solchen Situation nicht erstrebenswert, dass
- rechtzeitig erkennbar ist, wo bald Engpässe entstehen werden?
- jeder im Projekt seine noch offenen Aufgaben selbständig steuert?
- jeder seine Aktivitäten darauf einstellt, wer wann mit seinen Ergebnissen weiterarbeitet?
- jeder ausreichend Zeit für Rückfragen zu seinen Ergebnissen einplant?
- jeder seine Änderungen aktiv an die richtigen Empfänger kommuniziert?
Wäre es nicht erstrebenswert, wenn diese Koordinationsaufgabe nicht alleine bei der Projektleitung hängen bliebe?
Sie haben vielleicht auch die Erfahrung gemacht, dass diese Art der Transparenz nicht über eine noch bessere, noch genauere Planung zu erreichen ist. In Situationen, in denen Transparenz gefordert ist, halte ich es für vielversprechender, nach Lean Prinzipien der Softwareentwicklung zu steuern:
- Vermeide unnützen Aufwand. Unnützer Aufwand entsteht z.B. dann, wenn etwas produziert wird, das nicht sofort weiterverwendet wird, wenn die Qualität zugunsten der Termintreue abnimmt oder wenn Prozesse anfangen, bürokratisch zu sein;
- Liefere so schnell wie möglich. Hierbei denke ich an Endergebnisse, keine Zwischenergebnisse. Sie sollten alles versuchen, Wartezeiten zwischen einzelnen Arbeitsschritten zu vermeiden. Das bedeutet unter anderem auch, die Anzahl der parallelen Tätigkeiten pro Mitarbeiter zu reduzieren (maximal 1-2 Aufgaben).
- Befähige das Team. Jeder Mitarbeiter sollte Zugriff auf alle erforderlichen Informationen haben, um möglichst autonom entscheiden zu können. Die traditionelle Entscheidungshierarchie bremst einen konstanten Arbeitsfluss eher aus. Aufwandsschätzungen sollten immer vom Team kommen. Die Mitarbeiter wissen am Besten, was zu tun ist.
Zwei wirklich gute Bücher dazu haben Mary und Tom Poppendieck geschrieben:
Mary Poppendieck, Tom Poppendieck; “Lean Software Development”, Addison-Wesley Longman, 2003
In dem Buch werden Lean-Management Prinzipien auf die Softwareentwicklung übertragen. Basis für dieses Buch ist unter anderem Taichi Ohnos “Toyota Production System”.
Mary Poppendieck, Tom Poppendieck; “Implementing Lean Software Development”, Addison-Wesley Longman, 2006
In diesem Buch werden die Konzepte aus dem ersten Band noch einmal in verdichteter Form präsentiert. Auch wenn sich einiges wiederholt, ist das Buch lesenswert.
Die beiden haben auch eine Website, auf der Sie weitere Informationen finden können.
Dann gibt es da noch von Corey Ladas ein Buch zum Thema:
Corey Ladas; “Scrumban – Essays on Kanban Systems for Lean Software Development”; Bertrams Print on Demand, 2009
In seinem Buch beschreibt Corey Ladas, wie man mit Kanban-Systemen Prozesse transparent macht und selbstorganisiert steuern kann. Ein wesentlicher Bestandteil ist in seinem Buch die kontinuierliche Verbesserungen anhand von aktuellen Durchlaufzeiten einzelner Arbeitspakete.
Eine anschauliche Einführung in die Grundsätze findet sich auf seinem Blog: Mechanics of pull development workflow.
Außerdem empfehlenswert ist noch der AvailAgility Blog.
Dein Kommentar