´??-ban: die Wunderpille?!´
Was macht die erfolgreichen Mixtur aus?
Welche Vorgangsweise ist empfehlenswert?
Weshalb sollten andere Methoden, Frameworks oder sonstige Strukturansätze mit Kanban kombiniert werden?
Wovon sollte besser die Finger gelassen werden?
Was lassen nahezu alle bekannten Ansätze vermissen?
Welches Vokabular ist korrekt und welches irreführend?
AUSGANGSSITUATION
DEFINITION
Erst kürzlich stellte ein sehr versierte Kollege die Frage, ob jemand Scrumban eindeutig definieren könnte. Die Antworten fielen etwas zögerlich aus. Wobei David Anderson das recht klar in der PosIT Science Fallstudie wie folgt publiziert hat:
Quelle: David A. Anderson, zitiert aus dem berühmten „blauen“ Buch
Scrumban bedeutet nicht irgendeine Mischung der beiden Methoden, indem man die Praktiken aus jeder von ihnen auswählt. Scrumban bedeutet "macht alles Kanban und wendet es in einer Umgebung an, die bereits Scrum verwendet".
Ein einfacher Test, ob ein Unternehmen versteht, inwieweit Kanban auf Scrum angewendet wird ("Scrumban"), ist die Frage, wie viele Änderungen zu ihrem Prozess sind in letzter Zeit passiert und können sie eine Zeitleiste dieser Änderungen beschreiben, die seit der "Übernahme von Scrumban" eingeführt worden sind? "Wenn sie mit einem verwirrten Blick aufsehen, dann verstehen sie wahrscheinlich das Konzept und die evolutionäre Natur von Kanban nicht.
Kanban war schon immer der "Anfang mit dem, was man jetzt tut" und der Ansatz der evolutionären Weiterentwicklung. Sie fügen Kanban zu dem hinzu, was bereits vorhanden ist. Wenn ein Scrum-Prozess schon vorliegt, dann ist Ihre Geschichte, wie so viele andere, eine Scrumban-Geschichte.
HINEINGRABEN Scrum
Mit der Anmerkung: „… macht alles Kanban und wendet es in einer Umgebung an, die bereits Scrum einsetzt" sind wir beim herausfordernden Punkt als auch bei dem erwähnten Grundlagenartikel.
Was ist denn nun dieses ALLES Kanban? Bevor wir uns einer Antwort zuwenden, sollten wir uns vorher nochmals dem IST widmen. Also Scrum in diesem Falle.
Scrum ist ein agiler Rahmen für die Verwaltung und Durchführung komplizierter und/oder komplexer Produktentwicklungen. Ursprünglich wurde es für Software-Entwicklungsteams erschaffen. Die Methodik kann in vielen Fällen als Mittel der Zusammenarbeit eingesetzt werden.
Im Kern ist Scrum ein leichtgewichtiges und flexibles Framework, das Teams ermöglicht, effektiv zusammenzuarbeiten und zu kooperieren. Das Framework basiert auf einer Reihe von Rollen, Artefakten und Zeremonien, die Teams dabei helfen sollen, iterativ und inkrementell zu arbeiten und dem Kunden bei jedem Schritt einen Mehrwert zu liefern.
| Events |
Artefakte |
| The Sprint |
Product Backlog |
| Sprint Planning Meeting | Sprint Backlog |
| Daily Scrum | Increment |
| Sprint Review | -- |
| Sprint Retrospective | -- |
ABGLEICH Scrumban
Um uns den Abgleich zu erleichtern, liste ich die Strukturelemente von Kanban gesamthaft in Stichworten auf und prüfe auf Verträglichkeit oder Widerspruch mit Scrum:
| Kanban |
Scrum |
Detail |
| KERNPRAKTIKEN |
|
|
| Visualisierung des Arbeitsablaufs | Auch wenn der Ablauf im Sprint selbst meist klar ist, sind
Einzelschritte in der Visualisierung hilfreich. Die Visualisierung ist
grossteils schnell als Vorteil akzeptiert. | Die Ergänzung auch sonst selten dargestellter Arbeit wie offene Punkte
oder Wartung erleichtern die Erfassung des gesamten Umfangs und damit
dessen Steuerung. Herauszustreichen ist ein dadurch entstehender
wesentlicher Vorteil von Kanban durch die unterschiedliche Darstellung
unterschiedlicher Arbeitstypen und ggf. deren Trennung in mehrere
Swimlanes
(Prozessablauflinien).
Auf diese könnten dann auch
unterschiedliche, jeweils angepasste Regeln einwirken. Vollständig
negiert erlebe ich bis heute die Visualiserung der Schritte vor dem
Zustandekommen des Sprint- Backlogs samt der entsprechenden
Arbeitsvorbereitung und -auswahl wie Prototypen für Machbarkeitsstudien
oder den Aufbau validierten Lernens, soferne diese Tätigkeiten auch
vorab stattfinden. (Falls ja, würde es sich dabei NICHT um den vielfach
strapazierten Begriff „Upstream" handeln.)
Die gesamte Struktur
aller Sprints und Auslieferungen sowie ein Roadmapping kann ebenso
Gegenstand der Visualisierungen sein. Zusage- sowie Übergabepunkte wären
damit eindeutig festgehalten (was auch bei der Kernpraktik
„Rückkopplung" nochmals angeführt wird).
Von Vorteil wäre auch die Abbildung der Artefakte und insbesondere der Abhängigkeiten.. |
| Begrenzung gleichzeitiger Arbeit | Ist per se durch die Methode Scrum MITt dem Sprint und FÜR diesen gegeben. | Das ´Hineinziehen´ der Arbeit in den Sprint entspricht einer Arbeitsbegrenzung für die Dauer des Sprints. Fallweise ist es bei geteilten externen Diensten wie „Test" sinnvoll, zusätzlich spalten-bzw. zellenweises Limit anzubringen. |
| Optimierung Arbeitsfluss | Wird durch die Visualisierung unterstützt | De facto ist es nicht nur eine Unterstützung – es ist vielmehr sogar eine Ermöglichung durch die Visualisierung zusammen mit der Betrachtung des Arbeitsflusses von rechts nach links. |
| Regelklarheit | Definitions of Ready (DoR) und Definitions of Done (DoD), Teamvereinbar-ungen, Abfolgen bzw. Details von Treffen u.ä. sind Usus | Kanban animiert darüber hinaus nur noch, all diese Regeln auch zu visualisieren. (Um ein wenig vorzugreifen, so zeigt sich hier im Besonderen auch der Nutzen der zusätzlichen Verwendung von Obeyas zur Sammlung aller relevanten Fakten in der Arbeitsumgebung.) |
| Rückkopplung | Metriken wie Storypoints oder Velocity sind Standard. Ebenso die Gelegenheiten zum Austausch mit den Events. | Bei der Anwendung von Kanban könnte die vollständige Durchlaufzeit bis zur Fertig-stellung eines Produkts nach Inkrement n und/oder die initiale Fehlerquote sowie Betrachtungen von Blockern von Vorteil sein. Das würde auch die Definition des Zusage- und Lieferpunkts nach sich ziehen, wie schon oben erwähnt. Das ist für die Messungen essentiell. Wiederum ist die Visualisierung von möglichst allen Vereinbarungen angeraten und hiermit auch ein Thema für ein Obeya (zentrale visuelle Informationsdrehscheibe).
(Weitere Metriken würden mehr den Charakter eines Services (Dienstes) widerspiegeln und dadurch die Transformation zu einem reinen Kanban andeuten.) |
| Kontinuierliche Verbesserung | Ganz besonders zeigen erfreulicherweise agile Vorgehensweisen (im Gegensatz zur Projektkultur) den sinnvollen Einsatz von Retrospektiven und/oder Reviews mit diversen Schwerpunkten | Alle Vorkehrungen hat Kanban dazu in den Kadenzen geregelt. Die Vorgehensweise von Scrum kann dahingehend erweitert werden oder in diesen aufgehen oder der aktuelle Aufbau ist auch so völlig ausreichend. Visualisierung der Arten und Eirnichtungen sowie der Abfolgen sind auch hier sehr empfehlenswert. Verständnis ist überall Trumpf. |
| PRINZIPIEN | | |
| Einbeziehung und Verständnis Kunden | Die Rolle des Product Owners sollte genau diese Interessen wahrnehmen | Bei konsequenter Umsetzung könnte dem Kunden darüber hinaus der volle Zugang zu allen Visualisierungen gewährt werden. Selbst dann, wenn der Product Owner seine Rolle ausübt, kann der Kunde von Zeit zu Zeit zusätzlich die Nase ins Geschehen stecken. Transparenz ist die Grundstufe für Vertrauen, persönlicher Austausch die Krönung bei der Gestaltung nachhaltigen Nutzens. |
| Steuern der Arbeit | Bei Scrum ist immer der Teamgedanke im Vordergrund. | Bei Kanban liegt der Fokus auf der Arbeit.
Empfohlen wird die Klarstellung, wie hier vorgengangen wird und was im Vordergrund steht. Beide Sichtweisen haben ihre Pros und Contras. Ggf. werden unterschiedliche Arbeitstypen auch in dieser Hinsicht unterschiedlich gehandhabt. |
| Weiterentwickeln | S. Rubriken „Rück-kopplung" und „Kontinuierliche Verbesserung". | Das ist ein Aspekt der schon oben behandelten Rubriken aus „Rückkopplung" und „Kontinuierliche Verbesserung". |
| Beginnen mit dem IST-Status | Scrum gibt klar vor, wie Scrum funktioniert. Trotzdem passen viele Unternehmen insbesondere Rollen an und regeln individuell Längen der Sprints. | Kanban nimmt genau das, was da ist und wie es da ist. Machen Sie auch das sichtbar, was schon geändert ist. |
| Veränderungen nur evolutionär und schrittweise | Eine dezidierte Vorgehensweise gibt es dazu nicht, weil Scrum so funktioniert, wie es vorgeben ist und die Bandbrete möglicher Maßnahmen äusserst gering ist. | Kanban legt sehr viel Wert auf die Art der Veränderungen, um eine praktikable Nutzung jederzeit zu gewährleisten. Beide Ansätze stehen keineswegs im Widerspruch. Vielmehr geben die Erweiterungen durch „Scrumban" Anlass möglicher Adaptierungen im Stile von Kanban. |
| Situatives Führen | Agile, moderne, adäquate Führung ist ein Riesenthema bei Scrum. | Alle Ausführungen von Scrum passen zu dem Ansatz von Kanban. Letzteres wirft lediglich den Blick auf mehrere Kontexte der Führung, welche unterschiedliche Personen/Rollen bei unterschiedlichen Gelegenheiten zur Übernahme bzw. Ausübung der situativen Führung auf allen Ebenen in Frage kommen und wie eine sinnvolle Umsetzung ist. |
Summa summarum behaupte ich, sehr viele Vorteile durch einen Scrumban-Ansatz zu identifzieren. Die Integration von Kanban (und erst mit Obeya) erfolgt leicht und kann jederzeit weiter ausgebaut werden.
Sämtliche Events und Artefakte werden entweder visualisiert oder sind einfach im Ablauf integriert.
IMPLEMENTIERUNG Scrumban
Wenn wir uns nun die vielen Optionen aus obiger Tabelle betrachten, so drängt sich sich der Wunsch nach einer angepassten Standard-Implementierungsanleitung STATIK von Kanban für Scrumban auf.
| Kanban STATIK |
Scrumban STATIK |
| 1. ´Eignung für den Zweck´des Dienstes? |
Auch wenn der Ablauf im Sprint selbst meist klar ist, sind Einzelschritte in der Visualisierung hilfreich. Die Visualisierung ist grossteils schnell als Vorteil akzeptiert. |
| 2. Aktuelle Quellen der Unzufriedenheit | Dieser Punkt kann exakt so wie das Original mit Unterscheidung interner/externer Unzufriedenheiten im Bezug auf die jeweilige Scrumban-Implementierung erfolgen. |
| 3. Quellen und Arten der Nachfrage | Auch da kann die Standard-Vorgehensweise genutzt werden. Lediglich bei dem primären Arbeitstyp ´Entwicklung´ werden die Aussagen sich eher an die übergelagerte Raodmap anlehnen bzw. sich darauf beziehen. |
| 4. Aktuelle Lieferfähigkeit? | Dieser Abgleich der Kapazität macht eher bei der generellen Gestaltung als auch im Review Sinn. Daher empfehle ich, für Scrumban diesen Punkt hier auszulassen. |
| 5. Modellieren des Lieferarbeitsflusses? | Ebenso kommt hier die Standardanwendung zum Tragen. Wobei dies meist eher nur eine Visualisierung des Arbeitsflusses ist, der wenig Überraschungen bergen wird. Trotzdem sollte dieser Punkt keineswegs übersprungen werden. |
| 6. Passende Dienstklassen? | Lieferversprechen machen sowohl bei mehreren Arbeitstypen als auch bei mehreren paraellen Scrum-Teams Sinn. Die Umsetzung sollte demnach sinngemäss erfolgen |
| 7. Entwurf des Kanbansystems | Letztendlich ist das der Punkt, wo die Visualisierungen stattfinden. |
| 8. Vervollständigen des Kanbansystems | Hier rege ich die Zusammenführung aller Informationen und die Evaluierung des gegenseitigen Verständnisses an. Insbesondere bei diesem abschliesseden Punkt kann an die Ausrichtung von Obeya gedacht werden. |
Rückblickend bedeutet dies nur einen wahrscheinlichen Verzicht auf Punkt 4 – der Vergleichsevaluierung der aktuellen Lieferfähigkeit. Alle anderen Schritte inklusive Reverse STATIK machen beim Aufbau eines Scrumban viel Sinn.
HINEINGRABEN AgilePM
Was ist jedoch, wenn wir statt einem NDUF-Ansatz (No Design Up Front) wie Scrum einen Vertreter eines EDUF-Ansatzes (Enough Design Up Front) wie AgilePM zuwenden?
Da dieses Modell weniger bekannt ist als Scrum, skizziere ich dieses zum Verständnis der kommenden Empfehlungen kurz.
Der Ablauf besteht aus einem 6-stufigen generischen Prozess. Aussagen zur Entwicklungszeit werden erst mit der Versionierung der Bezugsmarke der Verein-barungen – also zum Ende – von ´Foundations´ (detailliertere Anforderungen auf einer mittleren richtungsweisenden Ebene sowie grundlegende Abmachungen zur Lösungsarchitektur, Umgebungen für Tests und Entwicklung, die Organisation der Teams mit passender Kommunikation samt einer Roadmap) getroffen.
Das bedeutet, diesen Aussagen liegt eine grobe Analyse der zu liefernden Gegenstände (ggf. basierend auf der Unterstützung von Modellen und Prototypen) und der Arbeitsweisen sowie der tätigen bzw. beeinflussenden Ressourcen zugrunde. Dies erfolgt nach der Prüfung der generellen Passung Strategie:Entwicklungsidee in ´Pre-Project´ in den Abschnitten ´Feasibility´ als auch ´Foundations´.
Die Entwicklung selbst wird nahezu ident wie bei den Sprints in Scrum in Timeboxen im Schritt ´Evolutionary Development´ (gleich ob ´Structured´ oder ´Free Format´ oder ´Service´) abgewickelt.
Die Ausrollung erfolgt im Schritt ´Deployment´. Wobei hier auch immer vorab Ende-zu-Ende Tests pro Inkrement (zumindest eine oder mehere Timeboxen) getätigt werden.
Schlussendlich ist ´Post-Project´ für die Messung des bisher eingetretenen Nutzens und dessen Dokumentation konzipiert.
Quelle: www.agilebusiness.org
| Events |
Artefakte |
| Baselining per phase |
Terms of Reference |
| Project Review | Business Case |
| -- | Prioritised Requirements List |
| -- | Development Approach Definition (DAD) |
| -- | Solution Approach Definition (SAD) |
| -- | Management Approach Definition (MAD) |
| -- | Delivery Plan |
| -- | Timebox Plan |
| -- | Timebox Review Records |
| -- | Project Review Report |
| -- | Benefits Assessment |
ABGLEICH AgilePMban
Den Detailabgleich wie oben können wir uns hier ersparen. Der grosse strukturelle Unterschied zu Scrumban besteht nun in genau den E-Schritten – also der Differen N:E – sprich No zu Enough Design Upfront. D.h., im Detail sind es die Schritte ´Pre-Project´, ´Feasibility´ und ´Foundations´. Genaues Prüfen könnte sogar eine Verschiebung von ´Pre-Project´ auf die Koordinations- oder Strategieebene ergeben. So wie es auch ein wahrscheinlich weiteres ´Post-Project´ mit eher längerfristigem Betrachtungshorzont auf einer diesen Ebenen geben sollte.
Diese Schritte dienen in Summe dem Abgleich der Arbeit, der Prüfung der Machbarkeit, Auswahl und Vorbereitung der Umsetzung der grösseren Happen an Arbeit. Das sind alles Aufgaben links vor dem Zusagepunkt.
Quelle: Kanban University, Training Kanban Systemdesign
n der Abbildung sind alle diese drei Prozessabfolgen nun einmalig pro Arbeitsvorschlag LINKS vor dem Zusagepunkt zu durchlaufen. Die Entwicklung, das Testen und die Ausrollung mit den Schritten ´Evolutionary Development´, ´Deployment´ und auch ´Post-Project´ (liegt NACH der Implementierung beim Kunden und damti nach dem Lieferpunkt) wird immer wieder als Schablone für jedes einzelne kleine Stück Arbeit neu genutzt.
Die Anwendung von Kanban erfolgt im Ansatz her völlig analog. Lediglich der Abbildungsumfang ist etwas grösser.
IMPLEMENTIERUNG AgilePMban
Ebenso können wir hier auf einen weiteren Detailabgleich verzichten, da sich alle einzelnen Punkte der Implementierung ident verhalten wie bei Scrumban.
Der Unterschied in der Nutzung mit Kanban befindet sich de facto nur im strukturellen Ansatz der Modelle.
Sinngemäss kann die Aussage von David Anderson nun lauten: „… macht alles Kanban und wendet es in einer Umgebung an, die bereits AgilePM einsetzt".
Wir sehen also die Universalität in der Nutzung von Kanban für andere agile Methoden unterschiedlicher Ausprägung.
FAZIT
Wenn wir gemeinsam zurückblicken, so analysierten wir anhand zweier Vertreter verbreiteter agiler Methoden die Optionen sowie Machbarkeit einer Kombination mit Kanban.
Wir blickten dabei in grosser Detailtiefe auf die jeweiligen Elemente und überlegten uns die Tiefe der Implementierungen als auch einen systematischen Weg zur Umsetzung. Dabei entdeckten wir, wie nahezu exakt die Standardschritte von STATIK allgemein anwendbar sind. Lediglich die nicht vorhandene Nutzung der Systemlast bei Services erfährt keine (sofortige) Beachtung durch eine Limitierung der gleichzeitigen Bearbeitung pro Arbeitsschritt.
Als Vorteile ergaben sich neben der augenscheinlichen Visualisierung viele weitere Einzelheiten und keinerlei Widersprüche. Wenn nun auch obenstehenden Empfehlungen für einen systematischen Einsatz von Kanban als Kombination berücksichtigt werden, egalisieren sich sogar bisherige Nachteile einer zu rudimentären oder schnellen Umsetzung. Zumindest werden bewusste Entscheidungen zur Tiefe der Implementierung angeraten und auch die vereinbarte Vorgehensweise sollte visualisiert werden.
Getrost darf an dieser Stelle empfohlen werden, im Regelfall die Vorteile eines ??-ban-Ansatzes zu prüfen. Möglicherweise werden die Gehirnzellen anfangs etwas mehr beansprucht. Die dauerhaften Vorteile wiegen dies jedoch bei weitem auf.
Dieter Strasser, MSc, CMC, Geschäftsführer:
▪ This email address is being protected from spambots. You need JavaScript enabled to view it.
Trainer, Coach, Facilitator bei Viable Projects GmbH:
▪ www.viableprojects.eu
