Nach meiner Überzeugung ist Kanban bestens geeignet, um die Bedürfnisse der Software Maintenance zu befriedigen. Aber wie komme ich zu diesem Schluss?
In der Software Maintenance geht es zwar wie im Projektgeschäft ebenfalls um Termine, die höhere Priorität hingegen hat die Qualität. Projekte sollen „in time and budget“ fertig werden, Qualität wird einfach vorausgesetzt, obwohl wir hier die Wahl aus einem sehr großen Spektrum haben, in dessen unterem Bereich die Mindestqualität liegt. Die Mindestqualitätsstufe im Projekt heißt „funktioniert“. Über die innere Qualität, vor allem die „Änderbarkeit“ verlieren die nicht-funktionalen Anforderungen in einem Projekt nur selten ein Wort.
In der Maintenance wollen wir ein Stück Software so haben, dass es tut, was es tun soll, wenn wir es aber ändern müssen, dies mit möglichst geringem Aufwand erledigen können. Nun gibt es in Kanban grundsätzlich keine Regel, die besagt, daß man hervorragende Qualität abliefern muss, wenn man die Regel nicht als eine „definition of done“ explizit definiert. Durch das Pull-Prinzip haben die Teammitglieder jedoch nicht den Termindruck, der gute Qualität aktiv verhindert. Ein ehemaliger Kollege sagte einmal: „Ihr könnt uns rauswerfen, aber Ihr könnt uns nicht zwingen schlechte Qualität abzuliefern.“ Ein schöner Satz, aber welcher Entwickler hält sich wirklich daran? Heute lautet sein Motto etwas sanfter: „Der Kunde bekommt, was er bezahlt.“ Die Grundaussage bleibt die gleiche, daß nur Qualität einen nachhaltigen Wert bietet.
Vorausgesetzt wir liefern einzelne kleine Aufgaben in angemessener Geschwindigkeit und in guter Qualität ab, so daß nicht aus jeder erledigten Aufgabe drei Notfälle entstehen, ist gerade dadurch, daß die Tasks relativ klein sind, sichergestellt, daß in regelmäßigen Abständen ein Teammitglied verfügbar ist, das sich die nächste Aufgabe zieht. Durch das WIP-Limit muß das Teammitglied nicht erst noch eine beliebige Anzahl anderer Themen beenden, bevor die „Ressource“ verfügbar ist. Welche Aufgabe dann gezogen wird, ist Sache der Priorisierung. Stellt man das einigermaßen geschickt an, hält man sich also die Möglichkeit offen, jederzeit neu zu priorisieren, kann man auf neue Situationen sehr schnell reagieren. Wichtig ist nur, dass begonnene Arbeiten auch abgeschlossen werden, so dass jeder investierte Aufwand auch in einer Wertsteigerung des Systems resultiert. Durch die WIP-Limits haben wir also die Möglichkeit sehr schnell auf geänderte Anforderungen zu reagieren, ein sehr wichtiger Punkt in der Maintenance, wie in der gesamten Softwareentwicklung.
Durch die Abildung des aktuellen Fortschritts am Board sieht spätestens beim regelmäßigen (meistens Daily) Standup jeder, und damit auch jeder Stakeholder, was gerade in Arbeit ist, was als nächstes kommt, und wie es allgemein vorangeht. Die Wertsteigerung des Systems wird hier gemessen, und nur hier ist auch die Frage erlaubt, warum eine bestimmte Aufgabe länger dauert als erwartet. Dieser Überblick ist ein berechtigtes Interesse eines jeden Stakeholders, von denen es in der Maintenance typischerweise eine ganze Menge gibt. Durch die Darstellung am Board entfällt ein explizites Reporting über den aktuellen Fortschritt, das nur zusätzliche Ressourcen binden würde, die auch sinnvoller eingesetzt werden können, z.B. um den Wert des Systems zu steigern. Wenn dem Berichtsempfänger nicht zuzumuten ist, sich zum Standup ans Board zu bewegen, hat er seinen Job verfehlt. Schließlich hat er hier die Möglichkeit seine Interessen zu vertreten.
Fällt bei der Gelegenheit einem der Teilnehmer auf, daß irgendetwas nicht zu seiner Zufriedenheit läuft, kann er das zur Sprache bringen. Gibt es keine offensichtliche sofortige Lösung, wird das Thema zum Agendapunkt der nächsten Retrospektive. Damit ist sichergestellt, daß uns die Prozesse unterstützen und nicht behindern. Schließlich kann das Team den Prozess jederzeit ändern. Sehr oft habe ich schon gehört, dass definierte Prozesse ja nichts bringen, sondern immer nur im Weg stehen, weil unnötige Dinge vorgesehen sind. Unter der Voraussetzung, dass die Prozesse nicht geändert werden dürfen, stimme ich dieser Aussage sogar zu.
Auf einem der letzten Treffen der Limited WIP Society München hat ein Teilnehmer die provokante Frage gestellt, warum wir in unserem aktuellen Team für die Maintenance nicht gleich Scrum machten? Schließlich führe doch jeder Einsatz von Kanban über kurz oder lang zu Scrum. Im ersten Moment habe ich mich über die Frage geärgert, den wenn jemand Klugscheißer spielt, dann bitte ich. Den Gedanken habe ich jedoch verfolgt, und mir die Antwort nach und nach zurechtgelegt:
- Kanban ist ein System für „Evolutionäres Change Management“, so steht es als Untertitel auf der deutschen Übersetzung des Buchs von David Anderson. Wenn uns die Prozessänderungen im Rahmen von Kanban zu Scrum führen, dann ist es gut, das Ergebnis ist aber nicht sicher.
- Die oben aufgezählten Vorteile von Kanban treffen auf alle agilen Entwicklungsmethoden zu, wobei diese Vorteile nur indirekt durch die Kanban-Prinzipien erreicht werden
- Im Schluss ergibt sich, daß Kanban eben kein agiles Prozessmodell für die Softwareentwicklung ist, sondern ein agiles Prozessänderungswerkzeug, das wahrscheinlich im Einsatz zu einem agilen Softwareentwicklungsprozess führt.
Wer also einen Maintenance-Prozess hat, mit dem alle Stakeholder zufrieden sind, der benötigt auch kein Kanban-System. Warum sollte man seinen Prozess ändern, wenn man damit wirklich glücklich ist? Und jetzt zeigen Sie mir einen Stakeholder, der gerne eine Gelegenheit verstreichen läßt, ohne sonstige Verluste die effektiven Kosten zu senken.