Larman's Law (IV)

Bild: Wikimedia Commons / L.C. Dwyer - CC BY-SA 4.0

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Vierte von ihnen gehen. Es lautet:

If after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing [the redefinition the new terminology to mean basically the same as status quo] and [the deriding of any other change initiative as needing pragmatic customization for local concerns], and creating the false impression ‘the change has been done’, deluding senior management and future change attempts, after which they become industry consultant.¹

Wie bei Larman's anderen Gesetzen muss man sich auch bei diesem durch eine oberste Schicht aus Sarkasmus und Zynismus arbeiten, bevor man zum eigentlichen Kern kommt, der dann aber tatsächlich seine Berechtigung hat. Verkürzt gesagt geht es in dieser Gesetzmässigkeit darum, dass in vielen Gross-Organisationen mittlere Hierarchieebenen dafür belohnt werden, Veränderungsprogramme scheinbar anzunehmen und umzusetzen, sie in Wirklichkeit aber auszuhöhlen und wirkungslos zu machen.

Dazu etwas Kontext: jede grössere Organisation ist von Innen deutlich uneinheitlicher als man von Aussen vermuten würde. Einzelne Standorte, Ressorts, Sparten oder funktionale Einheiten haben jeweils eine eigene Geschichte, eigene Kultur, eigene Ziele und eigene Sachzwänge, wegen denen es extrem schwierig ist, sie übergreifend den gleichen Organisationsprinzipien zu unterwerfen, ohne dabei Ineffizienzen, Fehlanreize oder Widersprüchlichkeiten in Kauf zu nehmen.

Gleichzeitig ist es für die Führungsebene schwierig bis unmöglich, all diese Besonderheiten zu erfassen (und diese Erfassung aktuell zu halten), geschweige denn, im Rahmen von Veränderungsprogrammen für jede von ihnen eine passende Lösung zu erarbeiten und umzusetzen. Um überhaupt handlungsfähig zu sein werden diese Unterschiede daher erstaunlich oft (bewusst oder unbewusst) ignoriert und es wird doch ein übergreifend einheitlicher Ansatz eingeführt, der dann nicht überall passt.

Das mit der Umsetzung der Veränderungen beauftragte Mittelmanagement hat in einer derartigen Situation zwei Optionen: entweder auf die Probleme aufmerksam machen oder offiziell alles mitmachen, den Spielraum der neuen Vorgaben dabei aber soweit wie möglich auszureizen, um möglichst viel beim Alten lassen zu können, um so arbeitsfähig und effizient zu bleiben. Welcher dieser Wege eingeschlagen wird, hängt dabei in der Regel an einer Frage - welcher wird von oben belohnt und welcher bestraft?

Wenn es der zweite ist, der belohnt wird, ist Larman's viertes Gesetz praktisch eingetreten. Belohnung bedeutet in grossen Organisationen nämlich meistens eine Beförderung in eine verantwortungsvollere Position, und für jemanden der Veränderungen (von aussen gesehen) erfolgreich umgesetzt hat, ist eine Beförderung in eine Position im Veränderungsmanagement naheliegend. Und da auch dort die gleichen Dinge belohnt und bestraft werden, finden auch dort die gleichen Verhaltensmuster statt.

Wie es besser ginge ergibt sich aus dieser Beschreibung fast von selbst: es müssen andere Dinge belohnt werden, wie z.B. das Aufdecken von Fehlannahmen, Übervereinfachungen und Fehlplanungen, das Aufzeigen von Konsequenzen, der Verzicht auf Beschönigungen und Scheinerfolge und die Bereitschaft, höheren Hierarchieebenen zu widersprechen. Dort wo das passiert ist die Wahrscheinlichkeit, von Larman's viertem Gesetz betroffen zu sein, deutlich geringer.

Nachtrag:

Ja, ich weiss. Ich bin nicht auf die "Industry Consultants" eingegangen. Hätte an dieser Stelle zu weit geführt. Kommt noch. Vielleicht.

¹Im Original bezieht sich dieses Gesetz mit numerischen Verweisen auf die beiden davorstehenden. Um ohne diesen Verweis verständlich zu sein sind diese beiden Gesetze  an den entsprechenden Stellen in eckigen Klammern eingefügt.

Rapid Prototyping on Steroids

Auf den ersten Blick ist das hier einer dieser Holy Shit-Momente. In gerade einmal fünf Minuten erstellt Henrik Kniberg hier mit Hilfe eines KI-Chatbots einen funktionsfähigen Prototypen einer mobile App in mehreren Versionen, samt Dokumentation und einem initialen Backlog mit den nötigen Anforderungen um daraus eine voll funktionsfähige erste Version zu erstellen. Früher wäre damit ein ganzes Team einen ganzen (Design-)Sprint lang beschäftigt gewesen, jetzt geht es in wenigen Momenten.

Wenn man weiss wie derartige Chatbots funktionieren relativiert sich die Leistung ein bisschen. Das Demonstrationsobjekt ist eine To Do-Listen-App, von denen es bereits unzählige gibt, deren Code hier Teil des Traningsmaterials der KI gewesen ist. Würde man sie dort einsetzen wo Prototypen normalerweise gebraucht werden, in der innovativen Neuentwicklung nämlich, wäre kaum Trainingsmaterial vorhanden und das Resultat wäre entsprechend wenig beeindruckend.

Trotzdem bleibt das Ergebnis dieser Vorführung natürlich beachtlich. Um das Potential dieser Technologie voll nutzen zu können, wird es darauf ankommen, zu wissen, wo sie einsetzbar ist und wo nicht. So werden sich beispielsweise die wenig innovativen Teile einer neuen Anwendung (Login, Profilseite, etc.) schnell generieren lassen, so dass mehr Zeit für die wirklich innovationsbringenden Tätigkeiten bleibt. Alleine das kann schon sehr viel bewirken.

Am Ende sollte trotzdem in jedem Fall klar sein, dass der auf diese Art entstandene Code mindestens durch ein gründliches Refactoring gehen, wenn nicht sogar neugeschrieben werden sollte, bevor er veröffentlicht wird. Wenn nicht, dürften einige unschöne Überraschungen bevorstehen. Selbst das kann im Vergleich zu einer vollständigen Selbstentwicklung aber immer noch deutlich effektiver und effizienter sein. Die Zukunft hat bereits begonnen.

Agile Bauprojekte (VIII)

Bild: Wikimedia Commons / Looniverse - CC BY-SA 4.0

Ein Massenphänomen sind sie noch immer nicht, aber die Anwendung agiler Arbeitsweisen in Bauprojekten ist mittlerweise nichts mehr was sich als unmöglich bezeichnen lässt, von Teslas MVP-Fabrikgebäuden bis hin zu "konfigurierbaren" und in Tagen errichtbaren Modulbau-Häusern gibt es zahlreiche funktionierende Beispiele. Zur Zeit wird agiles Bauen aber noch einmal einfacher, billiger und flexibler, denn eine weitere Technik ist im Bau angekommen: 3D-Druck.

Diese ursprünglich nur für Kunststoffe verwendete Technik ist mittlerweile durch technische Neuerungen auch für Baustoffe nutzbar, und ermöglicht so nicht nur die schnelle und ggf. individuelle Anfertigung von Bauelementen oder den erwähnten Modulen, sondern sogar von ganzen Gebäuden (davon ausgenommen bleiben weiterhin die Tiefbauarbeiten, und bei denen vor allem der Aushub und die Sicherung der Baugruben, die noch immer klassisch geplant und durchgeführt werden müssen).

Ein bekanntes Beispiel kann man seit 2021 in Amsterdam nicht nur betrachten sondern sogar betreten: eine ganze Brücke ist dort mit einem 3D-Drucker erstellt worden - aus Stahl. Dafür wurde schichtweise Metallpulver aufgetragen und so festgeschmolzen, dass dadurch nach und nach die Brückenform entstand. Darüber hinaus ist das ganze Bauwerk mit Sensoren versehen, die Belastungen messen und inspect & adapt ermöglichen - die nächste so gebaute Brücke wird stabiler und braucht weniger Material.

Auch Betonwände lassen sich mittlerweile schichtweise mit einem 3D-Druck-Roboter hochziehen, und auch hier können Ergebnisse in der Nähe betrachtet werden: in Heidelberg wurde 2023 das Gebäude eines Rechenzentrums mit einem Beton-3D-Drucker in nur sieben Tagen erstellt und seit 2024 steht in Beckum bei Münster das erste so entstandene Wohnhaus, dessen Bau nur zwei Wochen gedauert hat - beides ist also in einem Zeitraum fertig geworden, der einem Sprint entspricht.

Die beste Kombination aus Geschwindigkeit und Flexibilität bietet schliesslich die Kombination aus 3D-Druck und Modulbauweise. In Japan und den USA gibt es jetzt schon Baufirmen, die naben der Baustelle temporäre Fabriken errichten und in ihnen Baumodule erstellen, die dann gleich zusammengesetzt werden können. In diesem Rahmen können auch Schäden am Gebäude schnell behoben und etwahige Fehler der Planung schnell korrigiert werden. Auch hier also - inspect & adapt.

Wenn wir also über agile Vorgehensweisen in Bauprojekten sprechen, geht es nicht mehr darum, ob das überhaupt möglich ist, das ist bereits bewiesen. Auch die Genehmigung dieser Bauweise ist offensichtlich bereits da, der Bau der genannten Beispiele durfte ja stattfinden. Und was die Kosten betrifft - laut der oben verlinkten Artikel ist Bauen im 3D-Druckverfahren sogar billiger. Die Frage ist daher nur noch, warum es nicht viel öfter passiert. Vielleicht weil es noch zu wenige der dafür nötigen Roboter gibt?

Trios

Bild: Wikimedia Commons / Matthias Klein - CC BY-SA 3.0

Eine Besonderheit der Rollen in agilen Frameworks ist, dass fast immer mehrere von ihnen auf der gleichen Hierarchieebene einer gemeinsamen Organisationseinheit vorkommen, wo die Aufgabengebiete unter ihnen aufgeteilt sind. Die häufigste derartige Aufteilung ist die in Paare, v.a. mit Scrum Master und Product Owner, es gibt aber auch verbreitet so genannte Trios, also Dreiergruppen. Welche drei Rollen das sind ist aber nicht einheitlich, es haben sich über die Zeit verschiedene Varianten entwickelt.

Die drei Amigos

Die vermutlich älteste Variante eines Trios wird auch die drei Amigos genannt. Es handelt sich um eine in der Frühzeit der agilen Softwareentwicklung (vor 2010) verbreitete kleinstmögliche Form eines crossfunktionalen agilen Entwicklungsteams, bestehend aus jeweils einem Vertreter von Business, Softwareentwicklung und Qualitätssicherung. Als Vorgänger der Scrum Teams arbeiteten diese Trios vor allem an der Product Delivery also dem (agilen) Abarbeiten eines Lieferplans von Features.

Das Product Trio

Eine ähnliche, aber deutlich später (ca. 2020) entstandene Form eines kleinen, crossfunktionalen agilen Teams ist das durch Thereresa Torres popularisierte Product Trio, bestehend aus einem Product Manager, einem Designer und einem Software Engineer. Der Unterschied zu den drei Amigos ist vor allem das Tätigkeitsfeld - statt in der Product Delivery arbeiten Product Trios vor allem in der Product Discovery, also der ergebnisoffenen Neuentwicklung von Produkten.

Das TPD Trio

In gewisser Weise die skalierte Version eines Product Trio, wenn auch ca. 10 Jahre früher entstanden. Entwickelt als Teil des Spotify Models besteht ein TPD Trio aus einem Tribe Lead (Eingineering Manager), einem Product Lead und einem Design Lead, die zu dritt einen Tribe, also eine Einheit aus mehreren Squads (Entwicklungsteams) leiten. Statt selbst an der Umsetzung mitzuarbeiten erstellen sie dabei in ihrem jeweiligen Themengebiet Anforderungen und Vorgaben für die Teams.

Das ART Trio

Zu einer ähnlichen Zeit wie das TPD Trio entstanden, erfüllt das Führungs-Trio eines Agilen Release Train (ART) in SAFe zwar einen ähnlichen Zweck, ist aber anders zusammengesetzt. Neben dem Product Manager sind hier ein für die Prozesse verantwortlicher Release Train Engineer (RTE) und ein System Architect Mitglied. Im "Full SAFe" gibt es noch eine Entsprechung auf der nächsthöheren Ebene, bestehend aus Solution Manager, Solution Train Engineer (STE) und Solution Architect.

Andere Trios

Je nach Kontext können noch zahhlreiche weitere Formen von Trios bestehen, gesehen habe ich z.B. schon UX, Entwicklung und QA oder Entwicklung, Operations und Security. Wichtig ist aber in allen Varianten, dass es sich um gleichberechtigte Teile eines kleinen, crossfunktionalen Entwicklungs- oder Führungsteams handelt, die in Summe alle Aufgaben abdecken können, die zur Erledigung ihres jeweiligen Auftrages notwendig sind.

Und natürlich gibt es auch etwas grössere Einheiten, die dann Quartett, Quintett, etc. heissen können. Sie sind aber deutlich seltener anzutreffen als die Trios, die durch Product Discovery, Spotify und SAFe einen recht hohen Bekanntheitsgrad erreicht haben.