Die Überlastung von Entwicklungsteams verhindern mit Kanban

Inhaltsverzeichnis

In letzter Zeit ist die neue Methode Software-Kanban in aller Munde. Als ihre Vorteile werden zumeist die evolutionäre Einführungsstrategie und flexibel gehaltene Arbeitsprozesse genannt. Oft vergessen wird hingegen eine weitere Stärke von Kanban – der Schutz vor Überlastung des Teams.

Kanban ist aus unterschiedlichen Gründen und in verschiedenen Konstellationen attraktiv; zum einen ist bei der Einführung keine "Revolution" anzuzetteln, die die gesamte Organisation umkrempelt. Anders als beispielsweise Scrum geht Kanban von einer evolutionären Einführungsstrategie aus, die mit dem Ist-Zustand beginnt, um ihn nach und nach in kleinen Schritten zu verbessern. Zum anderen sind in Kanban weder ein Iterationskonzept vorgesehen noch feste Zeitfenster (Time-Boxes), in denen das Team ungestört arbeitet und eine Neupriorisierung der Anforderungen strikt untersagt ist. Dadurch wird Kanban auch für Bereiche wie Wartung und Systemadministration interessant, in denen Teams oft täglich umpriorisieren müssen, weil beispielsweise Live-Bugs auftreten, deren Beseitigung keinen Tag warten kann.

Daneben weist Kanban eine Stärke auf, die bisher weniger im Mittelpunkt der Diskussion steht: den Schutz des Teams. Oft wird vergessen, dass Kanban genau aus dem Grund ersonnen wurde, Teams zu schützen und eine auf Dauer durchhaltbare Entwicklungsgeschwindigkeit (sustainable pace) zu etablieren. Da die Art und Weise, wie Kanban Teams schützt, etwas anders funktioniert und eventuell etwas weniger intuitiv zu verstehen ist als im Falle von Scrum, sei in dem Artikel näher auf diesen Aspekt eingegangen.

Geht man auf die Arbeitsbelastung in einem typischen Entwicklungsteam ein, wären da zunächst die Teams, die keinem festen Entwicklungsprozess folgen, sondern im Wesentlichen "Entwicklung auf Zuruf" betreiben. Das ist insbesondere in kleinen Organisationen üblich, und zwar auch wenn sie mit der Zeit immer größer geworden sind, aber es versäumt haben, den Prozess hierfür zu definieren. An das Team werden in unregelmäßigen Abständen Anforderungen herangetragen, die mit einer Deadline versehen sind. Die richtet sich entweder nach einer Schätzung, wann das Team mit der Anforderung fertig sein kann, oder, und das ist leider der häufigere Fall, danach, was dem Kunden versprochen wurde. Der häufigste Satz, den solche Teams von ihrem Chef hören, lautet "das hier bräuchten wir übrigens mal ganz schnell bis nächsten Montag." Weil es aber auch noch Bugs gibt, die zu beseitigen sind, weil die Entwickler noch Support leisten müssen und weil sie zudem gelegentlich krank werden oder Urlaub nehmen möchten, führt die Konstellation in der Regel dazu, dass das Entwicklungsteam permanent überlastet ist und nur noch das betreibt, was manche flapsig als "fire-pissing" bezeichnen.

Gewissermaßen das andere Ende der Skala stellen Wasserfall-Projekte mit zu viel Planung dar. Bei ihnen legt der Projektleiter zu Beginn des Projekts Meilensteine fest, zu denen bestimmte Phasen desselben fertig gestellt sein müssen. Die meisten Meilensteine liegen weit in der Zukunft, und spätestens seit Winston Churchill ist bekannt: "Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen." Letztlich hängt der Erfolg von der Güte des Plans ab. Je länger der geplante Zeitraum und je detaillierter der Plan, desto wahrscheinlicher ist es, dass er schon bald nicht mehr stimmt. Ausgetragen wird das dann häufig auf dem Rücken der Teammitglieder, die mit wahren Heldentaten und Unmengen an Überstunden verzweifelt versuchen, Projekte zu retten. Leider gelingt ihnen das allzu oft, mit der Folge, dass für viele Unternehmen der Veränderungsdruck noch nicht hoch genug ist. Die Firmen würdigen das Heldentum meist noch nicht einmal ausreichend, wohl auch, weil es meist durch unterdurchschnittliche Qualität der Software erkauft wird.

Time-Boxing versus Work in Progress und Pull-Prinzip

Agile Methoden streben eine durchhaltbare Entwicklungsgeschwindigkeit an, die es dem Team erlaubt, auch größere Projekte mit langen Laufzeiten ohne Burn-outs zu überstehen. In Scrum liegt der Schlüssel für die nachhaltige Geschwindigkeit in der Kombination der drei Faktoren Time-Boxing, Commitment und Selbstorganisation. Das Team schätzt die Anforderungen selbst, bestimmt, wie viele von ihnen es im nächsten Sprint schafft, und legt sich auf dieses Sprint-Ziel fest. Während des Sprints darf der Product Owner unter keinen Umständen von sich aus neue Anforderungen an das Entwicklungsteam geben.

Es ist sogar explizit die Aufgabe des Scrum Master, jegliche "Angriffe" auf den ungestörten Sprint abzuwehren und das Team so zu schützen. Damit ist allerdings noch nicht garantiert, dass es tatsächlich keine Überlastung des Teams gibt. Denn insbesondere unerfahrene Scrum-Teams neigen dazu, sich maßlos zu überschätzen und sich auf unrealistische Sprint-Ziele zu verständigen. Sobald klar wird, dass ein Sprint-Ziel in Gefahr ist, beginnt das Team häufig mit Überstunden und Wochenendarbeit. Scrum stellt also per se noch keine Garantie für ein nachhaltiges Entwicklungstempo dar, es verlagert die Verantwortung dafür aber an die, die es betrifft: an das Entwicklungsteam. Mit Retrospektiven hält Scrum das richtige Werkzeug vor, um regelmäßig die Ursachen von zu hoher Arbeitsbelastung zu analysieren und diese dauerhaft zu beseitigen.

Kanban verwendet nicht den Mechanismus der Time-Boxen (Iterationen/Sprints) zum Schutz, sondern ein anderes Vorgehen, um das Team vor Überlastung zu schützen: die Beschränkung paralleler Arbeit (Work in Progress) in Kombination mit dem Pull-Prinzip.

Kanban stammt aus der produzierenden Industrie und dort speziell aus dem Bereich der Lean Production. Was manche gerne übersehen, ist die Tatsache, dass Lean Production nicht nur simple "Einsparungen" zum Ziel hat, sondern ein ganzheitlich ressourcenschonendes und dennoch schnelles Produktionsverfahren. Pull hat hierin mehrere Funktionen: Zum einen hat man festgestellt, dass das Pull-Prinzip bei gut eingespielten Lieferketten hilft, Wege und Lager zu sparen. (Beim Lagersparen kommt nun wieder die Begrenzung paralleler Arbeit ins Spiel, denn indem man das Lager begrenzt, limitiert man mögliche parallele Arbeit).

Interessant ist zum anderen aber, dass das Pull-Prinzip gleichzeitig hilft, die Maschinen zu schonen. Das Pull-Prinzip besagt im Original, dass eine "Senke" Material nicht von der "Quelle" anfordern darf, bevor das Material wirklich benötigt wird, um den Produktionsablauf nicht zu stören. Das soll unter anderem deshalb nicht geschehen, weil man die Maschinen schonen und teure Maschinenstunden nicht durch unnötige Wartung durch zu hohen Verschleiß vergeuden möchte. Diesen "Schutz vor Verschleiß" sollte den Entwicklern noch viel mehr als den Maschinen gegönnt sein.