Kommentierte Links (CXIX)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Donnerstag, 31. Oktober 2024
John Utz: Delete to Accelerate: Transforming Your Product with a Reverse Roadmap
Weniger ist mehr, das gilt in vielen verschiedenen Kontexten, aber ganz besonders im Umfeld agiler Produktentwicklung. Kleinere Anforderungen lassen sich schneller umsetzen, kleine Anwendungen einfacher umbauen oder erweitern, kleinere Systeme einfacher betreiben. Um in diesen Zustand zu kommen, empfiehlt John Utz eine zweite, parallele Roadmap. Während in der ersten das Hinzufügen von Features, etc. im Mittelpunkt steht, konzentriert sich die zweite auf das Verschlanken. Doc Norton: Opportunity Solution Trees
Ich bin grosser Fan davon, Change Management in Form von kleinen, überschaubaren Experimenten durchzuführen, aus ähnlichen Gründen wie den weiter oben genannten. Aber wie behält man dabei den Überblick über alle Ausgangshypothesen, Validierungsschritte und Ergebnisse? Doc Norton stellt mit dem Opportunity Solution Tree ein mögliches Werkzeug vor, in dem man nachvollziehen kann welche Experimente mit welchen Ergebnissen stattgefunden haben.Stefan Kühl: Disruption
Mal wieder ein "akademischer Rant" von Stefan Kühl, der als Soziologe eine eigene und distanzierte Sicht auf Manager, Berater und ihre Moden hat. Diesesmal ist die Postulierung einer im Vergleich zur Vergangenheit angeblich einzigartigen Disruption Gegenstand seiner Kritik, und wer seine Beiträge kennt, der weiss auch bereits, wie sein Fazit lautet: so einzigartig ist die aktuelle Situation gar nicht. Es sind andere Disruptionen als früher, aber keine schwerwiegenderen.Montag, 28. Oktober 2024
How Money Flows Trump Conway's Law
Conway's Law ist ein grosser Klassiker wenn es darum geht, die Zusammenhänge zwischen Organisationsstruktur und Software-Architektur zu erklären (oder aufzuzeigen, dass die überhaupt existieren). Ian Miell macht zu Recht darauf aufmerksam, dass diese Ableitung der Architektur aus der Struktur aber nur ein unvollständiges Bild bietet - auch die Struktur orientiert sich nämlich an etwas, und zwar an den Finanzströmen des Unternehmens. Mit anderen Worten: die Gestaltung der Finanzströme definiert über die Organisationsstruktur die Software-Architektur.
Über diese Erkenntnis hinaus geht Miell aber noch weiter und erklärt anhand von realen Beispielen, wie die Finanzströme mit Projekten, Produkten, DevOps, Site Reliability Engineering und Unternehmenspolitik zusammenhängen. Ein grosser Rundumschlag, aber ein lohnender und aufschlussreicher.
Donnerstag, 24. Oktober 2024
Schrödinger's Agile
Es ist gerade wieder eine dieser Phasen, in denen der "State of Agile" lebhaft diskutiert wird. Auf der einen Seite werden fehlgeschlagene agile Transitionen und die Entlassung der Scrum Master in manchen Unternehmen als neuer Beleg für die seit ca 2005 periodisch auftauchende "Agile ist tot"-These genommen, auf der anderen Seite werden verschiedene Transitions-Erfolgsgeschichten und die zahlreichen Scrum- und Agile-Stellenausschreibungen als Beweis des Gegenteils betrachetet.
In meiner Wahrnehmung sind beide Standpunkte richtig, und zwar nicht so, dass die Wahrheit in der Mitte liegt. Genau wie Schrödingers Katze ist agiles Arbeiten gleichzeitig tot und am Leben, für beides gibt es eindeutige Anzeichen. Und genau wie im Fall von Schrödingers Katze wird eine konkrete Überprüfung eines einzelnen Sachverhalts zwar für diesen Einen eine Antwort für die Frage tot oder lebendig bringen, die aber die grundlegende Gleichzeitigkeit nicht auflöst.
Werden wir etwas konkreter. Über die Zeit haben sich verschiedene Spielarten der "real existierenden Agilität" herausgebildet, deren aktueller Zustand höchst unterschiedlich sein kann. Nimmt man die jeweils für sich genommen unter die Lupe, kann alles dabei sein, von erstaunlich lebendig bis kurz vor dem Ableben. Diese Einschätzungen sind alle natürlich hochgradig subjektiv, wobei ich schon glaube, durch Kunden, Akquise und Meetups einen überdurchschnittlich breiten Einblick zu haben.
Technische Agilität
Alive and kicking. Egal ob Oldschool (Extreme Programming), zeitgemäss (DevOps, CI/CD) oder avantgardistisch (Chaos Engineering, AI Driven), die technische Dimension des agilen Arbeitens ist der de facto-Standard in der Softwareentwicklung geworden. Tatsächlich tritt hier gerade ein, was ich vor fast 10 Jahren geahnt habe: die Verbreitung ist soweit fortgeschritten, dass oft nicht mehr von agiler Softwareentwicklung die Rede ist, sondern nur noch von zeitgemässer Softwareentwicklung.
Business-Agilität
Alive and kicking. Produktzentrierung, Design Thinking, Lean Startup, Business-Experimente, AB-Testing, MVPs, Low Code-Prototypen und mehr sind selbst in Grosskonzernen und traditionellen Familienunternehmen mittlerweile weit verbreitet - sogar so sehr, dass mitunter die Fach- und Marketingabteilungen ein genauso gutes, manchmal sogar besseres Verständnis von Agilität haben als die IT-Abteilungen. Das wäre noch vor wenigen Jahren undenkbar gewesen.
Agiles PMO ("Team-Sekretariat")
Polytrauma. Ein Grossteil der Agile Coaches und Scrum Master dieser Welt hat leider das Klischee erfüllt, vor allem Meetings zu moderieren, Jira zu konfigurieren und die Teamkalender zu verwalten. Darin wird in vielen Firmen, aber auch in vielen Teams, kein Mehrwert mehr gesehen, und auch die Betroffenen selbst sind meistens unglücklich. Viele Entlassungen haben hier stattgefunden. Dort wo es "agile PMO-Kräfte" noch gibt, haben sie in der Regel zwei, drei oder noch mehr Teams zu betreuen.
Agiles Hands Off-Coaching
Tot. Bis zur Corona-Pandemie hat es einen weit verbreiteten Typ von Agile Coaches und Scrum Mastern gegeben, der durchgehend mit dem Team zusammensass, wenig selbst gemacht hat, aber regelmässig Beobachtungen geteilt und Feedback gegeben hat. Das war auch deutlich wertvoller als man auf den ersten Blick denken könnte, hat aber durch den Umschwung zur Remote-Arbeit 2020 schlagartig aufgehört zu funktionieren und zu existieren.
"Agiles" Life Coaching / Personal Coaching
Mausetot. Während der zuletzt genannte Typ für wertstiftendes Feedback mindestens ein Grundniveau an Wissen über Softwareentwicklung, Projektmanagement und Produktmanagement gebraucht hat, gab es daneben einen weiteren weitverbreiteten Typ, der dieses Wissen weder hatte noch wollte, und sich stattdessen auf (häufig ungefragtes) Life Coaching und Personal Coaching beschränkt hat ("Was macht das mit Dir?"). Diese Personen gehörten nicht nur in Krisenzeiten zu den ersten Personalabbau-Zielen.
Esoterisches Agile Coaching
Mausetot. Bei diesem Typ von Agile Coaches und Scrum Mastern fragt man sich rückwirkend, wie die sich jemals in nennenswerter Menge am Markt etablieren konnten. Pseudo-wissenschaftliche Ansätze wie neurolinguistische Programmierung, Eneagramme und Spiral Dynamics und extreme Überspitzungen grundlegend sinnvoller Konzepte, wie z.B. von gewaltfreier Kommunikation, waren schon immer schwer zu vermitteln, mittlerweile sind sie es gar nicht mehr.
Agiles Hands On-Coaching
Auf dem Weg der Besserung. Im Rahmen mancher Personalabbauprogramme sind zahlreiche agile Methodiker, die einen guten Job gemacht haben, mit den zuvor genannten in einen Topf geworfen und entlassen worden. In vielen Fällen ist danach aufgefallen, was plötzlich fehlt, so dass diese Stellen wieder aufgebaut wurden. Und bei vielen weiteren war die Wertschätzung so gross, dass ihre Positionen behalten konnten (wenn auch z.T. mit geändertem Jobtitel aber ähnlichen Aufgaben).
Agiler Zertifizierungsmarkt
Polytrauma. Über lange Jahre waren die Scrum-, SAFe- und Kanban-Zertifizierungslehrgänge sowohl Einnahmequelle als auch Vertriebskanal für viele Agile Coaches und agile Beratungen. Seit einiger Zeit wird der Wert dieser Zertifikate aber immer kritischer gesehen, während gleichzeitig immer neue Anbieter ein Überangebot geschaffen haben. Da für viele Zertifizierungs-Lizenzen eine Mindestmenge an Trainings nötig ist, sind die mitunter nur noch schlecht gebucht und dadurch ein Verlustgeschäft.
Agil-industrieller Komplex
Alive and kicking. Die meisten agilen Idealisten würden es sich anders wünschen, aber dem agil-industriellen Komplex geht es erstaunlich gut. Die Konzerne schmeissen zwar nicht mehr ganz so viel Geld aus dem Fenster um agile (Pseudo-)Transitionen und Skalierungsvorhaben durchzuführen, die Einführung von SAFe oder dem Spotify Model in Grossorganisationen ist aber immer noch ein solider Business Case, und das vermutlich noch lange.
Agile beyond IT
Den Umständen entsprechend. Die Zeit in der auch Einheiten wie HR, Hausmeisterdienst und Rechtsabteilung unbedingt Sprints, Dailies und OKRs haben wollten sind zwar vorbei, auf der anderen Seite haben Firmen wie Mercadona, Cleveland Clinics und SpaceX agile Praktiken weit aus der Softwareentwicklung herausgeführt und gelten in ihren Branchen sogar als Vorbilder. Darüber hinaus tritt Agilität unter z.T. anderem Namen noch in vielen weiteren Bereichen unentdeckt auf.
Was durch diese Übersicht klar wird: pauschale Aussagen wie "Agile ist tot" oder "Agile hat gewonnen" gehen an der vielschichtigen Realität vorbei.1 Und diese Situation wird dadurch, dass es zwischen einzenlen Unternehmen grosse Unterschiede gibt, nochmal vielschichtiger. Aus einer gewissen Distanz betrachtet muss man also grundsätzlich davon ausgehen, dass agiles Arbeiten sowohl lebendig als auch von uns gegangen sein kann. Was stimmt, sieht man nur im Einzelfall.
Montag, 21. Oktober 2024
Loose Coupling
Zu den Begriffen an denen man bei der Beschäftigung mit agilen Zielsetzungs-Systemen (OKRs, Sprint Goals, etc.) früher oder später vorbeikommt, gehört auch das Loose Coupling (ins Deutsche übersetzt die lose Koppelung). Beschrieben wird das meistens damit, dass über- und untergeordnete Ziele und Massnahmen nicht zu fest miteinander verbunden sein sollen (das wäre Tight Coupling, bzw. enge Koppelung) - aber warum will man diese enge Verbindung eigentlich oft nicht?
Zum besseren Verständnis hilft es, sich Zielsetzungssysteme anzusehen, die umgekehrt gestaltet sind, in denen also Tight Coupling stattfindet. Das sieht meistens so aus, dass die untergeordneten Ziele und Massnahmen fest definierte Teilmengen der übergeordnetend sind, was zwei Folgen hat: zum einen müssen sie alle erfüllt werden um das übergeordnete Ziel zu erreichen, zum anderen sind sie so eng miteinander verbunden, dass sie sich gegenseitig beeinflussen.
Wenn das übergeordnete Ziel z.B. die Gründung einer neuen Niederlassung ist, und davon das Mieten eines Gebäudes, die Einrichtung der Arbeitsräume und die Anstellungung von geeignetem Personal abgeleitet werden, dann ist das eine enge Koppelung. Sollte eine einziges dieser Unterziele oder der dazugehörigen Massnahmen scheitern oder sich deutlich verzögern, wäre auch das übergreifende Gesamtziel in gleicher Art davon betroffen.
Drehen wir es um, wie würde hier eine lose Koppelung aussehen? Das übergreifende Ziel könnte z.B. sein, die neue Niederlassung möglichst schnell arbeitsfähig zu bekommen. Abgeleitet davon könnte man die Onboarding-Handbücher verbessern, einen Bonus für bestehende Kollegen ausloben, die sich zeitweise versetzen lassen um die neuen einzuarbeiten, oder temporär mehr Home Office erlauben. Man sieht an diesen Beispielen: wenn sie nicht gelingen sollten, wären die Folgen weit weniger tiefgreifend.
Noch einmal einfacher ist das Loose Coupling in der digitalen Produktentwicklung. Wenn z.B. das Ziel ist, die Zeit die man in einem Genehmigungsportal verbringen muss zu reduzieren, können verschiedene Entwicklungsteams völlig unterschiedliche Ideen einbringen: besseres UX-Design, schnellere Ladezeiten, hilfreiche Chatbots, etc. Alle diese Ideen tragen zum übergeordneten Ziel bei, untrennbar mit ihm verbunden sind sie aber alle nicht, und untereinander auch nicht.
Durch diese Gestaltung wird etwas möglich, was in jeder ernsthaften Bemühung agil zu Arbeiten enthalten sein sollte: autonome, selbstorganisierte Teams. Durch das Vorgeben der übergeordneten Ziels wird sichergestellt, dass sie im Sinn der Gesamtstrategie arbeiten, mit welchen untergeordneten Ziele und Massnahmen sie das machen und auf welche Art und Weise sie diese umsetzen liegt aber bei ihnen (natürlich müssen dafür bestimmte Vorbedingungen erfüllt sein, z.B. Crossfunktionalität).
Es wird aber an dieser Stelle auch offensichtlich, an welcher Stelle Loose Coupling an Grenzen stösst: dort nämlich, wo aus technischen, juristischen oder sonstigen Gründen sehr klare Vorgaben nötig sind, die dann auch genau so erfüllt werden müssen. Andererseits handelt es sich dann bei ehrlicher Betrachtung auch nicht mehr um Zielsetzungs-Systeme sondern um Anleitungs- und Kontrollsysteme. Das wäre aber nochmal ein eigenes Thema für sich.
Freitag, 18. Oktober 2024
The agile Vice
Ein Hoch auf die Wissenschaft! Heute auf den amerikanischen Wirtschaftswissenschaftler Jason Furman, der am Peterson Institute for International Economics in Washington DC eine vielbeachtete Vorlesung zum Thema des aktuellen Zustands seines Fachgebiets gehalten hat, die den schönen Namen In Defense of the Dismal Science trägt. Daraus ist vor allem ein Aspekt interessant, der des unterschiedlichen Umgangs mit Change-Projekten duch unterschiedliche Gruppen.
In einer bewussten Vereinfachung teilt Furman alle an Veränderungen Beteiligten Menschen in zwei Gruppen ein, die er die Progressivenen ("the Liberals")1 und die Konservativen nennt. Beiden wirft er dabei ein jeweils spezifisches Laster (englisch: Vice) vor, womit er meint, dass beide Gruppen beim Umgang mit Veränderungen zu bestimmten Denkfehlern neigen, die beide dazu führen, dass es ihnen schwer fällt, für ihre Sichtweisen Mehrheiten zu gewinnen.
The way in which this happens often varies between liberals and conservatives. I am going to overgeneralize in describing what I call the “liberal vice” and “conservative vice” in policy analysis. But disclaimer: many liberals and conservatives do not suffer from these vices and moreover some liberals suffer from the conservative vice and vice versa.
Jason Furman, 2024: In Defense of the Dismal Science
The Conservative Vice
Das konservative Laster besteht darin, in allen Veränderungen vor allem die damit verbundenen Risiken zu sehen und sie in Folge dessen derartig mit Befürchtungen zu überladen, dass am Ende ein unrealistisch bedrohliches Zerrbild entsteht, aufgrunddessen alles Neue abgelehnt wird. Wie gesagt überzeichnet Furman bewusst, aber der Kern seiner Aussage ist nachvollziehbar.
The Liberal Vice
Das progressive Laster besteht darin, dass in allen Veränderungen vor allem die dadurch potentiell möglichen Verbesserungen gesehen werden, während die ebenfalls möglichen Verschlechterungen ausgeblendet oder sogar negiert werden. Das so entstehende gedankliche Konstrukt ist letztendlich genauso realitätsfern wie das Konservative.
In beiden Fällen ist das jeweilige Denkmuster mit dem Risiko verbunden, die Unterstützung aller anderen Beteiligten zu verlieren. Beim konservativen Laster, weil der Wunsch nach Veränderungen unterschätzt wird, bem progressiven Laster, weil berechtigte Sorgen und Ängste ignoriert werden. Und an der Stelle kommt jetzt die Transferleistung - lässt sich Furmas Idee der konservativen und progressiven Laster auf andere Themenfelder übertragen oder einengen? Ja, das geht.
The Agile Vice
Übertragen auf die agilen Transitionen, um die es auf dieser Seite ja im Wesentlichen geht, ist es so, dass sich vor allem ein Blick auf das progressive Laster lohnt, denn die Parallelen zu den in vielen dieser Transitionen gemachten Fehlern sind offensichtlich - so sehr, dass man in Anlehnung an Furman sogar von einem "agilen Laster" sprechen könnte.
Sowohl vom Management als auch von den "agilen Berufsmethodikern" wird die Umstellung des Arbeitsmodus auf Scrum, Kanban, SAFe und Co. meistens als ausschliessliche Win-Win-Rechnung verkauft: alles soll dadurch schneller, einfacher und besser werden und dabei auch noch mehr Spass machen als vorher. Was dabei unterschlagen wird: Agilität kommt mit einem Preis, dessen sollte man sich bewusst sein. Und er kommt oft in einer erstaunlichen Form: vielen zusätzlichen Regeln.
Wer jetzt innerlich protestiert, da er überzeugt ist, dass agiles Arbeiten keineswegs mit zusatzlichen Regeln verbunden ist, der ist dem agilen Laster bereits verfallen. Denn natürlich gibt es sie: WIP-Limits, Definitions of Done and Definitions of Reday, begrenzte Meeting-Dauern, mindestens ein Increment pro Sprint, gleichlange Sprints von maximal einem Monat Länge, kontinuierliche Integration, kontinuierliche Verbesserung, keine geteilte Product Owner Rolle, etc. Passend dazu noch einmal Jason Furman:
The more common problem is not that people who commit the liberal vice rule out too many policies because they reject anything with a tradeoff. Instead they are more likely to rule these policies in by getting the analysis wrong and denying the tradeoffs. People suffering from the liberal vice can be tempted to think that companies systematically make mistakes that, if corrected, would advance whatever other goals they have.Jason Furman, 2024: In Defense of the Dismal Science
Und spätestens hier dürfte beim Einen oder Anderen eine Selbsterkenntnis eintreten: wenn nicht alles problemlos läuft, dann liegt es nur an einer fehlerhaften Umsetzung; würden alle sich einfach verhalten wie gedacht, würde alles sofort gut werden - genau das ist es, was Agile Coaches und Scrum Master sich regelmässig gegenseitig versichern, wenn die erwarteten Verbesserungen ausbleiben und es ggf. sogar zu Verschlechterungen kommt.
Um es zu einem versönlichen Ende zu bringen - nicht jeder agilen Berufsmethodiker ist dem agilen Laster verfallen, und genau wie bei Furmans konservativen und progressiven Lastern handelt es sich dabei um eine Übertreibung. Was aber auch klar sein muss: diese Übertreibung veranschaulicht ein reales Problem, nämlich das (bewusste oder unbewusste) Ignorieren und Kleinreden des Preises, den man zahlen muss, wenn man agil arbeiten möchte.
Die Konsequenz sollte klar sein: ständiges Hinterfragen der eigenen Positionen, ständiges Überprüfen der eigenen Positionen auf Fehlannahmen, Einholen von Feedback der von den Veränderungen Betroffenen, Bereitschaft zur Einsicht der eigenen Fehlbarkeit. Oder mit anderen Worten - Anwendung von Inspect & Adapt auf die eigenen Überzeugungen. Eigentlich etwas, was im Umfeld agiler Arbeitsweisen das Normalste der Welt sein sollte.
Montag, 14. Oktober 2024
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.1
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.
Donnerstag, 10. Oktober 2024
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.
Montag, 7. Oktober 2024
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.
Donnerstag, 3. Oktober 2024
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.
