On Lean and Agility

Bild: Unsplash / Olga Guryanova - Lizenz

Mit dem Scrum-Framework haben Jeff Sutherland und Ken Schwaber etwas Bemerkenswertes geleistet: es ist ihnen gelungen, das de facto-Standard-Vorgehen der globalen Software-Industrie zu entwickeln. Der Minimalismus, der die Stärke von Scrum bildet, ist dabei gleichzeitig seine Schwäche - es ist schnell zu verstehen, lässt dabei aber auch einen Freiraum, der mit komplizierten und umfangreichen Regelwerken gefüllt werden kann, von denen SAFe und Disciplined Agile (DA) die bekanntesten sein dürften.

Da ein Grossteil der agilen Community diese beiden Ansätze ablehnt, gibt es bereits seit langem den Wunsch, ihnen eine dem ursprünglichen Geist von Scrum eher entsprechende Erweiterung entgegenzusetzen, idealerweise beruhend auf bereits verbreiteten Praktiken. Large Scale Scrum (LeSS) ist vor diesem Hintergrund entstanden, hat aber nur einen eher inoffiziellen Status. Erst seit Juni 2025 gibt es eine quasi-offizielle Erweiterung, verfasst (u.a.) von Jeff Sutherland: das Scrum Guide Expansion Pack.

Dieses Expansion Pack (mit ca 50 Seiten deutlich umfangreicher als der 13-seitige Scrum Guide, aber auch deutlich schlanker als SAFe und DA) wurde neben Sutherland von John Coleman und Ralph Jocham mitverfasst und besteht aus vier Sektionen: der eigentlichen Erweiterung mit dem Namen Adaptation of: The original Scrum Guide und einem Appendix aus den drei Teilen MORE executive SUCCESS extract, Cynefin Framework Kind of Explanation unofficial & unauthorized und Emergent Strategy.

In die erste Sektion ist auch der eigentliche Scrum Guide eingebettet, um ihn zu ergänzen enthalten alle vier Sektionen weiterführende Erläuterungen, einige der erwähnten verbreiteten Praktiken und historische Hintergründe. Das ist zum Teil banal (etwa wenn erklärt wird, dass "self managing" ein von aussen kommendes Management ausschliesst) zum Teil aber auch durchaus aufschlussreich (z.B. dann wenn erklärt wird, welche Untergruppen die eher diffuse Gesamtgruppe der "Stakeholder" haben kann).

An einigen Stellen finden de facto Erweiterungen des Scrum Guides statt, so gibt es jetzt nicht mehr lediglich drei Artefakte (Product Backlog, Sprint Backlog und Increment) sondern mit dem Product ein viertes; aus der einen Definition of Done sind die Definition of Outcome Done und die Definition of Output Done geworden; zu den drei Rollen, bzw. Accountabilies (Developer, Product Owner, Scrum Master) kommt mit den Stakeholdern eine vierte.

Zu den aufgenommenen Praktiken gehören am prominentesten die Produkt Vision (die das Product Goal nicht ersetzt sondern ergänzt), die Akzeptanzkriterien (die nochmal aufgeteilt werden in die eigentlichen Akzeptanzkriterien und so genannte Outcome-Kriterien) und die häufigsten in Retrospektiven besprochenen Themen (u.a. Professionalität, Effektivität und Teamdynamiken), über den Text verstreut finden sich aber auch weitere, etwa Systems Thinking, (Product) Discovery und Beyond Budgeting.

Eher in den Berech der Nerd-Wissens gehören einige Exkurse zu historischen Begrifflichkeiten und Dokumenten. So werden die Scrum Werte Focus, Openness, Courage, Commitment und Respect aus dem amerikanischen Militär-Begriff OODA (Observe, Orient, Decide, Act) abgeleitet und gleich mehrere Absätze widmen sich dem wissenschaftlichen Paper The New New Product Development Game von 1986, das eine zentrale Inspirationsquelle für Sutherland und Schwaber war.

Im Gegenzug dazu gibt es mit einem eigenen Teil zum Thema der künstlichen Intelligenz (KI) auch etwas, das erkennbar von aktuellen Entwicklungen getrieben ist. Kurioserweise eingeordnet zwischen den Rollen, bzw. Accountabilies werden die damit verbundenen Möglichkeiten und Risiken herausgestrichen (und es wird hervorgehoben, dass der Scrum Master keine KI sein darf¹). Das ist nicht falsch, aber etwas willkürlich, mit gleicher Berechtigung hätte man z.B. auch Big Data oder Cloud mit aufnehmen können. 

Ob das Scrum Guide Expansion Pack weite Verbreitung finden und noch weiter modifiziert werden wird, wird sich zeigen, wahrscheinlich ist aber in Analogie zum eigentlichen Scrum Guide (den es nur ergänzt, aber nicht ersetzt) beides. Ob es sich als Ersatz oder Gegenmodell zu den kommerziell erfolgreichen und von professionellem Marketing unterstützen Ansätzen SAFe und DA durchsetzen wird ist dagegen weit weniger klar, das in den nächsten Jahren zu beobachten wird sicherlich spannend sein.

Auf jeden Fall wird man es aber gut nutzen können, um zu erkennen, wer sich wirklich für das Thema Scrum interessiert. Denn ganz sicher werden nus solche Personen bereit sein, die gesamten ca 50 Seiten durchzulesen. Alle anderen werden das vermutlich geflissentlich an ihren Scrum Master delegieren.

Bild: Flickr / Rosenfeld Media - CC BY 2.0

Einer der grossen Unterschiede zwischen den beiden populärsten agilen Frameworks, Scrum und Kanban, war immer, dass Scrum mit dem Scrum Guide ein verbindliches Regelwerk hatte, während Kanban trotz weit verbreiteter und allgemein anerkannter Praktiken eher "Open Source" war, so dass jeder hineindefinieren und -interpretieren konnte was er wollte. Diese Unklarheit hat immer wieder den Wunsch nach einem "Kanban Guide" aufkommen lassen.

Die erste Organisation die versucht hat diese Lücke zu füllen (bzw. den damit verbundenen Zertifizierungs-Markt zu erschliessen) war die Lean Kanban University, die 2016 den trotz seines Namens etwas aufgeblähten Essential Kanban Condensed Guide veröffentlichte, der dann 2021 durch den schlankeren "Official" Kanban Guide abgelöst wurde. Aufgrund seines Namens wird der immer wieder für das einzige und verbindliche Kanban-Regelwerk gehalten.

Da der Begriff und die Idee von Kanan nicht geschützt sind, gibt es aber auch Alternativen, unter denen die vielleicht bekannteste schlicht The Kanban Guide heisst. Selbst wenn seine Verfasser Daniel Vacanti und John Coleman mit ProKanban (einer anderen Zertifizierungs-Organisation) verbunden sind, ist das Dokument bewusst nicht mit deren Brand verbunden oder auf deren Website gehostet, um so seinen universellen Anspruch und seinen nicht-kommerziellen Charakter hervorzuheben.

Von seiner Struktur her organisiert er sich sehr stark am Scrum Guide, bis hin zu dem Punkt, dass mehrere seiner Abschnitte fast identisch benannt sind (Purpose of the Kanban Guide statt Purpose of the Scrum Guide, Definition of Kanban statt Scrum Definition, Kanban Theory statt Scrum Theory, etc.).¹ Lediglich in seinem Mittelteil gibt es Abweichungen, gegen Ende entspricht der Aufbau mit End Note und Acknowledements wieder sehr stark dem des Scrum Guides.

Inhaltlich sind es auch vor allem diese mittleren Abschnitte, die Kanban Practices, das Improving the Workflow und die Kanban Measures die interessant sind.² Den grössten Teil nehmen dabei die Practices ein, es handelt sich bei ihnen um Defining and Visualizing the Workflow, Actively Managing Items in a Workflow, Controlling Work In Progress und  Service Level Expectation.³ Nach Ansicht der beiden Autoren handelt es sich dabei um die unverzichtbaren Kernbereiche der Kanban-Methode.

Mit Actively Managing Items in a Workflow sind im Kanban Guide die Tätigkeiten gemeint, die den reibungslosen Durchfluss von Arbeit durch das System sicherstellen oder wiederherstellen sollen. Im Einzelnen sind das Controlling Work in Progress (d.h. dessen Menge), Avoiding work items piling up in any part of the workflow, Ensuring work items do not age unnecessarily (mit Hilfe von Service Level Agreements) und Unblocking blocked work.

Mit Controlling Work in Progress und Ensuring work items do not age unnecessarily bekommen die erste und letzte der zuletzt genannten Tätigkeiten noch einen eigenen Abschnitt, in dem tiefergehend erläutert wird, was sich dahinter verbirgt, bzw. welche weiteren Konzepte damit verbunden sind. Hier finden sich u.a. auch das Pull-Prinzip und das probabilistische Forecasting, die damit im Vergleich zu anderen Kanban-Auslegungen eine eher wenig prominente Plazierung haben.

Im Vergleich dazu ist das Improving the Workflow relativ knapp beschrieben. Hervorgehoben wird vor allem, dass es überhaupt stattfinden sollte, dass es auf der Grundlage von Zahlen und/oder Erfahrungen erfolgen sollte und dass es Verbesserungen der Effizienz, Effektivität und Vorhersagbarkeit zum Ziel haben sollte. Bemerkenswert ist, dass explizit nicht nur kleine sondern auch grosse Verbesserungen möglich sind, also nicht nur Kaizen sondern auch Kaikaku.

Die Kanban Measures sind schliesslich wieder die grossen Klassiker: Work in Progress-Menge, Throughput, Work Item Age und Cycle Time (Lead Time dagegen bemerkenswerterweise nicht). Neben ihrer kurzen Erklärung wird noch unterstrichen, dass sie nur zum Zweck der Prozessverbesserung erhoben und kein Selbstzweck sein sollen, und dass es möglich ist, sie um weitere Metriken zu ergänzen, wenn man darin einen Mehrwert sieht.

Was der Kanban Guide nicht (bzw. nur als Nennung optionaler Möglichkeiten) enthält, sind Meetings und Rollen. Es wird zwar erwähnt, dass es möglich ist, Dailies und Retrospektiven (die hier nur Reviewing the Definition of Workflow from Time to tTime heissen) abzuhalten, von einer zu starken Formalisierung wird aber abgeraten. Im Fall der Rollen ist nicht mal das gegeben, sie werden an keiner Stelle des Kanban Guide auch nur erwähnt, geschweige denn vorgegeben.

Zur Bewertung, bzw. Einordnung: das auf den ersten Blick Auffälligste am Kanban Guide dürfte die starke Anlehnung seiner Struktur an die des Scrum Guide sein. Die mag ihre Vorteile haben, da jemand der bisher nur Scrum kennt sich leichter zurechtfinden wird, andererseits wirkt sie etwas gezwungen und z.T. sogar un-originell, etwa in den End Note, die in einigen Passagen eine Eins-zu Eins-Kopie ist. Auch die Definition of Workflow wirkt etwas gezwungen.

In Abgrenzung zum "Official" Kanban Guide der Kanban University ist erkennbar, dass die jeweiligen Verfasser jeweils unterschiedliche Elemente für wichtig oder verzichtbar gehalten haben. Während z.B. im "Official" Kanban Guide Aufbau und Nutzung eines Kanban-Boards einen grossen Platz einnehmen, fehlen sie in The Kanban Guide völlig. Das macht einmal mehr die Gestaltungsoffenheit von Kanban deutlich (die dann allerdings mit den Mindestvorgaben der Verfasser kollidiert).

Genau die Offenheit an dieser Stelle, durch die klar wird, dass Kanban zwar in Form eines Boards mit Kartenoder Kacheln dargestellt werden kann, aber keinerswegs dargestellt werden muss, ist übrigens eine, die grossen Teilen der Kanban-Community fehlt (Alternativen sind Ampelfarben, Kontroll-Charts, Kummulative Flussdiagramme, etc.). Alleine in dieser Hinsicht ist Vacantis und Colemans Guide eine wertvolle Ergänzung.

Auffällig ist ausserdem, dass ihr Regelwerk nochmal kürzer und komprimierter ist als die von Scrum und der Kaban University. Einschliesslich Inhaltsverzeichnis umfasst er nur neun Seiten. Aufgrunddessen kann man ihn auch ohne grossen Aufwand als Ergänzung zum nur unwesentlich längeren Guide der Kanban University benutzen, alleine um verschiedene Blickwinkel auf das Thema Kanban zu bekommen, dass sich mit einem Dokument alleine kaum abbilden lässt.

Unter den agilen Frameworks ist LeSS (Large Scale Scrum) vermutlich das mit der kuriosesten Entstehungsgeschichte. Ursprünglich entwickelt um das eigentliche Scrum ohne inhaltliche Veränderungen in Skalierungs-Kontexte übertragen zu können, haben sich seine Urheber gegen 2017 entschlossen, sich vom original-Scrum abzukoppeln und ihre eigene, inhaltlich abweichende Version zu entwickeln. Diese Entwicklung ist seit Juli 2024 abgeschlossen, es gibt jetzt einen "LeSS Scrum Guide".

• Scrum Guide (offizielle Version)
  
• Scrum Guide (LeSS Version)

Die Abweichungen zum offiziellen Scrum Guide lassen sich dabei in zwei Kategorien einteilen: zum einen sind es Themen, zu denen die LeSS-Erfinder Craig Larman und Bas Vodde eine andere Meinung haben als die Scrum-Erfinder Jeff Sutherland und Ken Schwaber, zum anderen sind es redaktionelle Änderungen, die den formalen Aufbau des Scrum Guides (Reihenfolge und Gruppierung der Themen) verändern, inhaltlich aber alles beim Alten lassen.

Bei der ersten Kategorie, den inhaltlichen Abweichungen, ist vor allem das (Development-) Team zu nennen. Aus dem offiziellen Scrum wurde es 2020 entfernt und durch "the Developers" ersetzt, um zu verhindern, dass ein Teil-Team innerhalb des Scrum Teams entsteht, dem Product Owner und Scrum Master nicht angehören. LeSS geht in die andere Richtung - diese beiden Rollen sind hier ausserhalb der Teams auf einer übergreifenden Ebene (und nehmen dadurch z.B. auch nicht an den Retrospektiven teil).

Die zweite wichtige Abweichung ist das Zielbild: im offiziellen Scrum findet sich seit 2020 das übergreifende Product Goal, zu dessen Eigenschaften gehört, dass es erreicht und abgeschlossen werden kann (es kann danach ggf. durch ein neues ersetzt werden). Abweichend davon gibt es in LeSS die Product Vision, die deutlich abstrakter ist. Als Folge dessen ist ein abschliessendes Beenden der Arbeit am Product Backlog hier ausdrücklich nicht vorgesehen (und wird sogar explizit ausgeschlossen).

Die dritte Abweichung dreht sich um das Backlog Refinement. Im offiziellen Scrum ist es eine durchgehend stattfindende Tätigkeit, deren Anlass, Umfang und Teilnehmer nicht erwähnt werden. In LeSS ist es abweichend davon als optionales Meeting beschrieben, einschliesslich der Teilnehmer (Scrum-Rollen und ggf. Stakeholder), des Ablaufs und des möglichen Umfangs (maximal 10 Prozent des Sprints, eine Regel, die 2020 aus dem offiziellen Scrum Guide entfernt wurde).

Darüber hinaus gebt es verschiedene weitere, eher abstrakte Abweichungen. Beispielsweise enthält das Product Backlog im offiziellen Scrum "Work for a complex Problem", in LeSS dagegen "Ideas for incrementally creating a Product"; Scrum basiert laut offiziellem Scrum Guide auf "Empiricism and Lean Thinking", laut LeSS-Scrum Guide dagegen nur auf "Empiricism"; die Definition of Done ist offiziell ein Committment, in LeSS dagegen ein Agreement. Den meisten Lesern dürfte das kaum auffallen.

Die zweite Kategorie der Abweichungen des LeSS-Scrum Guide zum offiziellen Scrum Guide sind die redaktionellen Änderungen. Der Sprint steht nicht mehr im Abschnitt der Events (Meetings) sondern hat einen eigenen Abschnitt, die drei im Sprint Planning zu beantwortenden Fragen sind nicht mehr nummeriert, etc. Das Ziel ist vermutlich eine bessere Lesbarkeit und Verständlichkeit, erklärt werden die Gründe für diese Neuformatierung nicht näher.

Soviel zum Inhalt, als nächstes drängt sich die Frage auf: braucht denn irgendjemand diesen zweiten Scrum Guide? Aus Sicht der LeSS-Erfinder bestimmt, zumindest dann, wenn man ihr Framework anwendet, in dessen Rahmen mehrere Entwicklungsteams sich einen Product Owner und ein Product Backlog teilen. Aus einer Scrum-puristischen Sicht vermutlich eher nicht, alleine deshalb nicht, weil diese Skalierungs-Praktiken seit 2020 auch (optionale) Teile des offiziellen Scrum sind.

Am Ende wird jedes Unternehmen oder jedes Team selber entscheiden müssen, welchen der beiden Scrum Guides es besser findet und welchen nicht. Erfahrungsgemäss dürfte das in den meisten Fällen aber eine relativ nachrangige Frage sein. In der Praxis werden die Umsetzungen der beiden Varianten (wenn sie denn wie vorgegeben stattfinden) sich ohnehin nur durch Methoden-Experten unterscheiden lassen und sich für die Beteiligten gleich anfühlen.

Was auf jeden Fall kritisch anzumerken ist, ist, dass LeSS durch diesen neuen Guide in sich selbst inkonsistent wird. Auf der offiziellen Website LeSS.works findet sich zum Beispiel in der offiziellen Beschreibung des LeSS-Frameworks noch ein aus zwei Teilen bestehendes Planning, im LeSS-Scrum Guide sind es drei. In der Framework-Beschreibung wird von teambasierten Refinements abgeraten, im LeSS-Scrum Guide sind sie enthalten. Da muss noch aufgeräumt werden.

Zuletzt eine Beobachtung: im Abschnitt Purpose of the Scrum Guide haben die LeSS-Erfinder Larman und Vodde eine Spitze gegen Jeff Sutherland untergebracht - der offizielle Scrum Guide wird hier bezeichnet als "the Scrum Guide by Ken Schwaber". Das ist zwar nicht komplett falsch, dass Sutherland an der letzten Version nicht beteiligt war, ist offiziell bestätigt worden. Seinen Beitrag komplett unter den Tisch fallen zu lassen ist aber zumindest ungewöhnlich, wer weiss was da im Hintergrund passiert ist.

Bild: Pixabay / Mahmur Marganti - Lizenz

Es ist schon eine Zeit lang her, dass zum letzten mal ein erwähnenswertes agiles Framework erfunden wurde. Es gab zwar Versuche, die waren aber entweder nur rudimentär entwickelt (z.B. POPCORN-Flow oder FLEAT) oder lediglich Variationen bereits bestehender Frameworks (z.B. Scrum 3.0 von Scrum oder TameFlow von Kanban). Dieses hier scheint in dieser Hinsicht besser zu sein: FAST (Fluid Agile Scaling Technology), erstmals veröffentlicht im März 2021 in Form des FAST Guide. Ob es erfolgreich sein wird muss sich noch zeigen, es ist aber ausdifferenziert genug um besprochen zu werden.

Wichtig ist zunächst, dass FAST sich selbst als Zusammenfassung und Weiterentwicklung bestehender Ansätze versteht, mit dem expliziten Anspruch Scrum abzulösen. Ron Quartel, der Schöpfer des Frameworks, nennt in dessen "Origin Story" die Hauptquellen Open Space Technology und Open Allocation/Dynamic Reteaming, im FAST-Guide kommen dazu noch Dunbar-Zahl/Tribe,  Ken Schwabers Überlegungen zu Post-Scrum und Verweise auf Conway, McGregor, Lewin, Pink und andere Vordenker. Aus all diesem Input entstehen die folgenden Elemente:

Tribes und (dynamische) Teams

Die  nach FAST arbeitenden Menschen bilden einen so genannten Tribe, der zunächst bis zu 14 Mitglieder haben kann (zu grösseren Einheiten siehe unten). Der Tribe ist in beliebig viele Teams unterteilt, die sich mit jeder Iteration (siehe nächster Absatz) selbstorganisiert in der für den Moment jeweils sinnvollsten Konstellation zusammenfinden. Das kann bedeuten, dass auf diese Art Feature-Teams zustande kommen, aber auch Komponenten-Teams oder Mischtypen sind möglich. Auch ein selbstorganisierter Neu-Zuschnitt der Teams während der Iteration geht, wenn es Bedarf dafür gibt.

Iterationen und FAST Meetings

Dass es Iterationen gibt ist auf den ersten Blick eine Gemeinsamkeit mit Scrum, ungewöhnlich ist aber die kurze Dauer und die sich oft ändernde Länge: empfohlen werden zu Beginn zwei Tage, anzustreben ist der kürzeste mögliche Zeitraum. Auch die Meeting-Struktur ist minimalistisch - es gibt lediglich ein Meeting, das zwischen zwei Iterationen stattfindet und ohne vorbereitete Agenda als Open Space durchgeführt wird. Alle Planungs-, Verbesserungs- und Teambuilding-Aktivitäten sollen selbstorganisiert in diesem Termin zur Diskussion gestellt, beschlossen und eingeleitet werden.

Vier Rollen

Angesichts des bisher zu erkennenden Minimalismus ist erstaunlich, dass es bei den Rollen sogar eine mehr gibt als in Scrum. Ein Product Director stellt im FAST-Meeting seine Vision für die nächste Iteration vor, aus der der Tribe selbstorganisiert seine Arbeit ableitet, ein pro Iteration gewählter Team- oder Feature Steward übernimmt in dieser Zeit die Koordination eines Themas, ein Tribe Coach hilft dabei zu verstehen wie die Methodik gemeint ist. Alle anderen Personen gelten einfach als Tribe Member, von denen jeder an mehreren Themengebieten arbeiten können sollte.

Vier Artefakte

Drei der vier Artefakte bilden mit möglichst geringem Detailgrad den Work Breakdown ab. Release Map (gross), Feature Tree (mittel), Iteration Board (klein, als einziges Artefakt optional). Das vierte bilden die so genannten Tribe Agreements, die aber nicht etwa bestimmte Beschlüsse und Regeln enthalten, sondern lediglich beschreiben wie diese möglichst unbürokratisch zu Stande kommen. Alle vier Artefakte können und sollen regelmässig selbstorganisiert geändert werden, ohne dass im Detail festgelegt ist wann das stattzufinden hat. Hauptsache Verbesserungen finden statt, egal wie.

Skalierung

Der Anspruch von FAST ist, dass es ohne zusätzliches Skalierungsframework funktioniert, bzw. sein eigenes Skalierungsframework ist. Tribes können dazu bis zur Dunbar-Zahl von 150 Mitgliedern anwachsen ohne dass zusätzliche Rollen und Meetings benötigt werden, lediglich das FAST-Meeting wird umfangreicher. Erst oberhalb der Dunbar-Zahl muss der Tribe in mehrere geteilt werden. Alternativ können FAST-Tribes in Skalierungsframeworks wie SAFe oder Flight Level-Kanban eingebettet werden, solange diese die internen Abläufe nicht verändern.

Aber: Ist das wirklich umsetzbar?

Ja, aber. Wie oben gesagt muss man sich FAST als ein Framework vorstellen das für Teams geeignet ist die Scrum gemeistert haben und jetzt einen Schritt auf die nächste Stufe machen wollen. Das bedeutet, dass sie Produkte haben die sich durch kleine, in wenigen Tagen umsetzbare Incremente erweitern lassen. Das bedeutet, dass sie die technische Exzellenz haben die für tägliche Produktionsdeployments nötig ist. Das bedeutet, das ihre Firma ihnen alle nötigen Freiheiten gibt. Und das bedeutet, dass ihre Mitglieder nah am Ideal des Fullstack-Developers sind, der nahezu jede nötige Arbeit erledigen kann.

Um ehrlich zu sein - nur wenige Teams dürften jemals den Entwicklungsgrad erreichen der für FAST nötig ist, nicht zuletzt weil nicht alle notwendigen Rahmenbedingungen selbst beeinflussbar sind. Aber vielleicht ist das auch gar nicht immer nötig - alleine der Versuch sich in diese Richtung zu entwickeln dürfte derartig viele positive Veränderungen bewirken, dass es den Aufwand bereits wert ist. FAST wäre damit weniger ein organisatorischer Rahmen und mehr ein guter Grund um ständig an Verbesserungen zu arbeiten. Aus "agiler Sicht" bereits mehr als ausreichend.

Bild: Pixabay / 5138153 - Lizenz

Etwas überraschend rauschte gestern eine Meldung durch die agilen Filterblasen: die Kanban University hat einen neuen Leitfaden veröffentlicht, genannt "The Official Guide to The Kanban Method". Auf der einen Seite ist das begrüssenswert, inhaltlich scheint es sich um eine kompakte und hilfreiche Zusammenfassung für Einsteiger zu handeln. Auf der anderen Seite gibt es aber einige Anmerkungen und Fragen.

New to #Kanban? Get The Official Guide to The Kanban Method! Start where you are NOW and download your free copy at https://t.co/l3dAtO0kee#yeswekanban #kanbanuniversity #kanbanmethod #kanbanguide #agile #scrum #lean #collaboration #leadership #workflow #change #servicedelivery pic.twitter.com/QVTdRltMWB

— Kanban University (@KanbanUni) February 24, 2021

Um mit der wichtigsen Anmerkung anzufangen: das Dokument mag zwar vom Namen her wie ein offizielles Grundlagenwerk der Methodik erscheinen, es ist aber alles andere als das. Anders als im Fall von Scrum oder SAFe gibt es bei Kanban weder einen eindeutigen Urheber noch einen "governing Body" der sich von allen anerkannt um die Weiterentwicklung kümmert. Die Kanban University ist (polemisch gesagt) eine Gruppe von Leuten mit einer Meinung. Das macht die Inhalte des Kanban Guide nicht falsch, sie sind aber nicht vergleichbar gültig wie die des Scrum Guide.

Sachlich und fachlich ist dagegen wenig auszusetzen. Nach einer leicht haarspalterischer Überlegung ob Kanban Methode oder Framework ist folgen die Praktiken Visualize, Limit Work in Progress (WIP), Manage Flow, Make Policies Explicit, Implement Feedback Loops und Improve Collaboratively, Evolve Experimentally, es wird anhand einer Autobahn-Metapher die grundlegende Vorgehensweise erklärt und am Ende gibt es noch Ratschläge für Einführung, Board-Designs, WIP Limit-Umsetzungen, Metriken und Produktionszyklen.

Vom Umfang her ist der Kanban-Guide angenehm überschaubar geworden, er hat lediglich 14 Seiten (einmal mehr dürfte der Scrum Guide hier die Benchmark gewesen sein). Bedenkt man, dass dazu auch Deckblatt und Inhaltsverzeichnis gehören und dass Überschriften, Footer und Grafiken grossen Platz einnehmen sind es sogar noch weniger. Apropos: die grafische Gestaltung ist wie immer Geschmackssache, mit vielen Farben und Comic-artigen Grafiken ist sie aber zumindest gewöhnungsbedürftig.

Etwas verwirrend ist, dass die Kanban University jetzt zwei "Guide" genannte Dokumente hat, neben dem hier besprochenen "offiziellen" Guide auch den älteren Essential Kanban Condensed Guide, der dazu trotz seines Namens deutlich umfangreicher ist als der neue Leitfaden. Genau wie der neue lässt sich auch der alte Guide noch von der Website der herunterladen und es gibt noch keine Aussage dazu ob er weiterhin gilt oder durch seinen Nachfolger obsolet geworden ist.

Alles in allem kann man sagen, dass der "Official Guide to The Kanban Method" ein handliches und für Einsteiger sicher nützliches Dokument geworden ist, bei der die Einführung begleitenden Kommunikation währe aber etwas mehr Klarheit wünschenswert gewesen. Andererseits dürfte sich das in der näheren Zukunft problemlos nachholen lassen.

Bild: Pexels / Suzy Hazelwood - Lizenz

Manchmal gibt es diese Momente: kurz nachdem ich im Sommer 2020 die Übersicht über die Grundlagen-Dokumente von Scrum erstellt hatte wurde eine neue Version des Scrum Guide angekündigt und nachdem dieser im November veröffentlicht wurde folgten im Januar die neuen Versionen von Nexus und Scrum@Scale. Zeit für ein Update dieser Zusammenstellung. Dabei bin ich auch auf einige Feedbacks eingegangen, auf andere nicht. Mehr dazu ganz unten. Aber jetzt erstmal - auf in die Geschichte. Durch die folgenden Dokumente hat sich Scrum in seine heutige Form entwickelt:

Dieser von von den Wissenschaftlern Takeuchi und Nonaka verfasste Artikel über die Arbeit japanischer Fabrikteams ist das einzige Grundlagenwerk an dem die "Scrum-Väter" Jeff Sutherland und Ken Schwaber nicht beteiligt waren (statt Scrum wird auch noch vom "Rugby Approach" gesprochen). Aus heutiger Sicht beschreibt es noch nicht Scrum selbst sondern einige Prinzipien auf denen es beruht, u.a. crossfunktionale Teams und iterativ-incrementelles Arbeiten. Die 1990 erfolgte Übertragung des New New Product Development Game auf die IT durch DeGrace und Stahl war die Inspiration für die Entwicklung von Scrum in seinem heutigen Sinn, was Sutherland und Schwaber auch selbst betont haben.

Nachdem Sutherland und Schwaber Scrum in den ersten Jahren nur im Rahmen ihrer eigenen Software-Projekte einsetzten führte der Wunsch es bekannter zu machen zur Vorstellung durch die beiden auf der OOPSLA-Konferenz im Jahr 1995. Das Konferenz-Paper gilt als Initialzündung der weltweiten Verbreitung von Scrum, enthält aber vieles noch nicht was heute zentral ist. Umgekehrt sind noch Elemente vom Wasserfall-Vorgehen enthalten, etwa die Phasen "Pregame", "Game" und "Postgame". Anderes, wie der Sprint, das Sprint-Ziel, das Sprint Planning, das Sprint Review oder der Product Owner (noch als Leiter eines Product Management-Teams), existieren bereits. Scrum ist in dieser (und den nächsten) Versionen explizit ein Ansatz der Software-Entwicklung.

Dieses leicht despektierlich "Scrum-Plop" abgekürzte Gemeinschaftswerk einer ganzen Reihe verschiedener Autoren erwähnt zum ersten mal die Rolle des Scrum Masters, wenn auch noch als eine spezifische Form des Teamleiters, dem auch leitende und kontrollierende Funktionen zugeschrieben werden. Besonders interessant: zusätzlich zum Scrum Master wird auch ein (nicht genauer beschriebener) Coach erwähnt, der anscheinend zu dieser Zeit noch eine eigene Rolle war. Auch das 15-minütige Daily Scrum-Meeting taucht hier erstmals auf, genau wie das Commitment des Teams das Sprint-Ziel zu erreichen.

Das erste Buch über Scrum, gleichzeitig aber auch ein Werk das im Rückblick leicht wunderlich wirkt. Statt Scrum als eigenständigen Ansatz vorzustellen stellten Schwaber und Beedle in den Vordergrund, dass ein anderer methodischer Ansatz, Extreme Programming (XP), sich mit Hilfe von Scrum besonders gut umsetzen liesse. Hintergrund ist, dass XP um das Jahr 2000 herum populärer war als Scrum und die Verbindung dieser beiden Ansätze Scrum schneller bekannt machen konnte. Zusätzlich kannten und respektierten sich die Urheber von Scrum und XP (u.a. waren sie 2001 gemeinsam an der Entstehung des agilen Manifests beteiligt). Der halboffizielle Status einiger XP-Elemente in Scrum (User Stories, Story Points, Pair Programming) erklärt sich aus dieser Zeit.

In dieser Übersicht über die Scrum-Einführung in verschiedenen Unternehmen tauchen erstmals Skalierungs-Elemente auf. Zum Einen findet sich hier die Idee, dass auch die Management-Teams nach Scrum arbeiten können, zum Anderen wird hier zum ersten mal das Scrum of Scrums vorgestellt, ein wöchentliches Scrum-Meeting in dem sich Vertreter verschiedener Teams treffen um sich untereinander abzustimmen und die Arbeit an übergreifenden Themen zu koordinieren. Aus diesen Ansätzen entstand später das Skalierungsframework Scrum@Scale (siehe unten).

Im Vergleich zu den anderen Texten ein eher wenig wichtiger, es wird nicht wirklich etwas Neues hinzugefügt. Interessant ist aber, dass Ken Schwaber in ihm einen weiteren Aspekt aus dem Extreme Programming aufgreift: den Team-Raum (angelehnt an den Extreme Space, in dem alle Teammitglieder zusammensitzen). Mittlerweile aus dem offiziellen Teil von Scrum verschwunden ist er noch immer ein wichtiger Teil in vielen Umsetzungen.

Ein weiterer Artikel von Ken Schwaber, der diesesmal aber grössere Änderungen beschreibt. Das Sprint Planning wird unterteilt in Planning I (was machen wir?) und Planning II (wie machen wir es?). Im Daily werden die drei Fragen gestellt was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind. Erstmals findet am Ende des Sprints eine Retrospektive statt, die mittlerweile der zentrale Antrieb für den kontinuierlichen Verbesserungsprozess geworden ist und als das Scrum Meeting schlechthin gilt. Auch die später zum zentralen Abnahme-Kriterium gewordene Definition of Done wird hier erstmals erwähnt, allerdings noch eher beiläufig an verschiedenen Stellen im Fliesstext. Diese zentralen Änderungen tauchen dann auch 2004 in Schwabers Buch Agile Project Management with Scrum auf.

Ein Dokument das erst rückwirkend zum ersten Scrum Guide erklärt wurde, Sutherland und Schwaber veröffentlichten es zuerst unter dem schlichten Namen "Scrum". Es ist die letzte Version von Scrum in der sich Wasserfall-Elemente finden: zusätzlich zu den Sprint Plannings können langfristige "Release Plannings" durchgeführt werden und es gibt noch die Möglichkeit Integration und Testing in separate Sprints auszulagern. Auch die kontrovers benannten Rollen "Pig" (Teammitglied) und "Chicken" (Stakeholder) tauchen ein letztes mal auf. Der Scrum Master wird als helfender und coachender "Servant Leader" beschrieben, was erst 10 Jahre später zu "True Leader" geändert wurde. Mit der Festlegung, dass mehrere Teams ein gemeinsames Backlog haben können taucht ein weiterer Skalierungs-Aspekt auf.

Die letzten Wasserfall-Elemente verschwinden aus dem Scrum Guide, ausserdem alle spezifischen Bezüge zur Softwareentwicklung, womit Scrum auch offiziell auf andere Bereiche anwendbar wird. Auch die Pig- und Chicken-Rollen verschwinden. Das Grooming wird dagegen zu einem festen Bestandteil und die Rollen werden ausführlicher beschrieben als vorher. Im Wesentlichen entspricht diese Version von Scrum der die bis heute gültig ist, die späteren Änderungen sind kleiner.

Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.

Es werden Neuerungen und Ergänzungen in verschiedenen Bereichen eingeführt: die Teammitglieder sollen sich in den Daily Scrums nicht mehr nur fragen was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind, sondern auch welchen Einfluss das auf das Erreichen des Sprint-Ziels haben wird. Das (in manchen Ländern anstössige) Wort Grooming wird durch Refinement ersetzt. In diesem Zusammenhang wird es auch möglich Backlog-Einträgen den Status Ready zu geben, woraus die inoffizielle Definition of Ready abgeleitet werden kann. Die Teilung des Sprint Plannings in Planning I und Planning II wird aufgehoben, das Was und das Wie können jetzt beliebig erarbeitet werden. Eine kleinere Ergänzung kommt bei den Skalierungs-Aspekten dazu: mehrere Teams können eine gemeinsame Definition of Done haben.

Das erste offizielle Skalierungsframework von Scrum. Grundlage sind die beiden Skalierungs-Aspekte des Scrum Guide, die gemeinsame Definition of Done und das gemeinsame Backlog für Teams die an einem gemeinsamen Produkt arbeiten. Da gleichzeitig vorgegeben ist dass es nur einen Product Owner für ein Backlog geben darf wird daraus abgeleitet, dass der auch für alle derartigen Teams zuständig ist. Weitere Elemente sind die Aufteilung der Scrum-Meetings in jeweils einen übergreifenden und einen teamspezifischen Teil und die zusätzliche Mitgliedschaft von Experten und ausgewählten Teammitgliedern in einem übergreifenden Integration-Scrum Team, dass den anderen Teams dabei hilft sich selbst zu koordinieren. Ein sehr ähnliches, halboffizielles Framework ist Large Scale Scrum (LeSS).

Die "Scrum-Werte" Respekt, Commitment, Fokus, Offenheit und Mut werden in den Scrum Guide aufgenommen. Das ist keine vollständige Neuerung, da sie bereits 2001 im Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle enthalten waren. Ihre Wiedereinführung ist der bisher prominenteste Fall einer Scrum-Regeländerung die auf Wünsche aus der Anwender-Community zurückgeht.

Neben verschiedenen redaktionellen Änderungen gibt es drei grössere: die berühmten drei Fragen im Daily Scrum sind jetzt optional, der Scrum Master bewegt sich mehr Richtung Coach, da er nicht mehr für die Einhaltung der Scrum-Regeln sorgt sondern deren Verständnis fördert, und zuletzt muss in jeden Sprint mindestens eine Massnahme zur Verbesserung der eigenen Arbeitsweisen aufgenommen werden.

Das übergreifende Integration Team ist selbst kein Scrum Team mehr, um konkurrierende Mitgliedschaften zu vermeiden, es funktioniert jetzt eher wie ein um externe Experten erweitertes Scrum of Scrums. Darüber hinaus gibt es redaktionelle Änderungen, unter anderem um klarer herauszustellen, dass der Nexus Guide an den Scrum Guide angelehnt ist und nicht zu ihm in Widerspruch stehen kann.

Eine vergleichsweise kontroverse Neuerung. Anders als der oben erwähnte Nexus-Ansatz geht Scrum@Scale davon aus, dass das eigentliche Scrum Framework nur für einzelne Teams gedacht ist und nicht für grössere Organisationen. Skalierung funktioniert daher in diesem Modell nicht durch die Gruppierung von Teams um Backlogs und Product Owner sondern dadurch, dass es zwar übergeordnete Hierarchie-Ebenen gibt, diese aber aus Delegierten der jeweils nächstunteren Ebene bestehen, die sich auch als Scrum Teams organisieren. Dabei gibt es zwei parallele Hierarchien: die Scrum of Scrums, Scrum of Scrum of Scrums, etc. für die Scrum Master und die gleichartig gestaffelten Meta-Scrums für die Product Owner. Auf diesen höheren Ebenen entstehen auch die neuen Rollen des "Scrum of Scrums Master" und des "Chief Product Owner" (samt deren Steigerungen).

Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.

Je nach Betrachtung eine der umfangreichsten Änderungen überhaupt oder lediglich eine grundlegende redaktionelle Überarbeitung. Die offensichtlichste Neuerung ist die Einführung des Produktziels, an dem sich das Product Backlog ähnlich ausrichtet wie das Sprint Backlog am Sprint Ziel. Das Planning besteht jetzt aus drei Teilen, die den Fragen Warum, Was und Wie entsprechen. Die drei Fragen im Daily Scrum sind völlig verschwunden. Dass Teams mit gemeinsamem Product Backlog auch einen gemeinsamen Product Owner haben müssen ist jetzt auch explizit beschrieben. Um den Eindruck konkurrierender Mitgliedschaften zu vermeiden gibt es innerhalb des Scrum Teams kein Entwicklungsteam mehr sondern nur noch Entwickler. Durch klarere Formulierung und Strukturierung ist diese Version mehrere Seiten kürzer als die letzte, dazu kommen angepasste Begrifflichkeiten, etwa True Leader statt Servant Leader.

Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt.

Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt. Darüber hinaus gibt es redaktionelle Änderungen und angepasste Begrifflichkeiten, beides mit dem Ziel, dass es genau wie bei der letzten Version des Scrum Guide zu einem geringeren Umfang und klareren Formulierungen kommen soll.

---

Natürlich gibt es noch weitere Quellen die wertvoll für das Verständnis von Scrum sind, vor allem in Buchform. Von Schwaber und Sutherland sind das vor allem die ikonisch benannten Titel Software in 30 Days und The Art of Doing Twice The Work In Half the Time, es gibt Scrum and XP from the Trenches von Henrik Kniberg, Agile Product Management with Scrum von Roman Pichler, die Bücher von Mike Cohn, die Bücher von Craig Larman und Bas Vodde, den EduScrum Guide von Willy Wijnands und viele mehr. Sie alle haben Scrum aber nicht verändert sondern beschreiben lediglich seine Anwendungsmöglichkeiten und vermitteln bewährte Techniken und Praktiken, weshalb sie keine Grundlagen-Dokumente im eigentlichen Sinn sind (lesenswert sind sie natürlich trotzdem).

Zum Feedback zu dieser Seite

Einige Worte zu dem Feedback das ich angenommen oder nicht angenommen habe: neu in der Liste ist Scrum in Church, ausserdem auch die Übersicht über die einzelnen Versionen von Nexus und Scrum@Scale, statt wie bisher nur auf die jeweils neueste Version zu verlinken. Da die jeweiligen Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide inhaltlich zusammenhängen macht das Sinn.

Nicht aufgenommen habe ich dagegen Large Scale Scrum (LeSS), Scrum 3.0 und die Scrum-Varianten aus SAFe und Disciplined Agile (DA). Bei LeSS und Scrum 3.0 weil sie nichts Wesentliches hinzufügen was es nicht bereits von Schwaber und Sutherland gibt, bei SAFe und DA weil sie Scrum so stark beschneiden, dass das Ergebnis mit dem Original nur noch eingeschränkt zu tun hat.

Weiteres Feedback ist jederzeit willkommen, spätestens zusammen mit den nächsten Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide gibt es dann auch von dieser Seite eine neue Version in die es gegebenenfalls eingearbeitet wird.

Grafik: Wikimedia Commons / Huluvu424242 - CC BY-SA 4.0

Nach drei Jahren ist es wieder soweit, der Scrum Guide hat ein Update erhalten. Nachdem im Vorfeld lediglich bekannt war, dass die neue Version kürzer werden würde als die alte, gab es gespannte Neugier auf das was wegfallen würde und das was dazukommt. Das Warten hat ein Ende, schauen wir uns an wie es gekommen ist.

Die offensichtlichste Neuerung dürfte das Produktziel sein, dass jetzt Teil des Product Backlogs ist. Im weitesten Sinn vergleichbar mit der Produktvision beschreibt es das langfristige Ziel auf das das Scrum Team hinarbeitet und auf das sich das gesamte restliche Product Backlog ausrichten soll. Es wird auch klar herausgestellt, dass es nur ein einziges Produktziel geben soll, womit auch die Hauptmotivation seiner Einführung klar sein dürfte - zusammengewürfelte Sammelsurium-Backlogs sollen unmöglich gemacht werden.

Bei den Rollen gibt es keine wirklichen inhaltlichen Änderungen, allerdings wurden vor allem beim Scrum Master Formulierungen so geändert, dass bestimmte (Fehl-)Interpretationen nicht mehr möglich sind. Es ist jetzt noch deutlicher, dass er nicht nur für das Team zuständig ist sondern für die gesamte Organisation und deren Weiterentwicklung in Richtung Agilität. Zum ersten mal ist er nicht mehr dafür zuständig Impediments selbst zu beseitigen, er muss nur noch dafür sorgen, dass irgendjemand es tut. Und seine Rolle in der Retrospektive ist jetzt deutlich weniger dominant formuliert. Angepasst wurde auch ein Grenzwert: statt 11 soll ein Scrum Team nur noch bis zu 10 Mitglieder haben.

Bei den Meetings hat sich vor allem das Planning in seinem Ablauf verändert. Neben die Phasen in denen der Umfang und die Art der Umsetzung diskutiert werden (früher Planning I und Planning II) tritt eine vorgelagerte dritte (bzw. der neuen Reihenfolge nach erste) Phase in der die Sinnfrage nach dem Zweck des Sprints gestellt und mit dem Sprintziel beantwortet wird. Ebenfalls erwähnenswert: die seit 2017 ohnehin nicht mehr verpflichtenden drei Fragen sind jetzt endgültig aus der Beschreibung des Daily Scrum verschwunden.

Eher für den englischen Sprachraum von Bedeutung dürfte das Ersetzen des Begriffs Self-Organizing durch Self-Managing sein. Die Intention einer klareren Betonung der Selbstbestimmung ist klar, im Deutschen dürfte diese Differenzierung aber kaum einen Unterschied machen¹. Auch die Unterscheidung zwischen Role (aus dem Scrum Guide entfernt), Responsibility und Accountability dürfte in Deutschland nur von akademischem Interesse sein.

Zuletzt kommen noch verschiedene redaktionelle Änderungen dazu, zum Teil in Form von klareren Formulierungen, etwa bei den Artefakten Product Backlog, Sprint Backlog und Increment, von dem z.B. jetzt klarer ist, dass es (zum Teil) auch vor Sprintende geliefert werden kann, etwa im Rahmen von Continuous Delivery. Gleichzeitig wurden an einigen Stellen unnötig detaillierte Beschreibungen entfernt, der offensichtlichste Fall dafür dürfte der Sprint-Abbruch sein, der von einem Absatz auf eine Zeile zusammengeschrumpft ist.

Fazit: mit dem Produktziel gibt es eine grosse Änderung die Scrum noch einmal in die richtige Richtung schieben kann, alleine dafür hat sich das Update gelohnt. Der Rest ist gut aber nice to have. Mal sehen wie lange es bis zum nächsten Update dauert.

¹Nachtrag: nach einigen Diskussionen zu dem Thema - ja, der 2017er Scrum Guide sagte "Self-organizing teams choose how best to accomplish their work" während der 2020er Scrum Guide sagt "Scrum Teams are [...] self-managing, meaning they internally decide who does what, when, and how." Wie oben gesagt, die Intention einer klareren Betonung der Selbstbestimmung ist klar, einen Paradigmenwechsel erkennt man hier aber vor allem dann wenn man unbedingt einen erkennen will. Auch in der 2017er Version war die Erstellung der (Sprint-)Ziele schon etwas was das Scrum Team selbst gemacht hat.

Bild: Pxfuel - Lizenz

Update 05.02.2021: da es neue Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide gibt, gibt es auch eine neue Version dieser Seite.

---

Scrum ist sich selbst in einer Hinsicht sehr treu: es findet ein kontinuierlicher Verbesserungsprozess statt, in dessen Rahmen seine Regeln ständig überarbeitet, ausdifferenziert aber zum Teil auch wieder verschlankt werden. Da dieser Prozess seit über 30 Jahren anhält ist es nicht immer einfach nachzuverfolgen was zu welchem Zeitpunkt hinzugefügt oder verändert wurde. Dem kann abgeholfen werden - hier sind die wichtigsten Grundlagenwerke auf denen das Scrum-Framework beruht und die es immer weiter entwickelt haben:

1986: The New New Product Development Game (Hirotaka Takeuchi, Ikujiro Nonaka)

Bild: Wikimedia Commons / Richard Bartz - CC BY-SA 2.5

Separate Skalierung für Scrum Master und Product Owner

Fraktaler Aufbau

Querschnittsteams

Jedes Team ist ein Scrum Team, auch ausserhalb der Produktentwicklung

So weit, so gut ...

Bild: Wikimedia Commons / Quintin Smith - CC BY 2.0

• Daily Scrum

  Die drei Fragen sind jetzt optional. Die neue Formulierung heisst "The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based". Damit wird offiziell was viele Teams ohnehin schon machen und was ich bereits bei einigen Teams eingeführt habe. Letztendlich wird hier ein Auseinanderklaffen von Theorie und Realität repariert. Wenn von den drei Fragen abgewichen wird um Status-Reporting und Kalenderverlesung zu vermeiden wird es von jetzt an weniger Diskussionen geben.

• Sprint Backlog

  Ein ganz anderer Fall. Die neue Formulierung heisst "The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting". Auch das ist nicht völlig neu, an vielen Boards gibt es bereits Kaizen-Lanes. Allerdings sind derartige Boards bisher eher in der Minderheit. Dass es ab jetzt offizieller Teil von Scrum ist wird für viele Diskussionen sorgen. Und ungeachtet der Tatsache, dass es Sinn macht den ständigen Verbesserungsprozess zu verankern -  wie passt das mit dem (fachlichen) Sprintziel zusammen? Da kann man auf die sich herausbildenden Practices gespannt sein.

Bild: Pixabay / Geralt - Lizenz

Alles neu macht der Januar. Das gilt für diese Seite (Feedback zum neuen Design bitte über das Kontaktformular an mich), es gilt aber auch für die Welt der agilen Methoden, Frameworks und Regelwerke. Seit einigen Wochen kursiert eine Version 0.9 eines Kanban-Guide in der Community, dessen Veröffentlichung durch die Lean Kanban University unmittelbar bevorstehen soll [Update 28.07.16: ist mittlerweile offiziell veröffentlicht, hier ist der Link]. Zeit für einen näheren Blick.

Zunächst das Offensichtliche: Kanban ist nach Scrum der zweite grosse Ansatz der agilen Produkt- und Prozessentwicklung, hat aber nicht einmal in Ansätzen einen vergleichbaren Bekanntheitsgrad und kommerziellen Erfolg. Der Kanban Guide [Update: es hat sich tatsächlich der wunderliche Name "Essential Kanban Condensed Guide" durchgesetzt] ist anscheinend Teil der Bemühungen diesen Rückstand aufzuholen, genau wie die Lean Kanban University (als Entsprechung der Scrum Alliance) und deren Trainings- und Zertifizierungs-Programme.

Es liegt daher nahe den neuen Kanban Guide mit dem Scrum Guide zu vergleichen. Die als erste ins Auge springende Gemeinsamkeit ist dabei der Umfang: genau wie die Scrum-Begründer Ken Schwaber und Jeff Sutherland haben auch David J Anderson und Andy Carmichael ihr Werk kurz gehalten, die im Moment kursierende Version ist mit 25 Seiten angenehm überschaubar [Update: da ist zwischen Version 0.9 und Version 1.0 einiges passiert, es sind jetzt fast 50 Seiten, mit Anhängen fast 90 (!)].

Eine halbe Gemeinsamkeit gibt bei der Wertebasierung. Während die Scrum-Werte keinen offiziellen Status haben [Update 07.11.16: mittlerweile sind auch die Scrum-Werte offiziell] stehen die Kanban-Werte ganz am Anfang des Dokuments. Im Einzelnen sind es Transparency, Balance, Collaboration, Customer Focus, Flow, Leadership, Understanding, Agreement und Respect. Schön, dass sich in diesen Werten die Eigenheiten von Kanban wiederfinden: vor allem Flow und Balance passen hier sehr gut (und bilden einen sichtbaren Kontrast zu den Iterations-basierten Scrum-Werten Committment und Courage).

Ein klarer Unterschied zu Scrum ist die Aufführung von Praktiken, im Einzelnen Visualize, Limit Work in Progress, Manage Flow, Make Policies Explicit, Implement Feedback Loops und Improve Collaboratively, Evolve Experimentally. An dieser Stelle bewegt sich die hier beschriebene Variante von Kanban weg von einem offenen Framework (wie Scrum eines ist) und hin zu einer Prozessanleitung. Besonders bei der Praktik Implement Feedback Loops ist das auffällig, hier werden gleich sieben verschiedene Meetings definiert in denen Feedback stattfinden soll.

Ebenfalls eher in eine deskriptive Richtung gehend sind die Anleitung für die Kanban-Einführung in Unternehmen, der so genannte Systems Thinking Approach to Introducing Kanban (STATIK), und der Kanban Litmus Test genannte Maturity Check. Auch die Empfehlung der zwei nach Möglichkeit zu verwendenden Metriken Cumulative Flow Diagram und Run Chart (anscheinend eine Abwandlung eines Control Charts) ist relativ spezifisch.

Eine Gemeinsamkeit mit Scrum findet sich zuletzt wieder bei den Rollen, die erkennbar aus dem anderen Framework übernommen wurden. Der Scrum Master heisst hier Service Delivery Manager, Flow Manager, Delivery Manager oder Flow Master, der Product Owner heisst Service Request Manager, Product Manager, oder Service Manager (es sind jeweils mehrere Möglichkeiten angegeben). Einfache Teammitglieder werden nicht erwähnt, scheinen also keinen methodentypischen Namen zu haben.

Das Fazit: gemischt. Zwar ist Kanban mit diesem Dokument jetzt klarer definiert und beschrieben (zumindest für alle die der Lean Kanban University Deutungshoheit zugestehen) was Einführung und Umsetzung erleichtern kann. Auf der anderen Seite war es immer die Stärke von Kanban, dass es als "Open Source-Bewegung" sehr offen und frei in der Umsetzung war, das könnte hier verloren gehen. Positiv gesehen: immerhin scheint es den Willen zu geben den Umfang gering zu halten [Update: wie gesagt, Version 1.0 hat mit Anhängen fast 90 Seiten (!)]. Mal sehen wie es sich entwickelt.