Mein Artikel zur Scrum-Master-Karriereleiter hat viele Fragen aufgeworfen. Die meisten Fragen erhielt ich zu den Scrum-Master-Stufen 4 und 5. Eine immer wieder gestellte Frage war:
„Wie können Scrum Master ihr Team unterstützen, auch andere Methoden in ihre Arbeit zu integrieren?“
Diese Frage werde ich heute am Beispiel von Kanban beantworten.
Ich zeige dir, wie du die Ideen von
- Visualisierung des Workflows,
- aktivem Management laufender Arbeit,
- Begrenzung von Work in Progress (WIP) und
- kontinuierlicher Verbesserung
in deinem Scrum Team umsetzen kannst.
Bevor wir loslegen, möchte ich dir diese Frage beantworten:
Warum solltest du daran interessiert sein, dass dein Scrum Team Ideen von Kanban in seiner Arbeit berücksichtigt?
Scrum optimiert die Effektivität.
Effektivität bedeutet Wirksamkeit. Dafür nutzen wir in Scrum Feedbackschleifen. Da sich in der Produktentwicklung nie alles vorhersehen lässt, arbeitet das Team niemals länger als 30 Tage, bis es Rückmeldung einholt, ob es an dem Richtigen arbeitet.
Somit hilft Scrum den Teams, wirksam zu sein.
Kanban optimiert die Effizienz.
Effizienz bedeutet, mit minimalem Aufwand zu arbeiten. Dafür nutzen wir in Kanban das Konzept des „Wertflusses“. Da in der Produktentwicklung nicht alle Arbeiten Wert schöpfen, legt das Team sein Augenmerk darauf, dass jeder seiner Arbeitsschritte Verschwendung minimiert. Also die Arbeit richtig getan wird.
Somit hilft Kanban den Teams, Verschwendung zu vermeiden.
Ich weiß, was du jetzt denkst: Erfolgreiche Teams sollten doch sowohl effektiv als auch effizient arbeiten. Ich stimme dir zu. Deshalb sollte die Frage nicht lauten: Scrum oder Kanban? Sondern vielmehr: Womit soll das Team beginnen?
Wenn ein Team mit Scrum begonnen hat, erhältst du hier vier Ideen, wie du Kanban auch in deinem Team nutzen kannst.
Beginnen wir damit:
Idee #1: Visualisierung des Wertflusses
Wie viele Spalten hat das Sprint Backlog deines Teams?
Wenn ich raten müsste, dann würde ich auf drei tippen. Trägt die erste Spalte die Aufschrift „To-do“, die zweite „Doing“ und die dritte „Done“? Daran ist erstmal nichts auszusetzen. So steuern die meisten noch unerfahrenen Scrum Teams ihren Arbeitsprozess im Sprint.
Willst du allerdings den Wertfluss deines Scrum Teams optimieren, dann solltest du weiterdenken:
Konzentriere dich nicht auf den Arbeitsprozess, sondern auf den Wertfluss. Was ist der Unterschied? Die Tasks einer User Story beschreiben meist den Arbeitsprozess. Sie helfen dem Team zu visualisieren, wer gerade an was arbeitet. Wenn eine Task im „Doing“ ist, lässt sich noch keine Aussage machen, wie weit die Entwicklung der User Story fortgeschritten ist. Wirklichen Wert versprechen nur ganze User Stories. Deshalb solltest du diese betrachten. Sie starten in der „To-do“-Spalte und enden in der „Done“-Spalte.
Was passiert dazwischen?
Wenn du das beantwortest und visualisierst, kennst du den wahren Fluss von Wert in deinem Team.
Ich gehe bei der Beantwortung dieser Frage so vor: Zuerst sammle ich alle Aufgaben oder Aktivitäten, die das Scrum Team erledigt, bis die User Story als „Done“ markiert ist. Jetzt kenne ich die einzelnen Schritte, die ein Eintrag des Product Backlogs durchläuft, bis er Wert liefert. Diese Schritte stellen die verschiedenen Stadien des Arbeitsprozesses dar.
Das Ergebnis könnte etwa so aussehen:
Wenn du den Wertfluss in deinem Team kennst, kannst du ihm helfen, diesen zu verbessern.
Idee #2: Aktives Management laufender Arbeit
Leider verlaufen die meisten Stand-ups noch folgendermaßen:
Reihum wird jeder Entwickler aufgefordert, diese drei Fragen zu beantworten:
- Was habe ich gestern getan?
- Was werde ich heute erledigen?
- Sehe ich irgendein Hindernis?
Von außen betrachtet, ähneln diese Stand-ups einem Statusbericht der Entwickler an den Scrum Master.
Wenn du ein treuer Leser meiner „Scrum Impulse“ bist, dann weißt du, dass ich von einem solchen Statusmeeting nicht viel halte. Ich weiß aber auch, wie schwer es ist, dieses fehlerhafte, aber lang antrainierte Verhalten zu ändern. Über die Jahre habe ich vieles ausprobiert, um solche Situationen zu verändern. Die größten Erfolge hatte ich bisher immer dann, wenn ich das Daily Scrum von einem personenzentrierten zu einem arbeitszentrierten Meeting umwandeln konnte.
Wie kann dir das gelingen?
Indem du die Entwickler aufforderst, die laufende Arbeit aktiv zu managen.
Ich habe es bisher immer so gemacht: Ich versammle die Entwickler zum Daily Scrum um das neue Scrum Board, welches den Wertfluss der Arbeit visualisiert. Nun lenke ich das Gespräch auf den Fluss von Wert, indem ich folgende Fragen stelle:
- Welche User Stories sind blockiert und was kann getan werden, um die Blockaden aufzulösen?
- Welche User Stories bewegen sich langsamer als erwartet von links nach rechts?
- Was können wir heute tun, um die aktuellen Arbeiten daran abzuschließen?
Du erkennst, ob dein Team den Fluss von Wert aktiv zu verbessern versucht, wenn du eher Aussagen wie diese hörst:
„Die Story zur Nutzeranmeldung hängt schon seit einigen Tagen im Test fest. Wer testet sie und wie kann ich euch dabei helfen, dass wir sie endlich abschließen können?“
Und nicht so eine Aussage:
„Gestern habe ich an Ticket 245 gearbeitet und heute werde ich an Ticket 246 arbeiten. Keine Probleme!“
Das aktive Management von laufender Arbeit ist ein guter Schritt dahin, dass mehr User Stories abgeschlossen und nicht zu viele User Stories gleichzeitig angegangen werden.
Diese Idee lässt sich noch verstärken:
Idee #3: Begrenzen von „Work in Progress (WIP)“
Was ist der schnellste Weg, eine User Story abzuschließen?
Für die meisten Scrum Teams ist das noch sehr ungewohnt, aber der schnellste Weg ist, wenn das ganze Team nur an einer einzigen User Story arbeitet. Es gibt eine Vielzahl von Simulationen, die dies verdeutlichen. Mein Liebling ist das Penny Game. Wie du es mit deinem Team nutzen kannst, habe ich in diesem Artikel festgehalten: „Sprint Retrospektive: Nutze die 4-Cs-Karte für eine gehirngerechte Gestaltung, die zum Lernen und aktiven Mitmachen einlädt“. In diesem Artikel hier möchte ich daher nur das mathematische Gesetz nennen, das diesen Zusammenhang zeigt. Die Rede ist von Littles Gesetz. Es zeigt auf, dass für einen bestimmten Prozess mit einem bestimmten Durchsatz im Allgemeinen gilt:
Je mehr User Stories zu einem bestimmten Zeitpunkt (im Durchschnitt) bearbeitet werden, desto länger dauert es, diese User Stories (im Durchschnitt) zu beenden.
Daraus können wir ableiten:
Falls die Fertigstellung von User Stories zu lange dauert, sollte das Scrum Team als Erstes die Reduzierung der „Work in Progress“ in Betracht ziehen. Das Extrem davon ist meine obige Behauptung:
Das ganze Team arbeitet nur an einer User Story!
Wenn du dein Team dabei unterstützen willst, effizient zu arbeiten, dann führe „Work-in-Progress-Limits“ ein. Da die richtige Begrenzung der laufenden Arbeit von der Anzahl der Mitglieder, der Arbeiten und unzähligen weiteren Bedingungen abhängt, muss ein WIP-Limit gleich Eins nicht zwangsläufig das Optimum darstellen. Die Herausforderung ist, das Optimum zwischen dem minimalen Einsatz von Arbeitszeit und der maximalen Anzahl fertiger Product-Backlog-Einträge zu finden.
Dies bringt uns zur letzten Idee:
Idee #4: Kontinuierliche Verbesserung
Scrum Teams sind es gewohnt, in der Sprint Retrospektive über die Verbesserung der
- Zusammenarbeit,
- der Definition of Done und
- der Werkzeuge zur Softwareentwicklung
zu sprechen.
Allerdings sprechen sie selten über die Verbesserung am Arbeitsfluss. Nutzt du die letzten drei Ideen, dann hast du dafür die Grundlage geschaffen.
- Dein Scrum Team hat nun eine Beschreibung, welche Stationen die Einträge des Product Backlogs durchlaufen.
- Es kennt die Fragen, die ihm helfen, die Einträge von links nach rechts zu bewegen.
- Es kennt den Zusammenhang, der die Dauer bis zur Fertigstellung einer User Story beschreibt.
Nun könnt ihr Verbesserungen daran vornehmen.
Wie könnten die aussehen?
Ihr könntet auch auf die Suche nach dem passenden WIP-Limit gehen.
Ziel sollte es sein, die Wartezeit einer User Story zu minimieren.
Wurde die Arbeit an einer User Story begonnen, sollte die Arbeit daran nicht verzögert werden, da Wartezeiten und Verzögerungen Verschwendung sind. Ziel der Kanban-Ideen ist es, die Verschwendung zu minimieren und damit die Effizienz zu verbessern. Daniel Westermayr bringt es in seinen Kanban-Schulungen treffend auf den Punkt:
„Unfertige Features sind Inventar, Inventar kostet Geld.“
(Wenn du mehr über Kanban lernen willst, dann kann ich dir den Besuch einer „Team Kanban Practitioner“-Schulung von Daniel nur empfehlen. In nur einem Tag lernst du dort alles, wofür ich Jahre gebraucht habe, es mir selbst beizubringen.)
In Gegensatz zur Fertigung von Waren in einer Fabrik können wir das Inventar bei Softwareentwicklung erstmal nicht sehen. Unfertige Features stapeln sich nicht in den Gängen von Lagerhallen und versperren nicht allen den Weg. Im Gegenteil: Sie bleiben verborgen.
Wenn du diese Verschwendung transparent machst, dann hilfst du, die Effektivität deines Teams zu verbessern und sparst deinem Unternehmen viel Geld, indem du ihm unnötige Lagerhaltung ersparst.
Mehr noch: Du hilfst deinem Unternehmen, ein agiles Prinzip wirklich zu leben:
„Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“