Es scheint mir, dass Scrumban nur eine Form von Kanban mit zusätzlichen Tools wie Kadenz, Planung, Retrospektive und täglichem Standup ist. Warum wird Scrumban zu einer anderen Markenmethodik?
Es scheint mir nicht, dass Scrumban etwas von der Kanban-Philosophie wegnimmt, es ist nur eine Mischung aus Scrum- und Kanban-Tools. Was tut Scrumban, um sich sowohl in der Praxis als auch in der Theorie von diesen beiden anderen Modellen abzuheben? Vielleicht eine andere Möglichkeit, die Frage zu stellen; Wie unterscheidet sich Scrumban von jedem anderen Scrumbut-Ansatz?
Grundsätzlich ist Scrumban ein Management-Framework, das entsteht, wenn Teams Scrum als ihre gewählte Arbeitsweise einsetzen und die Kanban-Methode als Linse verwenden, durch die sie sehen, verstehen und kontinuierlich verbessern können, wie sie arbeiten.
Scrumban unterscheidet sich von Scrum dadurch, dass es bestimmte Prinzipien und Praktiken betont, die sich wesentlich von der traditionellen Grundlage von Scrum unterscheiden. Darunter sind:
Scrumban unterscheidet sich von der Kanban-Methode dadurch, dass es:
Am wichtigsten ist vielleicht, dass die in Scrumban eingebetteten Prinzipien und Praktiken nicht nur für den Softwareentwicklungsprozess gelten. Sie können problemlos in vielen verschiedenen Kontexten angewendet werden und bieten eine gemeinsame Sprache und gemeinsame Erfahrungen über miteinander verbundene Geschäftsfunktionen hinweg. Dies wiederum verstärkt die Art der organisatorischen Ausrichtung, die ein wesentliches Merkmal des Erfolgs ist.
Als Corey Ladas der Welt Scrumban in seinem wegweisenden Buch Scrumban: Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Press, 2009) vorstellte, definierte er es kühn als Übergangsmethode, um Softwareentwicklungsteams von Scrum zu einem „mehr evolved“ Software-Entwicklungs-Framework. In der Praxis hat sich Scrumban jedoch selbst zu einer Familie von Prinzipien und Praktiken entwickelt, die komplementäre Fähigkeiten schaffen, die sowohl von Scrum als auch von der Kanban-Methode einzigartig sind. Diese Fähigkeiten haben zu drei unterschiedlichen Manifestationen geführt:
> As a framework that helps teams and organizations effectively adopt Scrum as a development methodology.As a framework that helps teams and organizations overcome a variety of common challenges scaling Scrum across the Enterprise.
Als Framework, das Teams und Organisationen dabei hilft, ihre eigenen Scrum-basierten Prozesse und Praktiken zu entwickeln, die für sie am besten funktionieren – nicht um Unzulänglichkeiten und Funktionsstörungen auszugleichen, die Scrum aufgedeckt hat, sondern um sie auf eine Weise zu lösen, die für ihre einzigartige Umgebung am effektivsten ist . Ich glaube, dass diese unterschiedlichen Erscheinungsformen entstanden sind, weil Teams und Organisationen sich all der großartigen Dinge bewusst sind, die eine zugrunde liegende Scrum-Methodik auf den Tisch bringt. Dazu gehören Funktionen wie:
Andererseits stehen zu viele dieser Teams und Organisationen bei der effektiven Einführung von Scrum vor Herausforderungen, für die das Framework wenig Anleitung bietet. Dazu gehören Herausforderungen wie:
http://www.informit.com/articles/article.aspx?p=2431512&WT.mc_id=Author_Reddy_Scrumban
Scrumban ist ein umgangssprachlicher Begriff, kein kodifizierter Prozess, daher ist es schwierig, genau zu sagen, was es ist. Ich kann jedoch sagen, dass ich viel Erfolg in Scrum-Teams sehe, die einige der Prinzipien und Praktiken von Kanban übernehmen. Einige von denen, die Scrum-Teams helfen, sind:
Visualisieren Sie Ihren Prozess: Viele Taskboards für Scrum-Teams lauten einfach Ready-Doing-Done. Dies spiegelt selten die Komplexität wider, mit der viele Organisationen ihr Produkt entwickeln. Durch eine genauere Darstellung der Arbeitsabläufe können Sie Engpässe und verbesserungswürdige Bereiche leichter erkennen.
Implementieren Sie WIP-Limits: Viele Studien zeigen, dass es eine optimale Anzahl von Artikeln gibt, die gleichzeitig in Bearbeitung sein können. Der Versuch, das gesamte Team an einer Sache arbeiten zu lassen, kann dazu führen, dass sich alle gegenseitig auf die Zehen treten, aber wenn zu viele Dinge in Bearbeitung sind, wird bis zum Ende des Sprints nichts fertig. WIP-Limits helfen dem Team, dieses Gleichgewicht zu finden und durchzusetzen.
Flow messen und überwachen: Ich sehe immer mehr Scrum-Coaches, die vorschlagen, dass Sie die Zykluszeit messen. Ich denke, das ist in Scrum nicht so wichtig wie in Kanban, aber es kann dem Team viel darüber sagen, was in ihrer Arbeit passiert. Die Vorlaufzeit kann auch für den Product Owner sehr interessant sein, wenn er darüber nachdenkt, wie er sein Backlog verwaltet.
„Vereinbarung zur Verfolgung schrittweiser Veränderungen“ und „Führung auf allen Ebenen“: Dies sind zwei der Kernprinzipien von Kanban und sehr kompatibel mit Scrum. Scrum hat eine Zeremonie für Selbstreflexion und kontinuierliche Verbesserung, aber es ist ziemlich offen, wie Sie das tun. Kanban kann hier Orientierung bieten – insbesondere für neue Teams.
Ich bin mir sicher, dass es noch andere gibt, an die ich im Moment nicht denke. Wenn ich mich an welche erinnere, werde ich den Beitrag bearbeiten und sie hinzufügen.
Ich würde es etwas anders ausdrücken. Scrumban ist der (mittlerweile) ziemlich etablierte Begriff, der von vielen erfahrenen/respektierten Vordenkern in der Lean/Agile-Branche für die Arbeit von Teams verwendet wird, wenn sie die Kanban-Prinzipien auf ihre Scrum-basierte Softwareentwicklungsarbeit anwenden. Die grundlegende Prämisse von Kanban ist es, Teams dabei zu helfen, sich zu verbessern, unabhängig von ihrer Methode der Softwareentwicklungsplanung und -bereitstellung. Teams können es weiterhin Scrum nennen oder zu Kanban oder Scrumban wechseln.
Neben dem Artikel, auf den Ajay Reddy hingewiesen hat, sind hier einige gute Referenzen zu Scrumban:
Das bekannteste und angesehenste – „Scrumban – Essays on Kanban for Lean Software Development“ von Corey Ladas ( http://www.amazon.com/Scrumban-Systems-Software-Development-Cooperandi/dp/0578002140 )
Ein weiterer guter Artikel ist von Yuval Yeret – „Also, was ist Scrumban?“ ( http://yuvalyeret.com/2012/04/28/so-what-is-scrumban/ )
Ein paar Artikel mit unserer eigenen Meinung -
"Was ist Scrumban?" ( http://www.swiftkanban.com/kanban/what-is-scrumban/ )
Hier ist auch ein Blogbeitrag, den ich geschrieben habe, als ich bei einer Lean Coffee-Sitzung auf der LKNA 2012-Konferenz so ziemlich dieselbe Frage gestellt habe - http://blog.digite.com/scrum-kanban-scrumban-or-kanban-lessons- at-lean-kaffee/
Hoffe das hilft!
Scrumbut ist keine Methodik, sondern ein Begriff, der verwendet wird, wenn Menschen vorgeben, Scrum zu betreiben, oder aufgrund organisatorischer Probleme nicht in der Lage sind, es richtig umzusetzen.
Sie können sich auch Scrum vorstellen, aber als eine Art zu arbeiten, während Sie zu Scrum wechseln
Verzetteln Sie sich auf keinen Fall zu sehr in den Methoden, konzentrieren Sie sich auf die agilen Prinzipien und schaffen Sie etwas, das in Ihrer Organisation funktioniert.
Abgesehen von den zuvor erwähnten Unterschieden finde ich, dass das, was Scrumban und Kanban wirklich unterscheidet, die verschiedenen Regeln sind, die es von Scrum übernimmt. Während Kanban locker und Scrum streng ist, spannt Scramban die Mitte und bietet eine Option für einen etwas kontrollierten Kanban-Prozess.
Anstatt keinerlei Zeremonien abzuhalten, behält Scrumban die Tradition eines täglichen Scrums bei und bietet die Möglichkeit, alle Sprint-Meetings hinzuzufügen, die das Team für notwendig hält. Das Gleiche gilt für die Prozessplanung, und obwohl Sprints innerhalb von Scrumban nicht obligatorisch sind, können die Teams sie nach eigenem Ermessen ablehnen. Während Scrumban also immer noch ein ziemlich lockerer Prozess ist, bringt es im Vergleich zu Kanban mehr Kontrolle und kann ein großartiger Übergangspunkt nach Scrum sein.
Niels van Reijmersdal
KMån