Kommentierte Links (LXXVII)
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.
Dass viele grosse Firmen mit der Zeit ihre eigenen agilen Frameworks entwickeln (und mit der Zeit weiterentwickeln oder verwerfen) ist eine verhältnismässig unbekannte Tatsache, lediglich das (oft missverstandene)
Spotify Model hat eine gewisse Berühmtheit erlangt, die anderen sind wenig bekannt. Um so interessanter ist das was Shishir Mehrotra hier vorstellt: es ist das Vorgehensmodell das bei Youtube nach der Übernahme durch Google entwickelt wurde. Erkennbar sind hier andere Frameworks integriert worden, wie z.B. OKRs und Teile von Scrum, vieles ist aber offensichtlich selbst entworfen worden und dürfte in dieser Form sicher einzigartig sein. Wie in anderen derartigen Fällen kann man auch hier nur davon abraten dieses Modell kopieren zu wollen, einige Elemente (wie z.B. das Verbot kurzfristig einberufener Meetings) sind so kontextspezifisch, dass sie an anderen Stellen eher Schaden als Nutzen anrichten würden. Eine faszinierende Fallstudie ist es aber auf jeden Fall.
Den wichtigsten Satz über die Aufwandsschätzungen nicht nur in grossen sondern in allen komplexen Projekten hat Tom Rusell fast versteckt in den Untertitel einer Absatz-Überschrift geschrieben:
"You must always involve those who will actually do the work". Alleine damit würde er einem Grossteil der derartigen Vorhaben schon weiterhelfen, er geht aber noch darüber hinaus und liefert eine ganze Reihe sinnvoller Anleitungen und Ideen. Das meiste davon erscheint wenn man es liest eher naheliegend als revolutionär, man muss sich allerdings bewusst machen, dass dieser Schein trügt - in vielen grossen Organisationen werden diese Praktiken eher simuliert als angewandt.
Übrigens - um zu zeigen, dass dieser Ansatz zwar funktionieren kann, er aber auch er keineswegs der einzige oder beste ist, ist hier eine völlig andersartige Fallstudie:
No Estimates at Scale in the US Federal Government.
Hinter der Abkürzung BAPO stehen die Begriffe Business, Architecture, Process und Organisation, sinngemäss übersetzbar mit Geschäftszielen, IT-Architektur, Arbeitsabläufen und Organisationsstruktur. Dass Jason Yip geht davon aus, dass diese Teilsysteme in dieser Reihenfolge geändert werden müssen wenn die Umstrukturierung einer Organisation wirklichen Erfolg haben soll. Den häufiger anzutreffenden Ansatz direkt von den Geschäftszielen zur Änderung der Organisationsstruktur überzugehen hält er für weniger sinnvoll, da dieses Vorgehen dazu führt, dass die neue Ablauforganisation nicht mehr mit den IT-Systemen kompatibel ist, da diese ja auf die alte Struktur optimiert wurden (
→ Conway's Law). Als jemand der sowohl gelungene als auch misslungene Transformationsversuche miterlebt hat kann ich dem nur aus voller Überzeugung zustimmen.
Wieder mal ein bisschen Meta-Content. Jeff Patton reagiert mit diesem Artikel auf zwei weitere Artikel (
hier und
hier) die etwas früher von Marty Cagan geschrieben worden. Die Synthese in die er die beiden Inhalte mit seinem seit einiger Zeit vorgetragenen
Zweifel an der agilen Produktentwicklung (des Jahres 2001) zusammenführt ergibt eine umfassende Kritik daran, dass die Software-Industrie im speziellen, aber auch der Markt und die Menschheit im Allgemeinen zu stark auf Output focussiert sind und zu wenig auf Outcome. Das ist zwar weder neu noch unstrittig, es ist aber anschaulich beschrieben und pointiert präsentiert, so dass es einen guten Anstoss für Diskussionen bietet. Denn selbst wenn man nicht in jedem Aspekt mit ihm übereinstimmt - er weist hier definitiv auf ein Thema hin über das man nachdenken sollte.
Für alle Fans resilienter Organisationen und für Anhänger des Chaos Engineering hat Danieö Lebrero eine Idee die man sofort bei sich selbst ausprobieren kann: Jeden Montag wird ein Mitarbeiter ausgelost das seinem Team in der nächsten Woche nur in absoluten Ausnahmefällen zur Verfügung steht und sonst ausschliesslich an einem kleinen Sonderprojekt arbeitet. Der angestebte Effekt ist eine höhere Ausfallsicherheit und Crossfunktionalität, entweder dadurch dass die Teams sich auf mögliche Ausfälle vorbereiten oder dadurch, dass der Ausfall eintritt und die verbleibenden Kollegen jetzt auch die Tätigkeiten übernehmen müssen die bisher immer der jetzt abwesende Spezialist übernommen hat. Die Spannung bei der Verlosung gibt es gratis dazu.
