Was bedeutet Scrumban
Das Wort "Scrumban" ist eine Kombination aus Scrum (mehr Infos Scrum Training) und Kanban (siehe auch Kanban Training) . Der beste Weg, Scrumban zu erklären, ist also, einen Überblick über die beiden unterschiedlichen Frameworks zu geben und dann zu besprechen, wie sie zu Scrumban verschmolzen sind.
Was ist Scrum?
Scrum ist ein agiles Framework, das aus ein- bis vierwöchigen Sprints besteht. Es wurde entwickelt, um kleinen selbstorganisierten Teams zu helfen, konsistent konkrete Produkte oder Ergebnisse zu liefern.
Das Scrum- Team (siehe Team Training) verwaltet eine Liste von Gesamtanforderungen an das Projekt (das so genannte Backlog) und legt fest, welche davon im nächsten Sprint abgearbeitet werden sollen. Nachdem dies festgelegt wurde, wird der Sprint "abgeschlossen", und alle anderen Arbeiten müssen in einer zukünftigen Iteration erledigt werden. Am Ende jedes Sprints werden die Ergebnisse überprüft, und der Plan für die nächste Iteration wird erstellt oder überarbeitet.
Wenn es richtig gemacht wird, haben Teams, die Scrum implementieren, das Potenzial, ein paar Dinge zu erreichen:
Kanban ist weniger zeitbasiert als Scrum. Anstatt sich auf Sprints und geplante Lieferungen zu konzentrieren, konzentriert es sich auf To-Do-Listen und die Verteilung der Arbeit auf das Team. Anstatt die Arbeit durch Sprints zu begrenzen, wird sie durch die Arbeitslast begrenzt. Mit anderen Worten: Sie können jederzeit ändern, welche Aufgaben als nächstes erledigt werden, solange Sie die Anzahl der zugewiesenen Aufgaben nicht erhöhen.
Kanban verwendet ein Tafelformat, um Teams dabei zu helfen, den Projektworkflow zu visualisieren und zu verstehen, in welchem Stadium sich Aufgaben befinden. Ursprünglich wurde es mit Post-It-Zetteln auf einer physischen Tafel verwaltet, aber es gibt jetzt Software-Optionen, die virtuelle Kanban-Tafeln bereitstellen.
Wenn Kanban richtig umgesetzt wird, ergeben sich folgende Vorteile:
Was ist also Scrumban? Scrumban versucht, einen Mittelweg für Teams zu finden, denen Scrum zu starr und Kanban zu flexibel ist.
Scrumban verwendet typischerweise den Scrum-Backlog-Ansatz zum Planen, Priorisieren und Zuordnen von Arbeit. Aber es verwendet Kanban-Boards, um die geplante Arbeit zu visualisieren, damit Teams schnell den Fortschritt der Aufgaben sehen und Engpässe erkennen können. Einige Scrumban-Teams behalten die Verwendung von Sprints bei, während andere sich dafür entscheiden, diese Scrum-Anforderung aufzugeben.
Scrumban verwendet oft Kanban-Regeln für die Menge an Arbeit, die zu einem bestimmten Zeitpunkt in Arbeit sein kann. Bei dieser Methode beginnt ein Team mit einer bestimmten Anzahl von Aufgaben auf einmal. Dann werden andere Arbeiten nur begonnen, wenn einige dieser Aktivitäten beendet sind, so dass nie mehr Aufgaben in Arbeit sind, als das Team glaubt, auf einmal bewältigen zu können.
Wie funktioniert Scrumban?
Scrumban beinhaltet die Anwendung von Kanban-Prinzipien - Visualisierung von Arbeitsabläufen und flexible Prozesse - auf das Scrum-Framework eines Teams. Aber Scrumban entfernt einige der starreren Aspekte von Scrum und überlässt es jedem Team, einen individuellen Ansatz für die Entwicklung zu erstellen.
Das Empfangen im laufenden Betrieb bringt einen großen Vorteil in Bezug auf die Reaktionsfähigkeit.
Einerseits behebt der Entwickler einen Fehler leichter, wenn der Kontext noch frisch im Kopf ist. Wird das Rezept dagegen nur alle zwei Wochen durchgeführt, verlängert sich die Zeit zur Fehlerkorrektur auf mehrere Iterationen (zur Abbildung auf IT N: Fehlererkennung, IT N+1: Fehlerkorrektur, IT N+2: Rezept der Korrektur). In Scrum ist das Board dem gewidmet, was während der Iteration passiert. Die Absicht ist, sich auf den Kern der Entwicklung zu konzentrieren.
Der der Iteration vorgelagerte Lebenszyklus der User Stories ("in Arbeit", "entwicklungsbereit" usw.) wird also vom Product-Owner verwaltet und ist für den Rest des Teams nicht sichtbar.
Vor allem für Entwickler ist es so, als würde man im Nebel fahren und deshalb nicht gut genug vorausschauen können, wenn man die für die nächsten Tage geplanten Funktionen nicht sieht. Das Team muss wissen, was in den nächsten Sprints auf uns zukommt, weil es einen Einfluss auf die Entwicklung des aktuellen Sprints haben kann.
Es ist auch sehr wichtig, einen angepassten Design-Workflow zu definieren, in dem wir viel mehr Akteure als den Product-Owner haben können (Business- oder Marketing-Manager, UX, Designer, wenn nötig etc ...).
Dies ermöglicht uns auch eine echte Sichtbarkeit in Bezug auf die Steuerung auf der Ebene der Vorbereitung der nächsten Phase des Projekts zu haben.
Was ist Scrum?
Scrum ist ein agiles Framework, das aus ein- bis vierwöchigen Sprints besteht. Es wurde entwickelt, um kleinen selbstorganisierten Teams zu helfen, konsistent konkrete Produkte oder Ergebnisse zu liefern.
Das Scrum- Team (siehe Team Training) verwaltet eine Liste von Gesamtanforderungen an das Projekt (das so genannte Backlog) und legt fest, welche davon im nächsten Sprint abgearbeitet werden sollen. Nachdem dies festgelegt wurde, wird der Sprint "abgeschlossen", und alle anderen Arbeiten müssen in einer zukünftigen Iteration erledigt werden. Am Ende jedes Sprints werden die Ergebnisse überprüft, und der Plan für die nächste Iteration wird erstellt oder überarbeitet.
Wenn es richtig gemacht wird, haben Teams, die Scrum implementieren, das Potenzial, ein paar Dinge zu erreichen:
- Eine schnellere Markteinführung. Scrum ist eine Möglichkeit, die inkrementelle Lieferung, die der agile Ansatz verspricht, durch regelmäßige kleine Releases zu erreichen.
- Geringeres Risiko. Die Auslieferung früher Prototypen innerhalb kurzer Iterationen ermöglicht es Teams, "früh zu scheitern" und Lektionen zu lernen, die sie sofort auf die Entwicklung des Produkts anwenden können, bevor es ausgeliefert wird.
- Transparenz und Sichtbarkeit. Scrum-Zeremonien ermöglichen es den Teams, Straßensperren zu identifizieren, was funktioniert und was nicht. Sie ermöglichen auch eine Umgebung, in der Teams zusammenarbeiten, um Lösungen und Wege zur Verbesserung oder Beseitigung der Engpässe und Verzögerungen zu finden.
- Höhere Benutzerzufriedenheit. Scrum-Teams sind bestrebt, den Benutzern zu helfen. Sie tun dies, indem sie die Benutzer früh und oft in die Testphase einbeziehen und schnell auf Veränderungen in der Branche reagieren und das Backlog entsprechend anpassen
Kanban ist weniger zeitbasiert als Scrum. Anstatt sich auf Sprints und geplante Lieferungen zu konzentrieren, konzentriert es sich auf To-Do-Listen und die Verteilung der Arbeit auf das Team. Anstatt die Arbeit durch Sprints zu begrenzen, wird sie durch die Arbeitslast begrenzt. Mit anderen Worten: Sie können jederzeit ändern, welche Aufgaben als nächstes erledigt werden, solange Sie die Anzahl der zugewiesenen Aufgaben nicht erhöhen.
Kanban verwendet ein Tafelformat, um Teams dabei zu helfen, den Projektworkflow zu visualisieren und zu verstehen, in welchem Stadium sich Aufgaben befinden. Ursprünglich wurde es mit Post-It-Zetteln auf einer physischen Tafel verwaltet, aber es gibt jetzt Software-Optionen, die virtuelle Kanban-Tafeln bereitstellen.
Wenn Kanban richtig umgesetzt wird, ergeben sich folgende Vorteile:
- Die Arbeit wird sichtbar. Es wird eine genaue Visualisierung des Entwicklungsworkflows erstellt. Dadurch können Teams sehen, wo die Engpässe und Verzögerungen liegen, die sie dann beheben können.
- Bessere Verantwortlichkeit und Kommunikation. Es gibt jedem ein gleiches Verständnis dafür, wer an was arbeitet und wie der Status einer bestimmten Initiative ist.
- Die Teams arbeiten im Rahmen ihrer Kapazität. Der Fokus auf die Begrenzung der laufenden Arbeit durch ein Pull-System verhindert, dass die Teams mit Arbeit überhäuft werden.
- Werte werden viel schneller geschaffen und geliefert. Dies wird durch die Verbesserung der Geschwindigkeit und Effizienz des Workflows erreicht.
Was ist also Scrumban? Scrumban versucht, einen Mittelweg für Teams zu finden, denen Scrum zu starr und Kanban zu flexibel ist.
Scrumban verwendet typischerweise den Scrum-Backlog-Ansatz zum Planen, Priorisieren und Zuordnen von Arbeit. Aber es verwendet Kanban-Boards, um die geplante Arbeit zu visualisieren, damit Teams schnell den Fortschritt der Aufgaben sehen und Engpässe erkennen können. Einige Scrumban-Teams behalten die Verwendung von Sprints bei, während andere sich dafür entscheiden, diese Scrum-Anforderung aufzugeben.
Scrumban verwendet oft Kanban-Regeln für die Menge an Arbeit, die zu einem bestimmten Zeitpunkt in Arbeit sein kann. Bei dieser Methode beginnt ein Team mit einer bestimmten Anzahl von Aufgaben auf einmal. Dann werden andere Arbeiten nur begonnen, wenn einige dieser Aktivitäten beendet sind, so dass nie mehr Aufgaben in Arbeit sind, als das Team glaubt, auf einmal bewältigen zu können.
Wie funktioniert Scrumban?
Scrumban beinhaltet die Anwendung von Kanban-Prinzipien - Visualisierung von Arbeitsabläufen und flexible Prozesse - auf das Scrum-Framework eines Teams. Aber Scrumban entfernt einige der starreren Aspekte von Scrum und überlässt es jedem Team, einen individuellen Ansatz für die Entwicklung zu erstellen.
- Entwickeln Sie eine Scrumban-Tafel
- Eine Scrumban-Tafel ist ähnlich wie eine Kanban-Tafel. Da Sie es als primäres Workflow-Tool verwenden werden, fügen Sie so viele Spalten zu Ihrer Scrumban-Tafel hinzu, wie Ihr Team benötigt, um jede einzelne Phase des Fortschritts zu markieren. Achten Sie aber darauf, dass Sie nicht so viele Spalten anlegen, dass die Tafel unübersichtlich wird und schwer zu sehen ist.
- Legen Sie die Grenzen für den Arbeitsfortschritt fest
- Denken Sie daran, dass Scrum sowohl Zeit- als auch Aufgabenlimits für jeden Sprint festlegt. Kanban hingegen konzentriert sich auf den kontinuierlichen Arbeitsablauf. Sie müssen ein Limit festlegen, wie viel Arbeit Ihr Team zu einem bestimmten Zeitpunkt übernehmen kann. Bei Scrumban wird dieses Limit die Anzahl der Karten sein, die sich zu einem bestimmten Zeitpunkt auf dem Board befinden. Legen Sie ein realistisches Limit fest, damit Ihr Team nicht überwältigt und frustriert wird.
- Ordnen Sie die Prioritäten des Teams auf dem Board
- Dieser Schritt verdeutlicht einen weiteren großen Unterschied zwischen Scrum und Kanban (und Scrumban). Bei Scrum weisen Sie für jeden Sprint bestimmten Personen innerhalb Ihrer Entwicklungsgruppe Aufgaben zu. Unter Scrumban hingegen liegt Ihr Fokus darauf, die Prioritätsreihenfolge aller Projekte auf dem Board festzulegen. Ihr Team wird entscheiden, welche Person welche Aufgaben in Angriff nehmen wird.
- Werfen Sie Ihre Planungs-Karten weg
- Da jeder Sprint ein striktes Zeitlimit hat und das Team während eines Sprints nur an einer vordefinierten Menge von Projekten arbeiten kann, muss ein Scrum-Team abschätzen, wie lange jede Entwicklungsaufgabe dauern wird. Also haben sie Methoden (siehe auch Methoden Training) wie den Planungspoker entwickelt, um die Anzahl der Story Points (die Zeit und Schwierigkeit angeben) für jede Aufgabe zu schätzen. Mit Scrumban ist die Arbeit kontinuierlich und nicht zeitlich begrenzt, daher wird Ihr Team keine Story Points schätzen. Sie werden sich nur auf die Priorisierung der wichtigsten Projekte konzentrieren.
- Legen Sie Ihre täglichen Meetings fest
- Obwohl Sie die meisten der für das Scrum-Framework typischen Meetings - Sprint-Planung, Sprint-Review, Retrospektive - nicht haben werden, können Scrumban-Meetings kurze Standups beinhalten, in denen das Team seine Pläne und Herausforderungen für den kommenden Tag bespricht. Diese kurzen Meetings sind auch ein guter Weg, um die Teambindung und den Zusammenhalt zu fördern, da Ihre Entwickler viel Zeit damit verbringen werden, individuell an ihren Aufgaben zu arbeiten und sonst vielleicht nicht viel Zeit für Interaktion haben.
Das Empfangen im laufenden Betrieb bringt einen großen Vorteil in Bezug auf die Reaktionsfähigkeit.
Einerseits behebt der Entwickler einen Fehler leichter, wenn der Kontext noch frisch im Kopf ist. Wird das Rezept dagegen nur alle zwei Wochen durchgeführt, verlängert sich die Zeit zur Fehlerkorrektur auf mehrere Iterationen (zur Abbildung auf IT N: Fehlererkennung, IT N+1: Fehlerkorrektur, IT N+2: Rezept der Korrektur). In Scrum ist das Board dem gewidmet, was während der Iteration passiert. Die Absicht ist, sich auf den Kern der Entwicklung zu konzentrieren.
Der der Iteration vorgelagerte Lebenszyklus der User Stories ("in Arbeit", "entwicklungsbereit" usw.) wird also vom Product-Owner verwaltet und ist für den Rest des Teams nicht sichtbar.
Vor allem für Entwickler ist es so, als würde man im Nebel fahren und deshalb nicht gut genug vorausschauen können, wenn man die für die nächsten Tage geplanten Funktionen nicht sieht. Das Team muss wissen, was in den nächsten Sprints auf uns zukommt, weil es einen Einfluss auf die Entwicklung des aktuellen Sprints haben kann.
Es ist auch sehr wichtig, einen angepassten Design-Workflow zu definieren, in dem wir viel mehr Akteure als den Product-Owner haben können (Business- oder Marketing-Manager, UX, Designer, wenn nötig etc ...).
Dies ermöglicht uns auch eine echte Sichtbarkeit in Bezug auf die Steuerung auf der Ebene der Vorbereitung der nächsten Phase des Projekts zu haben.