Leidet Ihr Scrum unter niedriger Produktivitaet? Ihr Problem koennte WIP sein

Es ist erwiesen, dass je mehr laufende Arbeit eine Person oder ein Team hat, desto laenger dauert es, Aufgaben abzuschliessen. Einerseits, wenn wir mehrere Aufgaben gleichzeitig erledigen und sie gleichzeitig abliefern, wird die Lieferzeit die Summe der Zeit fuer beide Aufgaben sein. Wenn wir jedoch in sequentieller Reihenfolge an den Aufgaben arbeiten, wird die erste Aufgabe frueher geliefert, und die durchschnittliche Lieferzeit wird ebenfalls geringer sein.

Darueber hinaus kann Multitasking zu Ineffizienzen fuehren, die bei der Arbeit an einer einzelnen Aufgabe nicht auftreten. Eine dieser Ineffizienzen tritt auf, wenn wir Kontextwechsel zwischen Aufgaben durchfuehren: Es wurde gezeigt, dass unser Gehirn Zeit braucht, um sich an den Kontext der neuen Aufgabe anzupassen, und diese Zeit ist nicht produktiv, sie ist ineffizient. Es gibt Zeiten, in denen wir bei einer Aufgabe feststecken und uns entscheiden, zu einer anderen Aufgabe zu springen, um den Fluss nicht zu verlieren und zu sehen, ob uns die Erleuchtung kommt, die uns entblockiert. Dies kann in einigen Faellen ein guter Ansatz sein, aber es ist wichtig, sich bewusst zu sein, dass wir jetzt zwei Kontexte im Kopf behalten muessen.

Bei der Teamarbeit bleibt dieses Problem bestehen und kann sogar verschaerft werden. Wenn wir beispielsweise an zwei Aufgaben in zwei verschiedenen Branches arbeiten und das Team Aenderungen am Code vornimmt, haben wir zwei Branches zu aktualisieren. Wenn unser Code zusaetzlich kompiliert wird, muessen wir moeglicherweise jedes Mal neu kompilieren, wenn wir den Branch wechseln, was unproduktive Zeit hinzufuegt. Wenn wir diese Zeit berechnen und mit der Anzahl der Entwickler in unserem Team multiplizieren, kann die verlorene Zeit pro Monat leicht in der Groessenordnung von Arbeitstagen liegen.

In Scrum wird zum Beispiel die laufende Arbeit (oder WIP) durch die Festlegung des Sprint-Umfangs und dessen Schutz vor Injektionen begrenzt. Wenn der Sprint zwei Wochen dauert, wissen wir, dass waehrend dieser zwei Wochen, wenn alles gut geht, keine neue Arbeit injiziert wird. Das Problem ist, dass zwei Wochen Arbeit bereits zu viel sind, wenn wir das WIP nicht gut verwalten. Scrum schreibt keine Praktiken zur Begrenzung des WIP innerhalb eines Sprints vor, nichts hindert einen Entwickler daran, an mehreren Aufgaben parallel zu arbeiten. Auch auf dem Sprint-Backlog-Board ist es nicht so offensichtlich zu sehen, wie viel laufende Arbeit es zu einem bestimmten Zeitpunkt gibt. Deshalb haben Tools wie Jira oder Clickup seit einiger Zeit Kanban-Board-Visualisierungen fuer Scrum-Sprints eingefuegt. Die Verwendung dieser Dashboards wird dringend empfohlen, da sie eine gute Sichtbarkeit des WIP und der Engpaesse bieten, die innerhalb des Sprints auftreten, in Echtzeit, ohne bis zum Ende warten zu muessen.

Aber Kanban-Boards sind nicht der einzige verfuegbare Mechanismus zur Verbesserung des Arbeitsflusses innerhalb eines Sprints. Das Ideal ist, die gesamte Kanban-Methodik zu uebernehmen, die durch die Visualisierung des Arbeitsflusses und die Begrenzung des WIP das Team bewusst macht und ihm die Verantwortung fuer die Produktionskette uebertraegt. Dies ermoeglicht es dem Team, schnell an der Beseitigung von Engpaessen zu arbeiten, sobald sie auftreten, und ein sehr gutes Gefuehl dafuer zu haben, wie der Arbeitsfluss funktioniert, damit er kontinuierlich ueberprueft und verbessert werden kann.

Wenn Kanban mit Scrum kombiniert wird, erhalten wir das sogenannte Scrumban, das die Zeremonien und die Sprint-Arbeit von Scrum mit der Beobachtbarkeit und Arbeitsflussverbesserung von Kanban vereint. Wenn Sie feststellen, dass Scrum in Ihrem Team abnehmende und mittelmaeissige Leistungen erbringt, koennte Scrumban eine gute Alternative sein, um den Trend zu aendern.