Scrumban

Scrum hat sich zu DER Revolution in der Welt der Softwareentwicklung entwickelt. Die Hauptphilosophie hinter Scrum ist die Akzeptanz, dass ein Problem zu Beginn nicht vollständig verstanden oder definiert werden kann. Scrum konzentriert sich darauf, die Fähigkeit des Teams zu maximieren, schnell zu liefern und auf neue Anforderungen zu reagieren. In einer Zeit, in der Projekte von Prozeduren und MS-Project-Planung beherrscht wurden, war dies eine echte Erfrischung. Wegen Scrum:

1. Projekte können das liefern, was der Kunde braucht, nicht nur das, was er dachte, dass er wollte.
2. Teams sind effizient. Sie arbeiten als Einheit, um ein gemeinsames Ziel zu erreichen.
3. Wir haben bessere Projektrollen (wie einen Product Owner und Scrum Master), Zeremonien (wie tägliche Standups, Grooming) und ein Scrumboard.

Aber die zentrale Frage lautet: "Sind wir schon am Ziel"? Und die Antwort lautet: "Nein!". Wir können Scrum optimieren, indem wir es mit Kanban mischen, was zu Scrumban führt.

Eine Kanban-Einführung für Scrumer Im Gegensatz zu Scrum, das im weitesten Sinne ein Rahmenwerk für die Softwareentwicklung ist, ist Kanban eine Methode. Sie legt beispielsweise keine Zeremonien und Projektrollen fest. Es gibt zwei Hauptprinzipien von Kanban, die ich hervorheben möchte:

1. Jede Spalte auf der Kanban-Tafel steht für einen Schritt im Arbeitsablauf. Anstelle der Spuren "ToDo", "In Arbeit" und "Erledigt" wie in Scrum haben Sie also "Definieren", "Entwickeln", "Testen" und "Bereitstellen". Das ist eine umfassendere Sichtweise; eine Aufgabe hat einen breiteren Lebenszyklus. Dieses Konzept wird auch als 'vom Konzept bis zur Kasse' bezeichnet; von der Benutzerforschung und der strategischen Planung bis hin zum Betrieb des Rechenzentrums und dem Produktsupport.
2. Ein weiteres Prinzip von Kanban ist die Begrenzung des WIP (unfertige Arbeit). Ein Beispiel für ein WIP-Limit ist die Begrenzung der Anzahl der Karten, die in jeder Spalte erlaubt sind. Der Vorteil ist, dass Engpässe dynamisch aufgedeckt werden. Aufgrund des WIP ist Kanban ein Pull-Mechanismus. Ein Tester kann z.B. nur dann ein nächstes Workitem abholen, wenn in der Erledigt-Spalte der Entwicklungsspur noch Items vorhanden sind und das WIP-Limit der Testspur nicht überschritten wird.

Schließlich ist Kanban unglaublich einfach, aber gleichzeitig auch unglaublich mächtig. Was ist an Scrum falsch?

1. Der Grund, warum wir zu Scrum übergegangen sind, ist, dass wir den Wasserfallansatz nicht mehr wollten. Aber in Wirklichkeit ist jeder Sprint in Scrum ein Mini-Wasserfall geworden. In jedem Sprint planen die Teams, versuchen zu entwerfen, zu entwickeln und zu testen. Am Ende prüft der Product Owner die abgeschlossene Arbeit und entscheidet, welche der Stories ausgeliefert werden können und bereit für die Produktion sind. Diese Sprints können zu einem Stakkato-Flow führen, der ermüdend sein kann. Mit Kanban können wir Sprints agiler gestalten und das Ziel ist ein kontinuierlicherer Fluss. Im Vergleich dazu, wie man einen Marathon läuft? Sie sprinten nicht 200 Meter weit, sondern in einem konstanten Tempo.
2. Scrum ist ein Push-Mechanismus und 'drückt' daher die Qualität Ihres Produkts. Wenn ein Sprint Backlog definiert wird, wird das Team um eine Verpflichtung gebeten. Was auch immer passiert ist, ein Team muss seine Verpflichtung erfüllen und am Ende des Sprints muss der Product Owner 'decharge' sagen, sonst hat das Team versagt. Kein Team möchte öffentlich scheitern, also nehmen die Teams am Ende des Sprints meist Abkürzungen, um die Frist einzuhalten. Diese Abkürzungen sind tödlich für die Qualität! Nach Engagement zu fragen, bedeutet, der intrinsischen Motivation des Teams nicht zu vertrauen. Das richtige Engagement zeigt sich bei jedem Standup. Bei einem Standup müssen sich die Teammitglieder gegenseitig erzählen, was sie am Vortag getan haben. Wenn sie zu lange an einer Geschichte arbeiten, wird ein anderes Teammitglied rebellieren. Das ist das wahre Engagement.
3. Einer der Gründe, warum wir mit Scrum arbeiten, ist, dass es besser ist, sofort zu beginnen, anstatt im Vorfeld eine Schätzung und eine Machbarkeitsstudie zu erstellen, denn fast immer wird das Projekt nach Abschluss der Studie durchgeführt. Die Schätzung zu Beginn ist nicht zuverlässig und die Machbarkeitsstudie ist reine Zeitverschwendung. Ist das nicht derselbe Fehler, den wir bei Scrum mit den Grooming- und Ready-Sitzungen machen und der eine Menge Overhead verursacht? Der erste Overhead beim Grooming besteht darin, dass wir eine Schätzung mit relativer Präzision abgeben. Es liegt in der Natur eines Entwicklers, sich über die Story-Punkte zu streiten; sind es 3, 5, 8 oder vielleicht 1 Punkt? Und das ist eine Verschwendung. Sie sollten nur über die Storygrößen groß, mittel oder klein sprechen. Eine genauere Schätzung ist reine Zeitverschwendung, denn es gibt zu viele externe Faktoren. Zweitens machen wir mit dem Grooming eine Mini-Machbarkeitsstudie. Mit einem Team denken wir über die Richtung der Lösung nach, und das ist gut so. Aber meistens dauert es zwei oder drei Sprints, bis sie im Sprint umgesetzt wird. Und mit all den Wochenenden voller Bier dazwischen haben wir die Lösungen schon wieder vergessen. Also sagt ein kluger Kopf: 'Ja, lass uns das dokumentieren', aber das ist ein ineffizienter Weg für das eigentliche Problem: Es liegt zu viel Zeit zwischen der Pflege und der Umsetzung.

Scrumban: die Tafel von Kanban [caption id="attachment_13279" align="aligncenter" width="600"] Eine Scrumban-Tafel[/caption] Die erste Spalte in einer Scrumban-Tafel ist für das Backlog reserviert, in dem die Stories nach ihrer jeweiligen Priorität geordnet sind. Es gibt mehrere Regeln für das Kanban-Backlog:

1. Es liegt in der Verantwortung des Product Owners, diese Lane mit Stories zu füllen und sie ständig zu füllen. Der Product Owner muss es vermeiden, zu viele Stories zu erstellen oder zu analysieren, da dies eine Verschwendung darstellt und das Just-In-Time-Prinzip von Scrumban untergräbt. Daher hat das Scrumban-Board ein WIP-Limit von 5 Backlog-Stories.
2. Sorgen Sie für das nötige Maß an Analyse, bevor Sie mit der Entwicklung beginnen. Jede Story muss mit einem Minimum an Aufwand analysiert werden. Das sollte in der Weekly Time Box (WTB) geschehen, die wir später besprechen werden.
3. Der Auftragsbestand sollte ereignisgesteuert sein und einen Bestellpunkt enthalten.
4. Prioritätensetzung auf Abruf. Der ideale Arbeitsplanungsprozess sollte dem Team immer die besten Dinge zur Verfügung stellen, an denen es als nächstes arbeiten kann, nicht mehr und nicht weniger.

Neben der Backlog-Spalte befindet sich die Tasking-Spalte, in der es immer mindestens eine Story geben sollte, die beauftragt ist (ein Mindest-WIP-Limit). Wenn dies nicht der Fall ist, wird das Team nach dem Standup eine Aufgabe erstellen, um diese Bedingung zu erfüllen. Eine Story wird aus dem Backlog entnommen und vom Team mit einer Aufgabe versehen. Tipp: Legen Sie die Aufgabenkarten auf die Rückseite der Story-Karten. Die nächsten Spalten sind die Spalten für die Umsetzung. Jedem Team steht es frei, notwendige Spalten hinzuzufügen, zu entfernen oder zu ändern, damit sie zum Unternehmen passen. In den Realisierungsspalten sollte eine maximale Anzahl von Stories angegeben werden, an denen gearbeitet wird. Wenn die Höchstzahl nicht erreicht ist, kann eine Story aus der Aufgabenspalte herausgezogen und auf der Umsetzungsspur ausgeklappt werden. Jetzt kann das Team an den Aufgaben der Story arbeiten. Jede Aufgabe, die umgesetzt wird, kann auf die Lane 'fertig' verschoben werden. Wenn alle Aufgaben für eine Story erledigt sind, kann die Story auf die nächste Lane verschoben werden. Wenn die Geschichte und die Aufgaben fertig sind, können die Karten an den rechten unteren Rand des Spielfelds verschoben werden, so dass eine neue horizontale Spur für die nächste Geschichte verfügbar ist. Scrumban: die Zeremonien von Scrum Mit Scrumban gibt es nur zwei Arten von Besprechungen: das tägliche Standup und den wöchentlichen Timeblock. Der Weeky Timeblock ist eine wiederkehrende Besprechung, die für mehrere Zwecke genutzt wird. Er sollte in der Mitte der Woche angesetzt werden. Der große Vorteil des wöchentlichen Timeblocks ist, dass die Entwickler nur einmal pro Woche von ihrer Arbeit abgelenkt werden (anstelle der verschiedenen Meetings bei Scrum). Der Wöchentliche Zeitblock besteht aus drei Teilen. Zunächst gibt es eine Demo der geleisteten Arbeit. Zweitens gibt es einen Rückblick auf den Entwicklungsprozess der letzten Woche. Drittens sollte das Team eine Vorschau auf die bevorstehenden Arbeitsaufgaben erhalten. Das Team versucht, die Intention der einzelnen Aufgaben zu verstehen und Feedback zu geben. Die einzige Größenangabe, die ein Team machen muss, ist, ob die Story klein, mittel oder groß ist. Vermeiden Sie die Verwendung von Pokerkarten/Story Points, die zu feinkörnig und zu vage sind. Fazit Scrumban ist eine Mischung aus den Scrum-Zeremonien und der Kanban-Methode. Mit Scrumban können wir

1. Führen Sie den wöchentlichen Zeitblock (WTB) ein. Die wöchentliche Zeitsperre sollte etwa 4 Stunden betragen und es gibt keine weiteren Treffen
2. Haben Sie einen breiteren Lebenszyklus einer Geschichte: 'vom Konzept zum Geld'.
3. Ändern Sie das Scrumboard in Unternehmensabläufe und vermeiden Sie das Push-Prinzip eines Sprints, sondern verwenden Sie einen Pull-Mechanismus.