Samstag, 30. Januar 2016

Kommentierte Links (IX)

  • Harvard Business Review: The New New Product Development Game

  • Bis heute kommt es immer wieder vor, dass ich auf meinen Projekten Manager treffe, die der Meinung sind, dass Scrum und ähnliche Methoden "neumodische Erscheinungen" wären, die sich "erstmal bewähren müssen". Ich weise diese Leute dann in der Regel auf diesen Artikel von Hirotaka Takeuchi und Ikujiro Nonaka hin, den die beiden vor ziemlich genau 30 Jahren im Harvard Business Review veröffentlicht haben (Ausgabe Januar 1986). In ihm wurde der Begriff Scrum zum ersten mal für die Beschreibung von Arbeitsprozessen benutzt und in ihm finden sich bereits die grundlegenden Ideen, auf denen agile Methoden heute beruhen: Built-in instability (heute würde man sagen Agilität), Self-organizing project teams, Overlapping development phases, “Multilearning”, Subtle control, Organizational transfer of learning. Eine erstaunlich lange Geschichte für eine neumodische Erscheinung.

  • DZone: 38 Scrum Master Interview Questions To Avoid Imposters

  • Ich habe es selber schon mehrfach schmerzlich erleben müssen - gute Scrum Master zu finden ist schwer, und immer wieder werden Stellen an völlig ungeeignete Personen vergeben (nicht zuletzt aufgrund von vom Thema überforderten Recruitern und Personalern). Dieser Interview-Leitfaden hier hätte einigen Projekten die ich kenne einen Großteil ihrer Probleme von vornherein erspart, da er die falschen Kandidaten sicher ausgesiebt hätte. Natürlich gibt es aber auch einen Haken: Stefan Wolpers, der Verfasser der 38 Fragen, liefert nämlich die Antworten nicht mit. Ohne Kenntnis und Verständnis der Methode kann der Interviewer also nur bedingt etwas mit ihnen anfangen. Nochmal umgekehrt betrachtet ist das aber wieder gut, den wer keine Ahnung von Scrum hat sollte auch keine Einstellungsinterviews mit Scrum Mastern führen.

  • Dave Smith: A developer’s guide to interviewing

  • Das Ganze von der anderen Seite betrachtet. In einem Job-Interview sollten nicht nur die Vertreter der einstellenden Firma Fragen stellen, sondern auch derjenige der sich für den Job interessiert - und die Fragen von Dave Smith würden einige Firmen die ich kenne nicht gut dastehen lassen. Was mir besonders gefällt: er fragt nicht nach der eingesetzten Methode (behaupten, dass man Scrum macht kann jeder) sondern versucht aus Informationen über Arbeitsabläufe und Standards Rückschlüsse zu ziehen. Woher wissen die Angestellten woran sie arbeiten müssen? Wie halten sie es mit Unit Tests? Gibt es Continuous Integration? Wie ist der Bugfixing-Prozess? Und so weiter. Ein paar dieser Fragen nehme ich sicher in mein nächstes Interview mit.

  • Joshua Partogi: Scrum does not work here in Asia

  • Geschichten wie die von Joshua Partogi habe ich bereits von einigen Scrum Mastern und Coaches gehört, die in Süd- oder Ostasien unterwegs waren. Scrum wird als reine Softwareentwicklungs-Methodik gesehen, die notwendigen Änderungen im restlichen Unternehmen werden dagegen ignoriert oder verleugnet. Dazu kommen Hierarchie-Gläubigkeit, die Unfähigkeit Konflikte sachlich (oder überhaupt) auszutragen, zwanghafter Konformismus und die Verwechselung von billiger Personalbeschaffung mit billiger Softwareentwicklung. Das Ergebnis ist Cargo Cult, also etwas das irgendwie nach Scrum aussieht aber nichtmal in Ansätzen so funktioniert. Der aus meiner Sicht bemerkenswerteste Aspekt ist Partogi aber gar nicht bewusst: In vielen deutschen (und generell westlichen) Großunternehmen findet man praktisch alles was er sagt genauso wieder, weshalb die Scrum-Einführungen auch dort regelmässig kläglich scheitern. Manche Verhaltensmuster sind eben universeller als man denkt.

  • Grant Amons: Ditching Scrum for Kanban — The best decision we’ve made as a team

  • Die Überschrift sagt eigentlich bereits alles: ein Team wechselt von Scrum zu Kanban und wird glücklich. Obwohl die Scrum-Einführung vieles verbessert hatte brachte sie nämlich auch Unzufriedenheit mit sich, da regelmässig Sprint-Ziele verfehlt wurden und Aufwandsschätzungen sich als falsch herausstellten. Nach dem Wechsel gab es diese Probleme nicht mehr und alle lebten happily ever after. Spontan würden mir dazu zwei Gedanken in den Sinn kommen: Erstens - hat dieses unzufriedene Team wirklich vorher Scrum gemacht, oder war bereits die Umsetzung falsch? (Besser ausformuliert findet sich diese Frage bei Hannah Kane). Und zweitens - ist das was dort jetzt gemacht wird wirklich Kanban? Beschrieben wird es als Scrum ohne feste Sprints und ohne Retrospektive - müsste es da nicht mehr geben, etwa ein Work in Progress-Limit, einen Eliminate Waste-Grundsatz oder einen Kaizen-Prozess? Unabhängig davon kann es aber durchaus sein, dass Kanban für manche Teams besser funktioniert als Scrum, allerdings nennt Amons auch eine sehr wichtige Voraussetzung für den Wechsel: bevor man sich entscheidet Scrum wieder abzuschaffen sollte man es zuerst verstanden haben, sonst weiss man nicht was man tut (siehe dazu auch: Shuhari und Harikiri).

Dienstag, 26. Januar 2016

Jira/Confluence als Grund für Monokultur in Retrospektiven

Ironie der Geschichte: Nachdem Michael Küsters erst letzten Monat geschrieben hat, dass Retrospektiven nicht "fancy" sein müssen, war ich gestern Teil einer von ihm moderierten Retro, die einige spielerische Elemente beinhaltete, die ich so noch nicht kannte. Eine meiner Erkenntnisse: ein großer Maler/Zeichner werde ich nicht mehr. Aber unabhängig vom konkreten Einzelfall - ich bewege mich in letzter Zeit wieder zu der Ansicht hin, dass Retrospektiven zumindest ab und zu neue Elemente haben sollten um nicht zu sehr in Routinen abzurutschen. Selbst wenn eine neue Form nicht zwingend neue Erkenntnisse bringt, zumindest ist es weniger wahrscheinlich, dass eine irgendwann in Ablehnung umschlagende Langeweile entsteht.

Im Rahmen dieser Überlegung habe ich später auch mit einigen Kollegen diskutiert wie es wohl zu der häufig anzutreffenden "Monokultur" kommen kann. Einen Grund dafür hatte ich bis vor kurzem gar nicht auf dem Schirm - es ist dieser hier:


Bei etwas Überlegung ist es klar: wenn das beliebteste agile Projektmanagement-Tool (Jira/Confluence) nur ein einziges Retro-Template enthält, das dann auch noch automatisch aufpoppt sobald der Sprint geschlossen wird und das sich auch nicht mit vertretbarem Aufwand modifizieren lässt, dann ist die Versuchung sehr groß es auch genau so zu verwenden. Vor allem bei Teams die nur digital und nicht mit physischen Boards arbeiten ist die Wahrscheinlichkeit eines "machen wir immer so" sehr hoch.

Aktuell benutze ich Jira und Confluence zwar auch, das Retrospektiven-Template setze ich aber bewusst nicht ein. Während der Veranstaltung selbst benutze ich eine beschreibbare Wand, die Dokumentation erfolgt dann über hochgeladene Fotos. Das ist zwar keine Garantie für Abwechselung, aber zumindest ein vereinheitlichender Faktor fällt damit weg.

Mittwoch, 20. Januar 2016

Ein Bild sagt mehr als 1000 Worte (X)

Zum 10. Jubiläum von "Ein Bild sagt mehr als 1000 Worte" ein Klassiker. Eine der zahllosen Meme-Variationen von "2 unit tests, 0 integration tests".

Montag, 18. Januar 2016

Ist das noch Scrum oder kann das weg?

Bild: Flickr/Enrique Fernandez - CC BY 2.0
Ein immer wiederkehrendes Phänomen in Scrum ist es, dass Teams sich darüber beschweren, dass die Methode ihnen zu restriktiv und zu einengend ist. Der Zwang die User Stories immer gleich zu formulieren (Als [Rolle] möchte ich [Aktion] um [Mehrwert]), die Vorschrift, dass man nicht mehrere von ihnen gleichzeitig bearbeiten darf (Sequenzielle Abarbeitung), das Verbot digitale statt physischer Boards zu benutzen (haptische Erfahrung), die Begrenzung von Sprints auf zwei Wochen (kurze Auslieferungszeit) und viele weitere Vorgaben werden als nicht immer zielführend empfunden. Mitunter wird aufgrund solcher Regeln sogar in Frage gestellt, ob Scrum wirklich eine agile Methode ist, da es scheinbar eine Anpassung an aktuelle Aufgaben und Probleme erschweren und verhindern könnte. Diese Einwände sind zwar in gewisser Weise richtig, dennoch steckt ein Denkfehler in ihnen: keine der genannten Regeln ist wirklich ein Teil von Scrum, genauso wenig wie viele andere von denen das häufig behauptet wird.

Das tatsächliche Scrum-Regelwerk ist eher schlank. Der offizielle Scrum Guide ist je nach Formatierung lediglich zwischen 15 und 20 Seiten lang, regelt nur die wichtigsten Bereiche (drei Rollen, fünf Events, drei Artefakte und wenige grundlegende Definitionen) und lässt sonst sehr viel Freiraum. Selbst scheinbar selbstverständliche Bestandteile der Methode erwähnt er nicht einmal - z.B. findet man in ihm weder die Taskboards noch die Backlog Refinements oder das Minimum Viable Product (MVP). Das alles (genau wie die weiter oben genannten Punkte) sind optionale Erweiterungen, die sich irgendwann mal eingebürgert haben ohne verpflichtend zu sein. Wenn man es wollte könnte man sie alle weglassen ohne damit gegen die Regeln zu verstoßen, das Ergebnis würde sich immer noch mit vollem Recht Scrum nennen können. Allerdings: Nur weil man es könnte heißt es nicht, dass man es auch sollte.

Praktisch alle gängigen Erweiterungen sind nicht durch Willkür entstanden sondern das Ergebnis jahrzehntelanger Best Practices. Egal ob sie aus anderen Methoden wie Kanban, Extreme Programming und Lean Startup übernommen oder extra für Scrum entwickelt wurden, hinter ihnen steckt immer die Motivation, die Ideen von Scrum und Agile möglichst optimal in die operative Arbeit umzusetzen. An dieser Stelle setze ich nach Möglichkeit auch immer an wenn sich eines meiner Teams gegen die scheinbar restriktiven und dogmatischen Regeln auflehnt: ich biete an, in einer Diskussionsrunde darüber zu sprechen wo diese Best Practices herkommen, warum man sie übernommen hat, was sie bewirken und welche Risiken man eingeht wenn man sie fallen lässt.

In fast allen Fällen haben sich die Teams danach entschieden, ihre Vorgehensweisen doch nicht zu ändern oder sie nur minimal zu modifizieren. Ihr Problem waren in diesen Fällen nicht die Regeln selbst, sondern deren fehlende Begründung und Erklärung. Sobald diese nachgereicht wurden stieg die Akzeptanz deutlich an. Und in den wenigen Fällen in denen doch Änderungen vorgenommen wurden gab es einen wirklich guten Grund dafür.

Donnerstag, 14. Januar 2016

Charisma als Scrum Master-Eigenschaft

Bild: Wikimedia Commons/Alberto Corda - Public Domain
Ein Ergebnis vieler Diskussionen der letzten Zeit: ein Scrum Master sollte eine charismatische Person sein. Dort wo Scrum richtig implementiert ist, ist er nicht der disziplinarische Vorgesetzte des Teams, dieses sollte ihm aber trotzdem (bis zu einem gewissen Grad) freiwillig folgen. Eine Grundlage dieser Gefolgschaft - zumindest so wie wir es verstanden haben - ist das Charisma, das er in die Waagschale werfen kann um seine Teammitglieder zu begeistern und vom richtigen Vorgehen (adaptiv, iterativ, etc.) zu überzeugen. Wenn er es hat kann er seinen Job machen, denn dann werden seine Ratschläge auch angehört, angenommen und umgesetzt werden wenn man nicht völlig sicher ist was ihre Umsetzung bewirken wird. Wenn nicht wird er es schwer haben, denn Vieles im agilen Vorgehen (z. B. keine Detailplanung, keine Zeit-/Aufwandsschätzung, keine Kontrolle) erscheint zunächst widersinnig wenn man anderes gewohnt ist. Und ein zweifelndes, von seiner Ansprache nicht überzeugtes Team wird sich meistens nicht trauen neue Wege zu gehen. So weit, so einfach. Es bleibt allerdings die Frage: Charisma - was soll das sein? Als alter Geisteswissenschaftler würde ich zur Bestimmung auf denjenigen zurückgehen, der den Begriff in seiner heutigen Form festgelegt hat, auf Max Weber. Er definierte es folgendermassen:
Charisma soll eine als außeralltäglich [...] geltende Qualität einer Persönlichkeit heißen, um derentwillen sie [...] als Führer gewertet wird. Wie die betreffende Qualität von irgendeinem ethischen, ästhetischen oder sonstigen Standpunkt aus "objektiv" richtig zu bewerten sein würde, ist natürlich dabei begrifflich völlig gleichgültig: darauf allein, wie sie tatsächlich von den charismatisch Beherrschten, den Anhängern, bewertet wird, kommt es an.
Mit anderen Worten: es kommt nicht darauf an wie überzeugend und bewundernswert exzellent in seinem Tun ein Scrum Master ist (selbst wenn das häufig fälschlicherweise für Charisma gehalten wird). Er ist nur dann charismatisch, wenn sein Team ihn dafür hält. Das passiert übrigens schneller als man denken sollte - in der Soziologie geht man davon aus, dass in der westlich/europäischen Welt Charisma nicht nur bestimmten Personen, sondern auch bestimmten Ämtern zugeschrieben wird. Das gilt z.B. für religiöse Führer, aber auch und gerade für die Wirtschaft. Noch einmal Max Weber:
Beziehung zur Wirtschaft: Die Veralltäglichung des Charisma ist in sehr wesentlicher Hinsicht identisch mit Anpassung an die Bedingungen der Wirtschaft als der kontinuierlich wirkenden Alltagsmacht. [...] In weitestgehendem Maße dient hierbei die erb- oder amtscharismatische Umbildung als Mittel der Legitimierung bestehender oder erworbener Verfügungsgewalten.
Stark vereinfacht gesagt und auf das konkrete Beispiel bezogen: die Teammitglieder nehmen zunächst ganz selbstverständlich an, dass der Scrum Master überzeugend und exzellent ist - warum sonst sollte man ihm diesen Job gegeben haben? Aber - was passiert, wenn sie mit dieser Annahme falsch liegen, wenn der Scrum Master diese Erwartungen nicht erfüllt? Auch darauf gibt die Theorie eine Antwort. Ein letztes mal Weber:
Über die Geltung des Charisma entscheidet die durch Bewährung [...] gesicherte freie [...] Anerkennung durch die Beherrschten. Bleibt die Bewährung dauernd aus, [...] vor allem: bringt seine Führung kein Wohlergehen für die Beherrschten, so hat seine charismatische Autorität die Chance, zu schwinden.
Anders formuliert: der Scrum Master hat zwar zunächst einen Vertrauensvorschuss, er wird aber permanent an den ihm entgegengebrachten Vorschusslorbeeren gemessen. Zeigt sich jetzt, dass er auch nicht überzeugender und besser ist als alle anderen, dann war es das mit der freiwilligen Gefolgschaft.

Um zur Aussage und Frage vom Beginn zurückzukommen: ein Scrum Master wird nur dann als charismatisch wahrgenommen (und nur dann folgt man ihm) wenn er die Erwartungen die die Teammitglieder in ihn setzen durchgehend erfüllt. Eine Herausforderung. Um das zu können und nicht daran zu scheitern sollte er in der Lage sein Expactation Management zu betreiben. Erst indem er seinem Team vermittelt wo es hohe Erwartungen haben kann und wo nicht macht er diese erfüllbar. Zu seinem Glück ist er dafür sogar zuständig und (wenn er denn fähig ist) auch in der Lage, denn das Vermitteln von Methodenkenntnis und Rollenverständnis ist zentraler Teil seines Jobs. Letztendlich ein Zirkelschluss - durch sein (Amts)charisma kann er die Erwartungshaltung beeinflussen und diese danach auch erfüllen, woraus wieder neues Charisma entsteht. Anders als man denken könnte ist charismatisches Auftreten also keine Göttergabe sondern ein anspruchsvolles Handwerk, das man beherrschen muss wenn man in der Lage sein will das Team indirekt zu leiten.

Dienstag, 12. Januar 2016

Telefonkonferenzen

Einer von vielen Gründen gegen geografisch verteilte Teams.

Donnerstag, 7. Januar 2016

Zeitdruck und Innehalten (und Lego)

Bild: Wikimedia Commons/Powerhauer - CC BY-SA 3.0
Zum Scrum Master-Job gehören unter Umständen Scrum-Workshops, in denen die Methode mit Hilfe von Legosteinen erklärt wird: Anstelle von Software werden damit Gebäude erstellt, das "Projekt" ist auf ein bis zwei Stunden begrenzt und die einzelnen Zyklen und Meetings sind entsprechend verkürzt, sonst wird versucht so nah wie möglich am Original-Vorgehen zu bleiben (eine genauere Erläuterung gibt es hier). Das Ziel ist eine eher spielerische Vermittlung, die auch für Menschen zugänglich ist die keine vertieften IT-Kenntnisse haben. Vor diesem Hintergrund kann dieses Vorgehen sehr sinnvoll sein, allerdings würde ich bei seinem Einsatz raten mit Vorsicht vorzugehen.

Beim Lego-Scrum (und auch bei anderen Simulationsmethoden wie z.B. dem Scrum-Kochen) sollte man meiner Meinung nach zwei Risiken bedenken: Zum Einen das Problem der fehlenden "Ernsthaftigkeit" (darüber hatte ich bereits etwas geschrieben), zum Anderen sollte man sich bewusst sein, dass Scrum auf diese Weise unter einem hohen Zeitdruck stattfindet. Bei einer 90-minütigen Simulation mit drei Sprints zu je einer halben Stunde bleiben für Refinement, Planning, Daily Standup, Review und Retrospektive jeweils nur wenige Minuten. Gerade bei unerfahrenen Teams kann das dazu führen, dass so viel wie möglich davon weggelassen wird um mehr Zeit für die "richtige Arbeit" zu haben. Wird das nicht diskutiert oder korrigiert gehen die Teilnehmer möglicherweise mit dem "Erkenntnisgewinn" nach Hause, dass diese Meetings etwas sind was man streichen oder stark verkürzen sollte wenn man schneller vorankommen will. Wenn sich das einmal in den Köpfen festgesetzt hat ist es mitunter nur schwer wieder dort herauszubekommen. Und das ist nicht der einzige "Kollateralschaden" der auftreten kann.

Zu den Kernelementen von Scrum gehört nach meinem Verständnis, dass in regelmässigen Abständen der Zeitdruck von den Teams weggenommen wird. Egal wie dringend und wichtig neue Features gerade sind (und sie sind fast immer dringend und wichtig) - in festen Zyklen muss innegehalten und Abstand genommen werden. Nur wenn man aus dem Hamsterrad heraussteigt und zurücktritt kann man sich die richtigen und zielführenden Fragen stellen:
  • Ist das was wir vorhaben überhaupt technisch umsetzbar? (Refinement)
  • Ist das was wir vorhaben in der gegebenen Zeit überhaupt zu bewältigen? (Planning)
  • Sind wir noch im Zeitplan, und wenn nicht - wie gehen wir damit um? (Daily Standup)
  • Ist das was wir produziert haben wirklich das was die Benutzer wollen? (Review)
  • Ist das methodische Vorgehen das wir gewählt haben tatsächlich das richtige? (Retrospektive)
Was passiert aber wenn man sich die Zeit für dieses Innehalten nicht nimmt sondern schnellstmöglich durch die Meetings hetzt um schnell wieder an die Arbeit zu kommen? In den meisten Fällen wird man Murks als Ergebnis haben. Probleme werden nicht durchdrungen, Gedanken nicht zu Ende gedacht, Beschlüsse vorschnell gefasst und Diskussionen abgewürgt. Am Ende stehen Ergebnisse die nicht wirklich brauchbar sind.

Zurück zur Lego-Simulation. In ihrem Fall besteht ein hohes Risiko, dass die enge Zeitbegrenzung die Meetings so staucht, dass sie in der gerade erwähnten Form dysfunktional sind. Wenn dadurch aber der "Erkenntnisgewinn" geprägt ist, den die Teilnehmer mitnehmen, dann ist das sogar wesentlich schwerwiegender als im oben genannten ersten Fall. Dann entsteht nämlich der Eindruck, dass die Scrum-Regelmeetings im Zweifel nicht nur verzichtbar sondern sogar eher schädlich sind, weil ja "offensichtlich" nur halbgare und kaum brauchbare Ergebnisse in ihnen entstehen. Und wenn sich dieser Eindruck erstmal verfestigt hat, dann wird es wirklich schwer ihn zu korrigieren.

Das alles heisst nicht, dass man Lego-Scrum und ähnliche Methoden gar nicht einsetzen sollte. Es heisst aber, dass in ihnen explizit darauf geachtet werden sollte, dass die beschriebenen Fehlentwicklungen nicht eintreten. Möglich ist etwa eine Mindestdauer für Meetings, so dass es für die Teams nicht mehr möglich ist Arbeitszeit zu gewinnen indem man die Meetingzeit zusammenstreicht. Auch die Frage ob ein bis zwei Stunden wirklich für eine Simulation ausreichen kann man diskutieren (ich z.B. glaube das nicht). Und zuletzt sollten die Veranstalter in eigenen Retrospektiven regelmässig auch ihr eigenes Vorgehen überprüfen, ganz so wie sie es vermutlich selbst irgendwann mal in einer Scrum-Simulation gelernt haben.

Montag, 4. Januar 2016

Essential Kanban Condensed Guide [updated]

Bild: Pixabay / Geralt - CC0 1.0

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.