Kommentierte Links (XCVII)
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.
Für die meisten Teams mit denen ich gearbeitet habe war es normal, dass sie einen Teil der User Stories (oder anderen Aufgaben) die sie in ihre Sprints eingeplant hatten in den jeweils nächsten schieben mussten. Tatsächlich kann man so auch gute Ergebnisse erzielen, es gibt aber gute Gründe dafür es nicht zu tun und stattdessen möglichst alle Aufgaben im laufenden Sprint zu beenden. Dmitriy Blinov fasst die wichtigsten davon zusammen: Planung und Risikomanagement werden einfacher, Qualität und Reaktionsfähigkeit steigen, unnötige Aufwände gehen zurück, Kunden und Stakeholder werden zufriedener. Wenn das keine Motivationen sind, was dann?
Dass die Ukraine in ihrem Verteidigungskrieg gegen den russischen Angriff von agilen Methoden profitiert gehört zu den bemerkenswerten Phänomenen dieser Auseinandersetzung (siehe auch
hier und
hier). Julian Borger führt das an verschiedenen Beispielen noch weiter aus, von der bereits
aus anderen Berichten bekannten Drohnen-Einheit Aerorozvidka über die ebenfalls
aus den Medien bekannte Echtzeit-Aufklärungssoftware Delta bis hin zur ukrainischen Armee selbst, die durch Abbau von Hierarchien und durch direkte Kommunikation zwischen zusammenkämpfenden Einheiten immer flexibler und reaktionsfähiger wird (während die russischen Streitkräfte noch immer wie in der Sowjetunion organisiert sind).
Clausewitz wäre begeistert.
Irgendwann ist in der Putput vs Outcome-Debatte der Begriff der "Feature Factory" entstanden, einer Organisationsform der Software-Entwicklung die in ähnlich hoher Taktung neue Funktionen produzieren soll wie eine Fabrik physische Konsumgüter. Itamar Gilad fasst zusammen wie die Idee der Feature Factory entstanden ist, von den Wurzeln in der klassischen Fabrikation bis zu modernen agilen (?) Ansätzen wie SAFe. Darüber hinaus zeigt er auch die Risiken auf die mit dieser Idee verbunden sind: die Vernachlässigung des Kontakts zwischen Kunden/Nutzer und Entwicklern und als Folge dessen das unnötige Aufblähen von Funktions- und Code-Umfang durch schnell produzierte aber nicht ausreichend validierte Features (siehe auch
The Build Trap).
Waiting Time und Blocked Work kennt man vor allem aus dem Lean Management, dass es aber auch für agil arbeitende Teams Sinn macht sich damit zu beschäftigen kann man bei Steven Lemon gut nachvollziehbar nachlesen (ein Bonus sind die guten Illustrationen). Was er zurecht als zentralen Punkt herausstreicht: nicht die Wartezeiten selbst sind das Hauptproblem, sondern das dadurch entstehende Multitasking. Schliesslich wird in der Regel eine Pause überbrückt indem man mit der nächsten Aufgabe beginnt, und wenn auch die wegen einer Abhängigkeit warten muss mit der übernächsten. Sehr gut ist bei ihm auch die Verbindung zu Scrum, zu dessen Zielen schliesslich das Abbauen von Abhängigkeiten und Wartezeiten gehört.
Zum ersten mal von der Kirche/dem Kult von Scrum gehört habe ich vor ca. 10 Jahren, seitdem kommt das Thema immer wieder hoch. Tatsächlich ist der Dogmatismus mit dem mache Scrum Master auf der Einhaltung von (dann häufig auch noch falsch verstandenem) "Scrum by the Book" beharren amüsant bis verstörend, so dass man Christiaan Verwijs dankbar dafür sein kann, diesen Klassiker mal wieder hervorgeholt zu haben (Apropos Klassiker: das hier ist eine gute Gelegenheit um auch auf
diesen hier von Emily Kager hinzuweisen).