Hi, herzlich willkommen in dieser Lektion, in der wir uns mit dem Thema Scrumban beschäftigen.

Welcher Inhalt wird in dieser Lektion behandelt?

Wir sprechen in den nächsten Minuten über:

• die Unterschiede sowie Vor- und Nachteile von Scrum und Kanban,
• die Kennzahlen der beiden Methoden,
• und die aus beiden Methoden abgeleitete Mischform Scrumban.
• Wir berücksichtigen dabei auch das Thema Budgetdruck,
• und ziehen letztendlich unser Fazit aus den gewonnenen Erkenntnissen.

Jetzt aber zum Inhalt dieser Lektion:

Wie unterscheidet sich Scrum von Kanban?

Ich habe bereits in der vorherigen Lektion angekündigt, mich dem streitbaren Thema Scrum etwas tiefer zu widmen.

Aber zuerst einmal die Frage, was Scrum und Kanban denn unterscheidet?

Aus Sicht von Scrum

• hat Kanban keine zeitgebundenen Iterationen (unter anderem die Sprints)
• Kanban benötigt keine Story-Estimation
• Kanban kennt das Prinzip des „Commitment“ (sprich: der Verpflichtung zur zeitlichen Lieferung definierter Inhalte) nicht
• Kanban arbeitet mit ganz anderen Kennzahlen als Scrum

und Kanban erfordert keinen Scrum Master

Du kannst dieses Video zur detaillierten Betrachtung der Unterschiede von Scrum und Kanban gerne pausieren. Beim Blick auf diese Gegenüberstellung von Scrum und Kanban fällt uns schnell auf, dass Scrum-Prinzipien und -Events in Kanban abgebildet werden können, aber für die Umsetzung nicht elementar notwendig sind. Dieser Umstand gibt uns bei einer Mischform aus Scrum und Kanban die Flexibilität, die Schwächen, Kritikpunkte und Streitpunkte von Scrum zu vermeiden. Und genau diese gewonnene Flexibilität der Mischform fördert das Verantwortungsbewusstsein im Team. Die Verantwortung richtet sich bei Scrumban auf die Einhaltung und Verbesserung von Team-Kennzahlen. Und im Grunde geht es für einen Projektmanager und Scrum Master sowohl bei Scrum als auch bei Kanban nicht nur um die Erreichung von Projekt- oder Sprintzielen, sondern auch um die Erreichung von performance- und qualitätsgetriebenen Kennzahlen. Wo liegt also der Unterschied bei den Kennzahlen?

Was ist die Velocity?

Für Scrum ist die Velocity eine ganz wichtige Kennzahl, welche die gelieferten Story Points pro Sprint angibt. Und die Story Points werden ja bezahlt. Ziel ist also, dass mindestens so viele Story Points geliefert werden, um damit die Kosten für das Team abzudecken. Mindestens!

Die Charts an sich können unterschiedlich dargestellt werden – hier einfach nur 2 Beispiele dafür.

Was ist Commited vs. Delivered?

Für die Sprintzielerreichung ist bei Scrum die Relation zwischen „Commited“ und „Delivered“ sehr wichtig. Ziel ist, dass alle bestätigten Stories eines Sprints auch geliefert werden. Die Unterschreitung in Form der hier dargestellten Estimation-Errors-Linie ist ein Makel und Versagen, das mit geeigneten Mitteln beseitigt werden muss. Die Messung der Estimation-Errors in % ermöglicht vergleichbare Ergebnisse selbst in der Startphase eines Projekts und bei Teamgrößenveränderungen.

Was ist ein Burn Down Chart?

Und dann gibt es bei Scrum noch den allseits bekannten Burn-Down-Chart, der dem Team anzeigt, ob die Abarbeitung innerhalb eines Sprints im geplanten Rahmen liegt, es einen Verzug oder vielleicht sogar einen Vorsprung gibt. Der Burn-Down ist der grafische Hinweis an das Team, bei Verzug den Einsatz zur Sprintzielerreichung zu erhöhen – sei es durch mehr Zeiteinsatz, die Konzentration auf die wesentlichen Anforderungen oder einen optimierten Personaleinsatz. Beim Blick auf diese Kennzahlen wird schnell deutlich, dass alle miteinander nicht zur Optimierung der Arbeitsabläufe beitragen können. Sie sind ausschließlich finanziell getrieben. Die Velocity gibt nicht die reale Lieferleistung an, sondern nur die Lieferung von Story Points (dem finanziellen Mehrwert, der erwirtschaftet wird). Wenn eine Story mehr Aufwand wie geplant verursacht, dann wird das mit der Velocity nicht erfasst. Commitment vs. Done führt nur dazu, dass Stories und Tasks im Team trotz unfertiger Bearbeitung auf Done gesetzt werden und beim Review nach dem Sprint wieder geöffnet werden müssen. Diese Kennzahl sagt in der Praxis gar nichts aus. Qualität spielt hier definitiv keine Rolle. Und das ist auch der große Kritikpunkt.

Der im Hardcore Scrum praktizierte manuelle Burn-Down auf dem Brown-Paper oder am Whiteboard ist in der Praxis vor allem bei verteilten Teams vollkommen unpraktikabel, weil in der Realität nicht jedes einzelne Team-Mitglied seine Task-Zettelchen up-to-date hält und der Scrum Master die damit verbundenen Stories ebenso nicht zeitnah in den dazu passenden Status verschieben kann. Die typische Kurve sieht dann halt doch immer wieder so aus und hat für das Team damit keinerlei Mehrwert.

Kommen wir nun zu den Kanban-Kennzahlen, die meiner Meinung nach eine der größten Stärken von Kanban sind und viel zum erfolgreichen Einsatz und der starken Ausbreitung von Scrumban beitragen.

Was ist der Durchsatz?

Da wäre zum ersten einmal der Durchsatz, der die Anzahl von Stories in einer frei definierbaren Zeitspanne angibt. Natürlich interessiert mich als Team-Mitglied auch, welchen Ertrag wir mit welchem „Aufgaben“ erwirtschaften. Mich interessiert aber primär, welchen Ertrag wir mit welchem „Aufwand“ erwirtschaften! Wenn die Story Points durch kaufmännische Verhandlung zu niedrig angesetzt sind, die Estimation-Ergebnisse aus dem Team nach dem Story-Sizing zur Auftragserteilung nach unten korrigiert wurden, dann kann das Team das nur noch sehr begrenzt korrigieren und einhalten. In diesem Fall den Makel beim Team zu suchen ist genauso vermessen, wie dann auch noch Abhilfe aus dem Team zu erwarten. Der Durchsatz pro Aufwand ist demnach eine geeignete Kennzahl um die echte Team-Performance zu messen und darauf basierend Optimierungspotenziale auszuschöpfen. Story Points als Verhandlungsergebnis mit dem Auftraggeber finden wir bei dieser Grafik und dieser Kennzahl demnach nicht.

Was bedeutet die Zykluszeit?

Eine zweite gute Kennzahl bei Kanban ist die Zykluszeit, also die Anzahl der Tage, die eine User Story von der Anforderungsermittlung bis zur Auslieferung an den Kunden benötigt. Das Besondere ist hier, dass wirklich alle Phasen abgedeckt werden und somit Optimierungspotenziale offengelegt werden, die Zykluszeit so kurz wie möglich zu halten. Das Ziel ist hier innerhalb eines vereinbarten Perzentils von beispielsweise 85% zu bleiben. 15% verschieben sich demnach aufgrund beabsichtigter Zurückstellungen. Wenn der Anteil oberhalb des vereinbarten Perzentils zu hoch ist, dann spricht das dafür, dass die Anforderungsermittlung nicht zielgerichtet genug gearbeitet hat, also Anforderungen eingekippt werden, die noch nicht gegebene Abhängigkeiten haben. Das gilt es natürlich zu vermeiden. Die Anforderungsermittlung muss vom Product Owner gut ausgesteuert sein, damit die ermittelten Anforderungen flüssig umgesetzt werden können.

Was ist ein Kumulatives Flussdiagramm?

Und dann gibt es bei Kanban auch noch das Kumulative Flussdiagramm, welches alle Projektphasen über den gesamten Projektzeitraum abdeckt und dabei die Anzahl der Anforderungen und die Zeit der Bearbeitung anzeigt. Die Anzahl der erledigten Anforderungen nimmt in der Projektlaufzeit natürlich immer weiter zu (hier blau dargestellt). Die Anforderungsermittlung ist zu Projektstart in der Regel sehr hoch, flacht dann über die Laufzeit ab und ebbt zum Ende hin komplett ab. Analyse, Entwicklung und Testing sollten nach einer akzeptablen Einphasung des Dev-Teams bis zum Ende relativ konstant verlaufen, wenn die Teamstärke im Projektverlauf nicht nennenswert verändert wird. Auch mit diesem Diagramm werden Fehlentwicklungen als Basis für eine Korrektur aufgezeigt.

So, was bleibt uns also abseits der Kennzahlen noch zu sagen?

Welche Eigenheiten hat Scrum?

Scrum ist extrem strukturiert. Und das ist auch gut so. Aber eben auch sehr streng. Besonders höherrangige Teammitglieder tun sich damit erfahrungsgemäß sehr schwer und stoßen in der Folge immer wieder Sinnhaftigkeitsdiskussionen an, die in Scrum für die Grundprinzipien aber keine Daseinsberechtigung haben. Scrum beinhaltet einen konstanten Zeitdruck, der durch Time-Boxing umgesetzt wird (wir gehen darauf in einer Folgelektion noch näher ein). Aber auch die Events sind streng abgegrenzt, was bedeutet, dass alle geplanten, aber nicht erreichten Eventinhalte mit einem echten Versagen gleichzusetzen sind. Unfertige Inhalte können nach Auslaufen eines Events nicht einfach so fertig bearbeitet werden. Nein, sie werden zurückgesetzt und müssen dann neu eingeplant und noch einmal angegangen werden. Sei es im Sprint, im Refinement oder sonst wo. Scrum deckt jegliche Schwächen im Team auf und fordert vom Team geeignete Maßnahmen, um diese Schwächen in Zukunft zu vermeiden. Die Strenge von Scrum führt unmittelbar zum Ausschluss bequemer Auswege oder einem darum herum Gewurtschtel. Scrum ist gnadenlos und erfordert eine extrem hohe Veränderungsbereitschaft und Demut. Mit dem harten Cut bei Sprintende werden die Sprintplanung, das dazu notwendige Story-Estimation und ein sauberes Refinement zu erfolgsrelevanten Faktoren für die Sprintzielerreichung. Aber auch innerhalb des Refinement wird die Lösungszeit durch ein Time-Boxing limitiert. Das Ziel und die Flexibilität ordnen sich wie beim Wasserfallmodell wieder der Planung unter. Und die Qualität leidet ebenso.

Dieser Umstand führt dann auch zur Kritik, dass Scrum in Teilbereichen nicht mehr wirklich agil, sondern zeit- und finanzgetrieben ist. Darunter leidet dann nicht nur die Umsetzungsqualität, sondern auch die Kreativität für neue Lösungsansätze, die ja doch das Ziel der Agilität ist. Bitte erinnere Dich hier an das Agile Manifest. Neues zu wagen ist unter diesem Umstand aber kaum mehr möglich – zu riskant. Und dann sind wir mit dem puren Scrum in der Situation, dass uns die Methode nicht mehr führt, sondern limitiert und wichtige Ziele der Agilität verhindert.

Dazu kommt die extreme Belastung eines Scrum-Teams. Das Team steht konstant unter Druck, um den maximalen Output zu erreichen. Was für das kaufmännische Ziel zuerst einmal positiv klingt, mündet in der Regel jedoch in hoher Fluktuation – und das in einer Zeit, in der Fachwissen nicht unbedingt reif von den Bäumen fällt. Das pure Scrum macht Dich einfach alle und erfordert einen ganz besonderen Menschenschlag, der das notwendige Fachwissen, äußerste Disziplin und Zuverlässigkeit mit Leidensfähigkeit, Demut und Selbstverantwortung vereint. Ich möchte nicht sagen, dass es so etwas nicht gibt. Sicherlich, es gibt da draußen High-End-Scrum-Teams. Aber die zelebrieren dann schon die ganz hohe Schule der Agilität. Die Masse erreicht das sicherlich nicht und die Projekte mit einem derart radikalen Ansatz gehen dabei in der Folge baden, erreichen ihre Ziele nicht, zerfallen, enden in Gruppendepression.

Was ist Scrumban?

Aus diesem guten Grund hat sich Scrumban entwickelt. Scrumban nutzt alle Events und Werkzeuge von Scrum, und ist damit auch perfekt mit anderen Scrum-Projekten kompatibel. Anstatt knallharten Grenzen in Events und Time-Boxing, nutzt Scrumban zur Aufgabenverfolgung Kanban-Boards, bei denen Aufgaben aktiv aus der vorhergehenden Swim-Lane abgeholt und nach Erledigung in die folgende Swim-Lane verschoben werden. Hardcore-Scrum-Coaches nennen so etwas dann Streichelzoo. Damit ist eine viel individuellere Aufgabenverfolgung möglich, als bei fest limitierten Events oder Time-Boxing. Weitere positive Effekte sind die bessere Einhaltung von Qualitätsanforderungen und das Einbringen von Kreativität für innovative Lösungen. Wenn ein Event wie z.B. ein Sprint beendet ist, dann wird eine noch nicht fertiggestellte Aufgabe je nach Anforderung nach dem Sprint oder im Folgesprint fertigbearbeitet – ohne Hickhack und Druck.

Wenn Du heute hörst, dass ein Projekt nach Scrum arbeitet, dass steckt fast immer Scrumban dahinter. Das pure Scrum findest Du heute kaum mehr – und ist auch realistischerweise nur innerhalb eines Softwareunternehmens für die Entwicklung interner Produkte mit internem Personal möglich, das konstant persönlich vor Ort zusammenarbeiten muss. Hardcore-Scrum ist für verteilte Teams kaum nutzbar und es gibt so gut wie keine ALM-Lösungen, die das pure Scrum unterstützen. Fast alle ALM-Lösungen arbeiten grundsätzlich mit Kanban-Boards, nur wenige stellen Add-Ons für die Implementierung von Scrum-Boards zur Verfügung – und die erfüllen dann den Hardcore-Scrum-Mastern noch nicht einmal die notwendigen Anforderungen. Das pure Scrum ist eine Zettelwirtschaft, die einen ins Zeitalter vor der Schreibmaschine zurückwirft. Die handschriftliche Zettelschreiberei stellt die Teammitglieder wegen fehlender Korrekturmöglichkeiten immer wieder vor ungewohnte Herausforderungen und die Leserlichkeit der Inhalte ist teils haarsträubend bis unmöglich. Dazu fallen die Klebezettel regelmäßig von der Wand und die nachfolgende Zuordnung zum passenden Vorgang gestaltet sich vorsichtig ausgedrückt bei vielen Vorgängen etwas schwierig. Mit der Archivierung von Vorgängen sieht es genauso haarsträubend aus – von im wahrsten agilen Sinne nicht existent bis zu ewig langen Pappordner-Reihen, aus denen Du nie wieder etwas finden wirst. In allen Bereichen hagelt es deshalb geradezu Fehlermöglichkeiten. Ich denke da nur an die Interpretationsversuche unleserlicher Zettelinhalte. Du rennst halt doch nicht immer zum Verfasser, vor allem nicht auf Kundenseite. Alles in allem also keine echte Option für die Masse der Projekte.

Wann wird heute Hardcore Scrum praktiziert?

Das pure Scrum wird heute eigentlich nur noch ausgepackt, wenn der Budgetdruck im Projekt extrem groß ist und die kaufmännische Seite deshalb versucht, die Effizienz im Projekt mit dem extremen Druck von Scrum in die Höhe zu treiben. Ich persönlich kann vor solch einem Versuch nur warnen, weil der mit großer Wahrscheinlichkeit scheitert. Viel zielführender wäre, sich einer drohenden Minusmarge bewusst zu sein, klare Grenzen für ein strategisches Engagement zu definieren und im Fall des Unterschreitens das Projekt solange einzufrieren, bis ein passendes Budget mit passenden Zielen und passendem Sourcing zur Verfügung steht. Nur diese Herangehensweise ist im agilen Sinn professionell.

Ich persönlich finde es ganz gut, dass sich aus dem archaischen Scrum so etwas wie Scrumban entwickelt hat. Scrumban ist einfach praktikabel, berücksichtigt die heute existierenden Rahmenbedingungen wie verteilte Teams, Remote-Arbeit, der Einbeziehung von Experten aus der ganzen Welt und der Arbeit mit Softwarelösungen anstatt mit unleserlichen Papierzetteln, die nicht an den Wänden kleben bleiben wollen. Wenn ich nur an die ganzen Reise- und Raumkosten für zusammengekarrte Teammitglieder denke, dann wird mir als Budgetverantwortlicher ganz übel. Diese Kosten gehen alle vom raren Projektbudget weg. Nein, Scrumban erfüllt die heutigen Anforderungen viel besser – und macht zudem Spaß. Auch dieser Aspekt ist für die Zielerreichung wichtig.

Gibt es Scrumban als Methode oder Framework?

Ja, und klar ist auch: Scrumban als Methode oder Framework gibt es gar nicht! Das ist eine sich selbst entwickelte Mischform ohne feste Definition. Jeder kann Scrum und Kanban nach den eigenen Bedürfnissen und Neigungen mischen. Dass sich das dann Scrumban nennt, ist eine reine Wortschöpfung. Denn die dann praktizierte Mischform ist weder reines Scrum noch reines Kanban.

Fassen wir nun zusammen, was wir in dieser Lektion behandelt haben:

• wir haben uns die Unterschiede sowie Vor- und Nachteile von Scrum und Kanban angeschaut,
• die Kennzahlen beider Methoden unter die Lupe genommen und dabei festgestellt, welche Kennzahlen für die Teamperformance tatsächlich relevant und praktikabel sind,
• daraus haben wir eine Mischform namens Scrumban abgeleitet,
• wir haben darüber gesprochen, wie wir bei sehr hohem Budgetdruck professionell agieren sollten,
• und daraus ein Fazit zur Anwendung von Scrumban gezogen.

Da dies die letzte Lektion in diesem Kurs ist, werde ich die Gelegenheit zur Verabschiedung nutzen. Scrum gegen Kanban – das ist immer wieder Grund für hitzige Auseinandersetzungen. Vielleicht brennt es auch Dir schon unter den Nägeln? Also, jetzt auf mich mit Gebrüll (lachen). Ich bin dann mal weg …