Scrumban – Was ist das?

Scrumban ist ein aus Scrum und Kanban gebildetes Kunstwort und beschreibt einen Methodenmix der beiden mit Scrum-Events, Kanban-Visualisierung, WIP-Grenzen, Pull-System und kontinuierlichem Fluss. Diese Kombination ist besonders für solche Unternehmen nützlich, die von Scrum auf Kanban umstellen oder Agile-Methoden ausprobieren möchten, aber besonderen Wert auf einen Pull-Workflow legen.

Der Begriff “Scrumban” wurde von Corey Ladas geprägt, dem Autor von “Scrumban: Essays on Kanban Systems for Lean Software Development”.

Scrum und Kanban auf den Punkt gebracht

Scrum entstand als Framework für Simultaneous Engineering in der Software-Industrie mit dem Ziel, die Geschwindigkeit der Produktbereitstellung zu erhöhen und flexibler auf veränderte Anforderungen und Marktbedingungen reagieren zu können. Scrum strukturiert die Bearbeitung in 1- bis 4-wöchige Iterationen (Sprints), nach denen jeweils ein funktionierendes Produkt verfügbar sein soll. Scrum-Teams sind klein, interdisziplinär, und ihre Aufgaben für jeden Sprint werden von einem Product Owner ausgewählt.

Kanban dagegen hat seine Wurzeln in der Produktion und eines seiner prägenden Merkmale sind WIP-Grenzen. Teams, die Kanban verwenden, konzentrieren Ihre Aufmerksamkeit auf das Aufrechterhalten eines kontinuierlichen Arbeitsflusses. Hier sind die Arbeitspakete als Kanban-Karten auf einer in Arbeitsschritte unterteilten Tafel visualisiert. Jede Phase hat ein eigenes WIP-Limit, um den Durchsatz zu beschränken, und wird regelmäßig überwacht, um Prozesseffizienz und Planbarkeit zu gewährleisten.

Was ist Scrumban?

Der Scrumban-Hybrid versucht, das Beste aus beiden Welten zu kombinieren, um den individuellen Herausforderungen besser gerecht zu werden. Oft wird erfahrenen Teams empfohlen, von Scrum zu Kanban zu wechseln, und Scrumban ist hierfür gut geeignet. Nicht selten entscheiden sich die Teams dann, bei Scrumban zu bleiben. In mancher Hinsicht ist Scrumban enger an Kanban als an Scrum angelehnt: Scrumban lässt sich leichter auf unterschiedliche Anwendungen adaptieren, denn es ist weniger restriktiv als Scrum.

Der Ursprung von Scrumban: Scrum einzuführen ist schwierig

Vielen Teams fällt die Einführung von agilen Methoden nicht leicht. Es erfordert einen Bewusstseinswandel, der oft schwer zu verinnerlichen ist. Zudem denken viele Manager aufgrund seiner Popularität ausschließlich an Scrum, wenn es um agile Methoden geht; und das, obwohl zahlreiche andere Frameworks und Methoden verfügbar sind, wie z. B. Kanban, XP, DSDM usw.

Zwar gibt es viele Erfolgsgeschichten in der Scrum-Implementierung, wenn Sie die beteiligten Mitarbeiter jedoch fragen könnten, würden diese Ihnen vermutlich bestätigen, dass es nicht einfach ist, mit Scrum erfolgreich zu sein. Führende Unternehmen benötigten i. d. R. 12 bis 16 Wochen, um die Disziplin zu etablieren, damit Scrum funktionieren kann. Gewöhnlich benötigen Unternehmen auch umfangreiche externe Beratung bei der Einführung. Nicht selten kämpfen Firmen dann damit, die neuen erforderlichen Rollen wie Product Owner, Scrum Master und Entwicklungsteam zu besetzen – für manche eine kleine HR-Katastrophe.

Darüber hinaus ist die Berechnung von Story-Punkten und die Messung der Geschwindigkeit – obwohl laut des offiziellen Scrum-Guides nicht zwingend erforderlich – fast schon zu einer Notwendigkeit geworden. Die meisten Teams haben Mühe, diese Konzepte zu verstehen, wobei sich Scrum Master darüber beschweren, wie schwierig die fachgerechte Anwendung ist. Mit Scrumban lassen sich all diese unnötigen Feinheiten vermeiden.

Projektmanager sind es gewohnt, mit Projekten umzugehen, die sich durch einen definitiven Start- und Endtermin auszeichnen. Sie arbeiten mit funktionsübergreifenden Teams, die Monate und manchmal Jahre zusammenarbeiten. Solche Projektteams profitieren oft vom Scrumban, da sie neue, von Scrum-Events abgeleitete Kommunikationsmethoden erlernen können, mit speziellen Planungssitzungen zur Besprechung der Projektanforderungen.

Bei etlichen Projekten, insbesondere bei Infrastrukturprojekten, steht am Ende eines Sprints nicht immer ein lieferbares Produkt zur Verfügung, was eine zentrale Scrum-Anforderung ist. Der Arbeitsfortschritt findet vielmehr kontinuierlich statt und geht erst bei dessen Fertigstellung in die Produktion bzw. in die nächste Projektphase über. Der Scrumban-Ansatz baut daher auf dem bestehenden Projektablauf bzw. Produktlebenszyklus auf und fügt diesem mit Kanban lediglich ein Visibilitätstool und die Scrum-Event- Methodik hinzu.

Scrumban beharrt auch nicht darauf, dass Projektmanager einen alleinigen Product Owner festlegen, der für den Backlog verantwortlich ist. Dessen Rolle ist in Scrum von entscheidender Bedeutung. In Unternehmen gibt es jedoch häufig viele Stakeholder mit ganz unterschiedlichen Anforderungen, was es einer einzelnen Person nahezu unmöglich macht, die Storys und Probleme zu priorisieren. Scrumban fordert keine standardisierten Storys oder einzelne Backlog-Eigentümer, sondern fordert von dem Team lediglich, sicherzustellen, dass der Backlog für alle sichtbar ist.

Übergang von Iterationen zur kontinuierlichen Bereitstellung

Scrumban ermöglicht es Entwicklungsteams, von festgelegten Planungszeiten auf eine bedarfsgerechte Planung umzustellen. Neue To-Dos könnten regelmäßig in der Produktion festgestellt werden. Im Gegensatz zu Scrum zwingt Scrumban die Produktteams nicht dazu, den Sprintumfang auf 1 bis 4 Wochen zu begrenzen, sodass die Erfüllungsphase so lange andauern kann, wie es für das gewünchte Endergebnis erforderlich ist. Für die meisten Unternehmen ist das Ende der Entwicklung erst der eigentliche Anfang des Lebenszyklus. Diese Projekte werden eher so umgesetzt, dass die von ihnen ausgelöste kurzzeitige Veränderung weitergeführt wird und Nutzen bringt, wofür Scrumban zweckmäßiger ist.

Für Entwicklungsteams, die mit Scrum vertraut sind und einen Continuous-Flow-Ansatz verfolgen, ist der Übergang von der Produktentwicklung zur Pflege mit Scrumban einfacher.

Unterschiede zwischen Scrumban und Kanban

Gewöhnlich teilen Teams, die Scrumban-Boards verwenden, den Arbeitsablauf in mehrere Phasen auf als bei einem Kanban-Board üblich. Dies soll verdeutlichen, dass es sich um einen graduellen Prozess handelt, der sich aus dem Sprint-ähnlichen Projektplanungsansatz ergibt. Sehr oft enthält ein Scrumban-Board immer noch eine “Sprint”-Phase oder “Story”-Arbeitspakete. So ist es möglich, den Bearbeitungsfortschritt in Bezug auf eine Story oder einem Sprint zu verfolgen, ungeachtet der Tatsache, dass das Team kontinuierlich arbeitet.

Auch sind Scrumban-Teams meist freier bei der Priorisierung von Spalten-Elementen als ihre Kanban-Kollegen, die die First-In-First-Out-(FiFo)-Regel zu beachten haben.

Fazit

Für Unternehmen, die die Notwendigkeit erkennen, zu einer agileren, schlankeren Arbeitsweise überzugehen, ist Scrumban ein einfacher Ansatz – ohne den unnötigen Ballast aus Scrum, den viele Unternehmen nicht benötigen. Es ermöglicht Unternehmen, ihre Arbeit in einer für sie gewohnten Art und Weise fortzusetzen und gleichzeitig bewährte Lean- und Agile-Praktiken, wie sie in Continuous-Flow-Umgebungen praktiziert werden, zu implementieren.

Scrumban kann Ihnen genau das benötigte Maß an Rigorosität verschaffen, zusammen mit der Flexibilität, Effizienz und Transparenz von Kanban und Lean.

Die wichtigsten Vorteile des Einsatzes von Scrumban sind:

• höhere Qualität der abgeschlossenen Arbeit und Just-in-time-Entscheidungsfindung
• erhöhte Bearbeitungsgeschwindigkeit
• minimierte Verschwendung
• handlungsfähigere und zufriedenere Teams
• kontinuierlich verbesserte Prozesse