5 1 Vote
Artikel-Rating

Scrumban ist die Verschmelzung von Scrum und Kanban, bei der beide Frameworks bzw. Methoden vollumfänglich und vollständig umgesetzt werden. Im Gegensatz zur häufig anzutreffenden Sichtweise, dass in Scrumban lediglich die „aktuell am besten passendsten“ Elemente aus beiden agilen Arbeitsweisen genutzt werden, ist diese Definition von Scrumban deshalb deutlich umfassender.

In diesem Artikel erfährst Du, auf welchen Grundprinzipien Scrumban basiert und wie die Umsetzung genau aussehen kann. Dabei stütze ich mich vor allem auf den Kanban Guide für Scrum Teams, den Du Dir bei Scrum.org herunterladen kannst.

Scrumban ist keine Rosinenpickerei

Im Internet findest Du diverse Artikel darüber, was Scrumban ist bzw. sein könnte.

Die meisten von ihnen schlagen vor, sowohl aus Scrum als auch aus Kanban die „besten“ oder „passendsten“ Elemente für die gemeinsame Arbeit zu übernehmen. (Beispielsweise kannst Du das so im Beitrag auf Teamhood so lesen.)

Diese Idee mutet mitunter wie reine Rosinenpickerei an, die darauf hinausläuft, dass elementare Prinzipien aus beiden agilen Arbeitsformen ausgelassen werden.

Beispielsweise weil sie zu schwer umzusetzen wären oder sie einer Organisation oder einem Team gerade nicht in den Kram passen.

Rosinenpicker-Scrumban

Aber mit einer solchen Vorgehensweise wirst Du weder Scrum noch Kanban wirklich gerecht. Vor allem verspielst Du den potenziellen Nutzen, der durch sie entstehen kann, gleich doppelt.
0
Hast Du schon Erfahrungen mit solchen halbgaren Anwendungen von Scrumban machen können? Wie ist Deine Meinung zu dem Thema?x
Du bist also weder gut beraten, beispielsweise die Scrum Events auszulassen, noch ist es eine gute Idee, das WIP-Limit aus Kanban zu verwerfen.

Echtes Scrumban ist sowohl Scrum als auch Kanban

Im Gegensatz dazu gibt es durchaus die Möglichkeit, sowohl Scrum als auch Kanban einzusetzen, ohne dabei Abstriche zu machen. Möglich wird dieser Scrumban-Ansatz vor allem deshalb, weil Scrum ein Framework und keine Methode ist.

Denn dadurch kannst Du Scrum umsetzen, wie es der Scrum Guide vorsieht, und gleichzeitig alle Elemente, Prinzipien und Praktiken der Kanban-Methode anwenden, ohne dass dabei wichtige Bestandteile aus Kanban verloren gingen.

Zugegebenermaßen ist diese Interpretation von Scrumban deutlich anspruchsvoller als nur das „aktuell Passendste“ umzusetzen.

Aber dafür stiftet diese Art von Scrumban auch einen echten Mehrwert für Dein Team und Deine Organisation.

Echtes Scrumban - Kanban für Scrum Teams

Grundprinzipien von Scrumban

Nach dieser Lesart basiert Scrumban vor allem auf vier wichtigen Grundprinzipien, die Du auch im schon erwähnten Kanban Guide für Scrum Teams wiederfinden kannst.

  • Der Scrum Guide bleibt vollständig gültig.

  • Fokus auf den Workflow des Scrum Teams durch Kanban
  • Nutzung einer Definition of Workflow

  • Umsetzung der Kanban-Praktiken in Scrumban

Der Scrum Guide bleibt vollständig gültig

Wie bereits erwähnt bleiben die Spielregeln des Scrum Guides auch bei der Erweiterung durch Kanban bzw. der Umsetzung von Scrumban weiterhin gültig. Im Kanban Guide für Scrum Teams heißt es dazu:

Dieser Leitfaden soll den Scrum Guide weder ersetzen noch Teilen davon widersprechen. Er ist dazu gedacht, die Praktiken von Scrum zu verbessern und zu erweitern.

Fokus auf den Workflow des Scrum Teams durch Kanban

Scrumban ermöglicht einem Scrum Team durch die Erweiterung mit Kanban einen stärkeren Fokus auf seinen Workflow. Allerdings bezieht sich diese Optimierung und Verbesserung des Workflows in Scrumban nicht ausschließlich auf die einzelnen Arbeitsschritte während eines Sprints (und somit lediglich auf das Sprint Backlog eines Scrumban Teams).

Es ist für ein Scrumban Team möglich und sinnvoll, seinen Workflow über den Sprint hinaus zu definieren wie hier rechts zu sehen.

Zum einen bezieht dieser Workflow Arbeitsschritte aus dem Product Backlog mit ein, die dem Sprint selbst vorgelagert sind. Zum anderen besitzt dieser Workflow auch einen dem eigentlichen Sprint nachgelagerte Prozessschritt (Releasable).

Letzterer wäre beispielsweise sinnvoll, wenn ein Scrum Team User Stories erst dann für den Release-Prozess freigibt, wenn sie die Sprint Review durchlaufen haben.

Wie Du siehst, gehört auch der erste Status des Sprint Backlogs (Planned) noch nicht zur Kategorie Doing bzw. Work In Progress, sondern noch zur Kategorie To Do. Denn andernfalls würde das die Cycle Time des Teams unnötig verfälschen, weil mit dem Sprint Planning bereits alle User Stories als Work In Progress zählten, obgleich noch gar nicht an ihnen gearbeitet wird.

Nutzung einer Definition of Workflow

Damit Dein Scrumban Team den Workflow (wie von Kanban gefordert) messen und steuern kann, schreibt der Kanban Guide für Scrum Teams eine sogenannte Definition of Workflow vor. In erster Linie dient diese dazu, die Kanban-Praktik Mache Regeln explizit umzusetzen. So gesehen ist sie eine reine Formalisierung dieser Praktik, die eine starke Parallele zur Definition of Done aus dem Scrum Guide aufweist.

  • Welche Elemente diese Definition genau enthält und wie sie in der Praxis funktioniert, erfährst Du in meinem Artikel Die Definition of Workflow.

Umsetzung der Kanban-Praktiken in Scrumban

Auch in Scrumban sind die bekannten Kanban-Praktiken weiterhin gültig und werden entsprechend umgesetzt. Allerdings findest Du interessanterweise im Kanban Guide für Scrum Teams lediglich vier statt der üblichen sechs Praktiken:

  • Visualisierung des Workflows (durch ein Kanban Board)
  • Begrenzung des Work In Progress (durch ein WIP-Limit)

  • Aktives Management laufender Arbeit

  • Überprüfen und Anpassen der Definition of Workflow (DoW) des Teams

Zunächst einmal wird hier deutlich, dass diese Punkte aus Scrumban vollkommen identisch mit den bekannten Kanban-Praktiken sind. Auch in Scrumban wird also ein WIP-Limit angewendet, das die Begrenzung paralleler Arbeit ermöglicht. Und natürlich wird auch in Scrumban der Workflow über das bekannte Kanban Board visualisiert. Ebenso wird die laufende Arbeit durch Metriken wie beispielsweise Work Item Age aktiv gesteuert oder auf Tools wie das Cumulative Flow Diagram zurückgegriffen.

Allerdings gibt es drei Abweichungen im Vergleich zu den sechs „echten“ Kanban-Praktiken.

  • Die Kanban-Praktik Mache Regeln explizit ist entfallen, weil sie wie oben erwähnt durch die Nutzung einer Definition of Workflow unnötig wird.
  • Die Praktik Verbessere gemeinsam & entwickle experimentell wurde zur Praktik Überprüfen und Anpassen der Definition of Workflow des Teams geändert und stellt damit die DoW stärker in den Fokus. Hinzu kommt, dass dieser Prozess auch durch die Sprint Retrospektiven seine Beachtung findet.

  • Die Kanban-Praktik Implementiere Feedbackzyklen ist in Scrumban ebenfalls nicht vorhanden. Weil Scrum jedoch weiterhin vollumfänglich umgesetzt wird, sind durch die Scrum Events die notwendigen Feedbackzyklen bereits vorhanden und müssen daher auch nicht explizit erwähnt werden.

Fazit zu Scrumban

Ich hoffe, ich konnte Dir mit diesem Artikel vermitteln, dass Scrumban deutlich mehr ist, als sich aus beiden Frameworks & Methoden das Schönste und Passendste rauszusuchen. Denn nach dieser Scrumban-Interpretation bleiben sowohl Kanban als auch Scrum vollumfänglich und vollständig erhalten, sodass für Deine Organisation und Dein Team echter Nutzen entstehen kann.

Wenn Du noch Fragen, Ideen, Anregungen oder Kritik zu diesem Beitrag hast, freue ich mich wie immer auf Dein Feedback in den Kommentaren und auf dieser Seite!