Scrum und Kanban kommen in der Softwareentwicklung immer häufiger zum Einsatz und haben in der Familie der Agilen Methoden inzwischen ihren festen Platz eingenommen. Doch sind diese beiden Ansätze überhaupt miteinander vereinbar?

Software-Kanban stellt den Arbeitsprozess für das Team transparent dar und spürt so Verbesserungsansätze auf. Arne Roock stellt diese Methode und ihre Prinzipien vor. Ein Beispiel zeigt, wie sich die Methode einsetzen lässt.

Viele Manager glauben, dass sämtliche Ressourcen immer zu 100% ausgelastet sein müssen. Falsch, meint Dr. Arne Roock. Er erläutert, wie Sie mit Hilfe eines Kanban-Boards bei verringerter Auslastung eine hohe Produktivität erreichen können.

Einmal war ich bei einer Firma, deren Chef gern Kanban einführen wollte. Ich war regelmäßig vor Ort, gab Schulungen, moderierte Workshops und führte Einzelgespräche. Ein Marketing-Mitarbeiter schilderte mir, dass er mit dem Daily unzufrieden war. 

Einmal war ich bei einer Firma, die kurze Zeit vorher mit Kanban angefangen hatte, sodass mir ihr Geschäftsführer jetzt stolz ihr Board zeigte. In der Tat war es beachtlich, was sie in kurzer Zeit bereits erreicht hatten, ohne dabei externe Unterstützung in Anspruch zu nehmen.

hEinmal war ich bei einer Firma, deren Chef gern zu seinen Projektleitern sagte: "Ich will keine Probleme hören, ich will nur Lösungen hören!" Die Äußerung kann nicht nur sehr demotivierend sein, die dahinterliegende Einstellung ist sogar gefährlich.

Einmal war ich bei einer Firma, die gerade ein (für ihre Verhältnisse) großes Projekt startete. Die Firma war recht klein und jung und hatte keine Erfahrung mit Projektmanagement. Im Gespräch wurde schnell klar, dass man eine Person benötigt, die sich darum kümmert, das Projekt zu einem erfolgreichen Ende zu führen. Zum Glück war auch schnell eine Kollegin gefunden, die nicht nur Lust auf diese neue Aufgabe hatte, sondern auch von allen Beteiligten als überaus geeignet angesehen wurde.

Aber worin genau würde denn nun die Aufgabe bestehen? Keiner wusste es genau. Dies rührte zum großen Teil daher, dass die junge Firma eine starke Abneigung gegen den Begriff "Projektmanager" hatte und damit stets große Konzerne, strikte Hierarchien und starre Budgets verband. Daher kam es auch nicht in Frage, die Kollegin einfach auf eine PM-Schulung zu schicken oder ihr ein Lehrbuch zum Projektmanagement in die Hand zu drücken. Also wurde entschieden, mit der Ungewissheit der neuen Rolle zu leben, ins kalte Wasser zu springen und mit der Zeit zu lernen.

Einmal war ich bei einer Firma, die ihre Entwicklung über vier Standorte verteilt hatte – drei unterschiedliche Zeitzonen in drei unterschiedlichen Kontinenten. Das funktionierte nicht ganz so perfekt, und jetzt stellte mir der Kunde die Frage, wie Kanban ihnen helfen könnte, das zu "reparieren". Die kurze Antwort dazu ist, dass Kanban eine Art böse Schwiegermutter ist: Sie sagt einem immer wieder wie blöd man ist, aber sie ändert einen nicht.

Einmal war ich bei einer Firma, die ein großes Problem hatte. Die Qualität war schlecht. Diese Firma entwickelt und vertreibt ein Softwareprodukt, und in letzter Zeit stieg die Anzahl der Fehler. Gleichzeitig sank die Kundenzufriedenheit.

Einmal war ich bei einer Firma, die ein neues Produkt launchen wollte. Das Produkt war vielversprechend und innovativ – kein Mitbewerber hatte zuvor etwas Ähnliches entwickelt. Für dieses neue Produkt wurde ein eigenes Team zusammengestellt, in dem sich auch einige neu eingestellte Spezialisten befanden, denn die Firma hatte von Haus aus keine Erfahrung mit der eingesetzten Technologie.

Jetzt stand natürlich die eine große Frage im Raum: "Wann sind wir fertig?" Schnell entspann sich eine Diskussion um verschiedene Schätzverfahren; die Beteiligten warfen mit Begriffen wie "Schätzpoker", "Function Points", "Abstrakte Schätzmaße" und "Schätzmeetings" um sich. Die Entwickler, die sich offenbar an frühere Erfahrungen mit Schätzungen erinnerten, rollten mit den Augen und schnell waren die ersten zynischen Bemerkungen zu hören.