Sonntag, 28. Februar 2021

Kommentierte Links (LXXII)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Willem-Jan Ageling: Does Scrum’s Product Owner Really Exist?

Auf den ersten Blick eine unverständliche Frage. Product Owner findet man mittlerweile in gefühlt jeder zweiten IT-Abteilung, ihre Existenz dürfte also gesichert sein. Auf den zweiten Blick ist sie aber gar gar nicht so abwegig, denn bei einer radikalen Auslegung des Scrum Guide könnte man tatsächlich Zweifel haben. Besonders der im Scrum Guide stehende Satz "For Product Owners to succeed, the entire organization must respect their decisions" wird in diesem Zusammenhang immer wieder aufgeführt, häufig verbunden mit der (in den meisten Firmen völlig unrealistischen) Forderung, dass das so weit gehen müsste, dass der Product Owner sich gegebenenfalls ohne Rücksprachen entscheiden könnte das Produkt einzustellen. Willem-Jan Ageling nimmt eine solche Aussage Anlass um etwas Kontext und Realismus in die Debatte einzubringen. Das vorweggenommene Fazit: Product Owner gibt es, und Maximalforderungen sind nicht hilfreich.

Christiaan Verwijs: Don’t Scale Up. Scale Your Product Down!

Dass eine immer stärkere Aufblähung eines Produktes dazu führen kann, dass ein Team alleine nicht mehr die ausreichende Kapazität hat um es weiterzuentwickeln ist ein oft anzutreffendes Phänomen. Die häufigste Reaktion darauf ist das Hinzufügen weiterer Teams, deren gemeinsame Arbeit dann durch ein Skalierungsframework koordiniert wird (mit Bürokratie und Ineffektivität als häufiger Folge). Christiaan Verwijs hat einen anderen Vorschlag: warum nicht stattdessen das zu gross gewordene Produkt in mehrere kleine aufspalten, die dann wieder von jeweils einem Team verantwortet werden können? Passend dazu ein ähnlicher Vorschlag von Sara Estes: man kann Produkte auch gesundschrumpfen indem man Features wieder entfernt.

Jeff Gothelf: Hiring and retention is not HR’s responsibility. It’s yours.

Letzten Endes betont Jeff Gothelf hier einmal mehr, dass organisatorische Silo-Strukturen problematisch sind. Er geht aber auch darüber hinaus und zeigt eine weitreichende Konsequenz auf: wenn man nicht mehr von wenigen zentralen Einheiten abhängig sein will dann führt kein Weg daran vorbei deren Aufgaben zumindest in Teilen selbst zu übernehmen. Sein Beispiel dafür ist HR, es liesse sich aber auch auf viele andere übertragen. Wer wirklich crossfunktionale Einheiten anstrebt wird an derartigen Überlegungen nicht vorbeikommen.

Serafin Eilmes: Das Paradox der Holakratie – Wie durch Regeln Regellosigkeit entsteht

Selbst wenn es in diesem Artikel in erster Linie um Holokratie geht - das grundlegende Phänomen das Serafin Eilmes hier beschreibt lässt sich auch in nahezu jeder grösseren Organisation wiederfinden. Sobald der Umfang der Regeln die die Mitarbeiter zu befolgen haben eine bestimmte Schwelle überschreitet ist es für sie nicht mehr möglich den Überblick über alle Vorgaben zu behalten von denen sie betroffen sind. Im schlimmsten Fall ist die Menge der Vorschriften sogar so gross (und ggf. so verstreut gespeichert), dass es nicht mehr mit vertretbarem Aufwand möglich ist sie auf Relevantes zu durchsuchen. Die Folge: obwohl umfangreiche Regelwerke bestehen kommt es immer wieder vor, dass die regulierten Personen sich über deren Inhalt oder sogar Existenz im Unklaren sind. In Folge dessen wird einfach ein irgendwie sinnvoll scheinender Weg gewählt, der aber im Zweifel ein unbewusster Regelverstoss ist.

Marcus Raitner: Wissensarbeiter in der Autonomiefalle

Bereits letzten Oktober habe ich in einem Artikel von Cal Newport einen Denkanstoss bekommen. Newport geht davon aus, dass das von Peter Drucker eingeführte Führen mit Zielen (Management by Objectives) oft zu positiv gesehen wird, weil es in der Realität immer wieder dazu führt, dass Angestellte mit Zielen überhäuft aber mit der Umsetzung alleingelassen werden. Nachdem ich zwar die Absicht hatte darüber zu schreiben, es aber monatelang vor mir hergeschoben habe, ist mir Marcus Raitner jetzt zuvorgekommen. Besonders zwei der von ihm erörterten Aspekte finde ich wichtig: zum einen ist das was heute unter dem Namen Management by Objectives stattfindet nicht mehr das was Drucker erreichen wollte, aber zum anderen kann die Nutzung von iterativen Ansätzen wie Scrum dafür sorgen, dass es wieder dazu wird.

Donnerstag, 25. Februar 2021

Kanban University veröffentlicht 'Official Kanban Guide'

Bild: Pixabay / 5138153 - CC0 1.0

Etwas überraschend rauschte gestern eine Meldung durch die agilen Filterblasen: die Kanban University hat einen neuen Leitfaden veröffentlicht, genannt "The Official Guide to The Kanban Method". Auf der einen Seite ist das begrüssenswert, inhaltlich scheint es sich um eine kompakte und hilfreiche Zusammenfassung für Einsteiger zu handeln. Auf der anderen Seite gibt es aber einige Anmerkungen und Fragen.



Um mit der wichtigsen Anmerkung anzufangen: das Dokument mag zwar vom Namen her wie ein offizielles Grundlagenwerk der Methodik erscheinen, es ist aber alles andere als das. Anders als im Fall von Scrum oder SAFe gibt es bei Kanban weder einen eindeutigen Urheber noch einen "governing Body" der sich von allen anerkannt um die Weiterentwicklung kümmert. Die Kanban University ist (polemisch gesagt) eine Gruppe von Leuten mit einer Meinung. Das macht die Inhalte des Kanban Guide nicht falsch, sie sind aber nicht vergleichbar gültig wie die des Scrum Guide.


Sachlich und fachlich ist dagegen wenig auszusetzen. Nach einer leicht haarspalterischer Überlegung ob Kanban Methode oder Framework ist folgen die Praktiken Visualize, Limit Work in Progress (WIP), Manage Flow, Make Policies Explicit, Implement Feedback Loops und Improve Collaboratively, Evolve Experimentally, es wird anhand einer Autobahn-Metapher die grundlegende Vorgehensweise erklärt und am Ende gibt es noch Ratschläge für Einführung, Board-Designs, WIP Limit-Umsetzungen, Metriken und Produktionszyklen.


Vom Umfang her ist der Kanban-Guide angenehm überschaubar geworden, er hat lediglich 14 Seiten (einmal mehr dürfte der Scrum Guide hier die Benchmark gewesen sein). Bedenkt man, dass dazu auch Deckblatt und Inhaltsverzeichnis gehören und dass Überschriften, Footer und Grafiken grossen Platz einnehmen sind es sogar noch weniger. Apropos: die grafische Gestaltung ist wie immer Geschmackssache, mit vielen Farben und Comic-artigen Grafiken ist sie aber zumindest gewöhnungsbedürftig.


Etwas verwirrend ist, dass die Kanban University jetzt zwei "Guide" genannte Dokumente hat, neben dem hier besprochenen "offiziellen" Guide auch den älteren Essential Kanban Condensed Guide, der dazu trotz seines Namens deutlich umfangreicher ist als der neue Leitfaden. Genau wie der neue lässt sich auch der alte Guide noch von der Website der herunterladen und es gibt noch keine Aussage dazu ob er weiterhin gilt oder durch seinen Nachfolger obsolet geworden ist.


Alles in allem kann man sagen, dass der "Official Guide to The Kanban Method" ein handliches und für Einsteiger sicher nützliches Dokument geworden ist, bei der die Einführung begleitenden Kommunikation währe aber etwas mehr Klarheit wünschenswert gewesen. Andererseits dürfte sich das in der näheren Zukunft problemlos nachholen lassen.

Dienstag, 23. Februar 2021

Kein Richtiges im Falschen

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

Es gibt einige hochproblematische Denk- und Handlungsmuster die mir in mittlerweile mehr als zehn Jahren Unternehmensberatung und Agile Coaching immer wieder aufgefallen sind, sowohl bei Kunden als auch bei anderen Beratern. Eines davon durfte ich mir vor kurzem auf einer Rede auf einer Branchenveranstaltung wieder anhören. Da es schwerwiegende Auswirkungen haben kann lohnt sich ein näherer Blick.


Die zentrale These lautete, dass Hochleistungsteams in grossen Unternehmen nur bestehen können wenn sie permanent gegen Regeln verstossen. Alles - Machtstrukturen, Kommunikationswege, Organisationsaufbau und Arbeitsabläufe - wäre dort so leistungsfeindlich, dass Leistung nur im unbeachteten Hintergrund stattfinden könnte. Die Aufgabe von Managern müsste es daher sein, diese "verborgenen Inseln der Höchstleistung" zuzulassen und sie gegen Entdeckung und Anpassung an die geltenden Regeln zu verteidigen.


Puh. There is a lot to unpack here, wie die Amerikaner sagen würden. Zunächst die Ausgangslage: offensichtlich kannte der Redner1 aus seiner Arbeit vor allem hochgradig dysfunktionale Organisationen. Dass es die gibt ist unbestritten, und dass er überwiegend dort gelandet ist, ist Pech für ihn. Sein erster Denkfehler ist allerdings, dass er aus seiner lediglich anekdotischen Evidenz eine generelle Regel ableitete (von der ich nicht glaube, dass sie stimmt). Aber gut, gehen wir den Gedankengang mit und tun wir so als wären alle Firmen leistungsfeindlich.


Der zweite Denkfehler baut auf dem ersten auf: nicht nur ist in ihm die Ausgangslage überall gleich schlimm, sie ist auch nirgendwo zum Besseren veränderbar, weil die Regeln (und das sie durchsetzende Management) diese Verbesserung verhindern würden. An dieser Stelle ist vieles problematisch - etwa das Menschenbild, der Determinismus, die durchscheinende Untertanenkultur. Auch hier glaube ich nicht, dass die Annahme stimmt, aber nochmal, gehen wir den Gedankengang mit.


Der dritte (auf den beiden vorigen aufbauende) Denkfehler ist der bei dem es wirklich gefährlich wird: da in dieser Weltsicht die Situation überall gleich dysfunktional ist und da niemand das ändern will (oder kann) bleibt nur noch der bewusste Regelverstoss als einzige Handlungsoption übrig. Warum das gefährlich ist dürfte offensichtlich sein - sobald einmal eine Erziehung zur Normverletzung stattgefunden hat werden mit hoher Wahrscheinlichkeit auch sinnvolle Regeln umgangen werden, und vielleicht sogar Gesetze. Das Ergebnis ist Nihilismus.


Was in der Gesamtsicht dieser Denkfehler erkennbar wird ist das Risiko in das man sich begibt wenn man toxische Rahmenbedingungen nicht ändern will (oder sie für unveränderbar hält) und stattdessen versucht innerhalb dieses Rahmens nur das zu optimieren was von ihm nicht vorgegeben wird. Da bei diesem Vorgehen der Root Cause, also der Ursprung des Problems, nicht angegangen wird, bleiben dessen Auswirkungen bestehen und kontaminieren letztendlich auch die gut gemeinten lokalen Optimierungen.


Auf den Punkt gebracht wurde diese Erkenntnis bereits in den 40er Jahren vom Philosophen Theodor W. Adorno mit seinem mittlerweile geflügelten Wort "Es gibt kein richtiges Leben im falschen",  mit dem er (vereinfacht gesagt) aussagte, dass man sich auch noch so gut gemeinte lokale Verbesserungen eigentlich sparen kann wenn sie in einem dysfunktionalen Gesamtsystem stattfinden. Auf das oben genannte Beispiel übertragen: wer die "verborgenen Inseln der Höchstleistung" vor der toxischen Umwelt versteckt statt diese Umwelt zu reparieren verbessert damit nichts.


Um zum Abschluss zu kommen: warum die hier erläuterten Denk- und Handlungsmuster hochproblematisch sind dürfte jetzt klar sein, dass sie weit verbreitet sind dürfte aber leider auch zutreffen2. Sich dieses Thema bewusst zu machen kann ein zentraler Faktor für Erfolg oder Misserfolg von Verbesserungsvorhaben sein - nicht zuletzt deshalb weil man dann alle Berater und Agile Coaches die nur am Richtigen im Falschen arbeiten wollen sanft auf die Unsinnigkeit ihres Tuns hinweisen kann.



1Keine Nahmensnennung, weil ich ihn weder an den Pranger stellen noch beruflich schädigen will.
2Ja, auch nur anekdotische Evidenz, aber immerhin basierend auf einem Jahrzehnt Beratungserfahrung.

Donnerstag, 18. Februar 2021

The Secrets of High Performing Technology Organizations

Mit Aussagen wie "das Erfolgsgeheimnis von ..." sollte man zwar immer vorsichtig sein, aber das was Jez Humble hier erzählt hat nicht nur Hand und Fuss sondern auch eine solide Datenbasis. Mehr als 31.000 Teilnehmer haben dem DevOps Research & Assessment-Program ihre Daten zur Verfügung gestellt, man kann also davon ausgehen, dass das Ergebnis Relevanz hat.



Ebenfalls zu empfehlen sind neben dem Video auch die Inhalte der weiter oben verlinkten Website. Zum einen ist das eine dort zu findende interaktive Visualisierung verschiedener Erfolgsfaktoren, zum anderen aber auch verschiedene Studien und Paper. Zu empfehlen ist besonders dieses hier. Wer mag kann hier eine Erkenntnis gewinnen die von vielen Unternehmen und Agile Coaches ignoriert wird: Schlanke Prozesse, Vertrauenskultur, Psychologische Sicherheit, Sinnfindung und Lernbereitschaft sind immens wichtig, in einem IT-Kontext ist aber nichts davon möglich wenn technische Exzellenz und moderne Infrastruktur fehlen.

Montag, 15. Februar 2021

Warum Agilität keine Management-Mode ist

Bild: Pexels / The Lazy Artist - CC0 1.0

Zu den Kuriositäten die einem Agile Coach immer wieder begegnen gehört die erstaunlich weit verbreitete Ansicht, dass die agilen Vorgehensmodelle nur eine Management-Mode wären. Und ähnlich wie vorher bei [hier beliebige andere Methodik einsetzen] wäre es nur eine Frage der Zeit bis sie durch die nächsten Moden abgelöst würden. Nun ja. Kann man so sehen, muss man aber nicht.


Um das Offensichtlichste zu nennen: mit einer mehr als zwanzigjährigen Geschichte seit dem Manifest für agile Softwareentwicklung (und einer nochmal dazukommenden Vorgeschichte) reden wir mittlerweile von mehr als dreissig Jahren ununterbrochen zunehmender Verbreitung und Popularität. Was sich über so lange Zeit hält kann man kaum noch als Mode bezeichnen, eher wäre es angemessen von etablierten und gefestigten Arbeitsweisen zu sprechen.


Und selbst wenn es so sein sollte, dass eine dreissigjährige Phase eine (dann sehr langlebige) Mode darstellt, zu einer Management-Mode würde es dadurch noch lange nicht. Denn selbst wenn Manager aus vielen verschiedenen Bereichen heute gut damit beraten sind sich mit diesem Thema zu beschäftigen - in ihrem Ursprung und in weiten Teilen ihrer Umsetzung haben die agilen Vorgehensmodelle wenig mit den Management-Ebenen zu tun.


Ein Grund dafür ist, dass die agilen Arbeitsweisen initial nicht konzipiert worden sind um Unternehmen zu lenken sondern von Praktikern der unteren Hierarchiestufen entwickelt wurden um die tägliche Arbeit von Umsetzungsteams einfacher zu machen. Als sich daraus dann trotzdem hierarchie- und organisations-übergreifende Ansätze entwickelten war der erste Reflex vieler oberen Ebenen diese "da unten" entstandenen Ideen als unqualifiziert abzulehnen.

 

Zur Verdeutlichung ein Ausschnitt aus dem höchst lesenswerten Artikel For Agile, It's The Best And The Worst Of Times des Wirtschafts-Journalisten Steve Denning (Forbes Magazine):

For instance, in 2014, when I attended the Drucker Forum for the first time, I was met with deep skepticism. Agile might be fine, I was told by the world’s leading management experts, for those unkempt, disrespectful software developers dwelling in the basement, or for tiny startups. But if we had learned one thing about the management through the millennia, from the great armies of Julius Caesar onwards, it was that big organizations - organizations with tens of thousands of people - could only be managed by top-down discipline. Otherwise: chaos.

Laut Dennings Analyse hat es bis ca 2016 gedauert bis sich diese Aussagen geändert haben. Für ihn hat die Agile Bewegung bis zu diesem Zeitpunkt "ein Leben in den Schatten" geführt, das obere Hierarchie-Ebenen trotz bereits erkennbarer Erfolge nur mit einer Mischung aus Amüsiertheit und Abscheu betrachteten.


In dieser Haltung kann man eine narzisstische Kränkung erkennen: dass ein nicht-Manager eine besser funktionierende Methode der Unternehmensführung entwickeln könnte als ein Angehöriger des Managements hätte in den Augen vieler Betroffener deren Position und Selbstverständnis so unterminiert, dass allein schon die Möglichkeit verdrängt und negiert wurde (btw: ironischerweise gibt es ähnliche Vorbehalte gegen agiles Arbeiten mittlerweile auch bei Software-Entwicklern). Und es geht noch weiter.


Ein weiterer sich aus seiner Entstehung herleitender Grund dafür, dass Agile kein von oben vorgegebener Hype sein kann ist dessen tiefe Verwurzelung in flachen Hierarchien und "handwerklichen Prinzipien". Ob es die über Arbeitsprozesse entscheidenden Retrospektiven der Umsetzungsteams sind (an denen Aussenstehende in der Regel nicht teilnehmen dürfen) oder Praktiken wie Pair Programming, Code Reviews oder automatisierte Deployments - Manager sind an vielen Aspekten gar nicht beteiligt.


Aufgrund dieser starken Verankerung "ausserhalb der Management-Reichweite" wird auch die typische Umsetzungsform unmöglich, mit der sonst das jeweils aktuelle Trend-Vorgehen implementiert wird. Massenveranstaltungen mit Tschakka!-Vorträgen und in Wellen durchgeführte Schulungen aller Mitarbeiter kann man zwar auch in agilen Transitionen versuchen, die angestrebten Änderungen an Verhaltensmustern und Umsetzungsdetails erreicht man so aber nur selten.


Um keine Missverständnisse aufkommen zu lassen: das alles heisst nicht, dass das Thema der Agilität für obere Hierarchiestufen unzugänglich wäre. Im Gegenteil, auch dort gewinnt es mehr und mehr Anhänger. Klar ist aber auch - durch ihre "Entstehung im Schatten" und ihre starke Verwurzelung in der Umsetzungsebene ist die Agile Bewegung zu grossen Teilen unterhalb der Management-Ebene angesiedelt, wodurch es per Definition unmöglich ist, dass es sich bei ihr um eine Management-Mode handelt.



Nachtrag:

Um auf mehrfaches Feedback einzugehen: Ich weiss nicht ob ich unklar formuliere, anscheinend ja. Nur weil ich sage, dass Agilität keine Management-Mode ist bedeutet das nicht, dass dieser Ansatz meiner Meinung nach für immer die Welt regieren wird. Das eine hat mit dem anderen wenig zu tun. Siehe auch hier.

Donnerstag, 11. Februar 2021

Agile Manifest Destiny

Bild: Wikimedia Commons / Kallahar - CC BY 3.0

Auf den Tag genau heute vor 20 Jahren machten sich siebzehn Software-Entwickler, Projektmanager und IT-Consultants aus verschiedenen Gegenden Nordamerikas auf den Weg. Ihr gemeinsames Ziel: das Hotel "The Lodge" im Snowbird Ski-Resort in Utah, wo sie eine "Leightweight Methods Conference" durchführen wollten, also eine kleine Konferenz zum Thema leichtgewichtiger (→ möglichst unbürokratischer) Vorgehensmodelle in der Software-Entwicklung.

 

In den nächsten Tagen entstand dort ein Dokument das heute als Grundstein der "agilen Bewegung" gilt, das Manifest für agile Softwareentwicklung, das in vier einfachen Gegensatzpaaren die bis heute anerkannten Grundüberzeugungen dieser Denkrichtung zusammenfasst: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. Die Veranstaltung war damit nicht weniger als der Entstehungsort einer der wichtigsten Urkunden der IT- und Management-Geschichte.


Was die Veranstaltung hingegen nicht war (und hier existiert eine weitverbreitete Falschwahrnehmung) ist der Geburtsort der agilen Bewegung, oder gar des Konzeptes der Agilität selbst. Die existierte schon deutlich früher in vielen verschiedenen Formen. Zum Teil waren diese entwickelt worden durch die Verfasser des Agilen Manifests selbst, die ja nicht aus Zufall nach Snowbird eingeladen worden sind, zum Teil lag ihre Entstehung noch weiter in der Vergangenheit.


Verkürzt zusammengefasst: Wenn man von den Frühformen bei den Römern, Mongolen und Preussen absieht begann die Entwicklung der modernen Agilität in den 80er Jahren, als Pioniere wie Hirotaka Takeuchi, Ikujiro Nonaka und Mary Poppendieck erkannten, dass konsequentes Lean Management nicht nur zu hoher Qualität bei niedrigen Preisen führte, sondern dass damit auch eine bemerkenswerte Flexibilisierung und Beschleunigung der Produktionsprozesse verbunden war. Spätestens ab 1990 wurde versucht das in die IT zu übertragen.


Aufbauend darauf entstanden in den 90er Jahren verschiedene Vorgehensmodelle in der IT, darunter die bis heute bekannten Frameworks Scrum und Extreme Programming, aber auch Lean Software Development, Feature Driven Development, Adaptive Software Development, Crystal und viele mehr. Sie verhalten sich zur Agilität wie frühe impressionistische Bilder zum Impressionismus - sie existierten schon deutlich vorher und wurden nachträglich unter diesem Begriff zusammengefasst, unter dessen Dach dann die Weiterentwicklung stattfand.


Sogar die Auswahl des Tagungsortes Snowbird hatte eine Vorgeschichte - wie man u.a. bei Martin Fowler und Rebecca Wirfs-Brock nachlesen kann fanden hier seit Mitte der 90er Jahre die "Workshops on Object-Oriented Design" statt, an denen bereits mehrere der späteren Verfasser des Agilen Manifests teilnahmen und in denen bereits Themen behandelt wurden die man heute der agilen Anwendungsentwicklung zuordnen würde.


Um nicht falsch verstanden zu werden: all das soll die Leistung der Leightweight Methods Conference von 2001 nicht herabsetzen, erst durch sie hat die Agilität ihren Namen bekommen und ist beschreibbar und popularisiert worden. Es muss aber auch klar sein, dass hier nichts grundlegend Neues erfunden wurde, sondern dass eine Bewegung die lange vorher begann hier ihren vorläufigen Höhepunkt und Durchbruch erreichte. Was danach kam waren im Wesentlichen Konsolidierung und Kommerzialisierung.


Auch deren Abwesenheit macht übrigens einen Teil des Mythos des agilen Manifests aus. Wer sich die Bilder von damals ansieht bekommt schnell den Eindruck, dass der agil-industrielle Komplex 2001 noch in einer unvorstellbar weit entfernten Zukunft lag. Keiner der auf ihnen abgebildeten Männer wirkt als wäre er auf der Jagd nach dem grossen Geld, es sind erkennbar Enthusiasten aus der Umsetzungsebene, die echte Lösungen für echte Probleme suchen. Und vielleicht ist genau dieser Geist eine zentrale Inspiration, die die "Agile Bewegung" zwanzig Jahre später in Erinnerung behalten und selbst beherzigen sollte.


hey guys, found some pics and PDFs of the Agile Manifesto meeting. Pics below. Can't upload the PDFs, so took screen snaps of them to post here. I'll upload to my site later

Gepostet von Alistair Cockburn am Montag, 26. März 2018

Montag, 8. Februar 2021

The Hammer and the Dance

Bilder: Pixabay / Valentin Tixonov / Alpcem - CC0 1.0

Wenn sich Organisationen auf die Reise in Richtung Agilität begeben ist es fast zwangsläufig, dass sie früher oder später mit der Fragestellung konfrontiert werden wie disruptiv dieser Wandel sein soll. Sollen wenige, tiefgreifende Änderungen in kurzer Zeit durchgeführt werden oder machen viele kleine. über längere Zeit gestreckte Anpassungen mehr Sinn?

 

Die auf den ersten Blick unbefriedigende Antwort lautet, dass beides richtig ist, je nach Kontext. Das ist zwar zutreffend, hilft aber nicht wirklich weiter und muss daher konkretisiert werden. Ein Ansatz mit dem man dabei arbeiten kann (einer von vielen, es gibt hier keine absolute Wahrheit) trägt den poetischen Namen "The Hammer and the Dance". Er kann tatsächlich helfen, allerdings bedarf es zuvor einiger kurzer Erläuterungen.


Ein stark disruptiver (revolutionärer) Ansatz besteht aus starken Umwälzungen. Organisatorische und personelle Umstrukturierungen gehören dazu, auch Intensiv-Trainings aller Mitarbeiter oder Verkauf/Abschaffung und Neukauf/Neubau von Anlagen, Systemen und Gebäuden. Der Vorteil an diesem Vorgehen ist, dass in kurzer Zeit viel bewegt werden kann, der Nachteil, dass bei den davon Betroffenen Ängste und Widerstände ausgelöst werden können.


Ein wenig disruptiver (evolutionärer) Ansatz besteht dagegen aus einem behutsamen, schrittweisen, einladungs-basierten Veränderungsprozess, der sich auf kleine und überschaubare (Teil-)Schritte konzentriert und von denen auch nicht zu viele gleichzeitig stattfinden lässt. Die Ergebnisse können die selben sein wie beim stark disruptiven Ansatz, die Ängste und Widerstände sind aber erfahrungsgemäss deutlich geringer. Der Nachteil ist, dass dafür viel Zeit nötig sein kann, was in dringlichen Situationen ein Problem ist.


Der Hammer and Dance-Ansatz versucht Beides zu verbinden. Entwickelt im Jahr 2020 zur Bekämpfung der Covid19-Pandemie geht er davon aus, dass es sinnvoll ist abwechselnde Phasen starker und behutsamer Eingriffe zu haben, die er als "Hammer" und "Tanz" bezeichnet. Welche dieser Vorgehensweisen als nächstes angewandt wird muss dabei von der aktuellen Situation abhängen (mehr zu Hammer and Dance in der Covid19-Bekämpfung hier und hier).


Aus Sicht eines "Agilisten" ist dieses Vorgehensmodell vor allem deshalb naheliegend weil es evidenzbasiert ist. Im ursprünglichen Kontext der Pandemiebekämpfung bedeutet das (vereinfacht gesagt), dass das Überschreiten bestimmter Infektions-Grenzwerte zu starken Eingriffen führt, die dann wieder zu behutsamen Eingriffen zurückgefahren werden wenn die Grenzwerte wieder unterschritten werden und über einen definierten Zeitraum niedrig bleiben.


Um eine Übertragung auf den Kontext einer agilen Transition vorzunehmen müsste damnach in einem ersten Schritt definiert werden welches die relevanten Werte sind die gemessen werden sollen. Das können die klassischen Zahlen aus datengetriebenen Retrospektiven sein, wie Lead Time, Cycle Time, Durchsatz, WIP-Menge oder Bug-Rate, aber auch Devops-Metriken wie Deployment Frequency, Recovery Time, Automation Rate oder System Availability.


In einem zweiten Schritt sollten die jeweiligen Grenzwerte definiert werden. Wichtig ist dabei, dass diese keinen Idealzustand darstellen dürfen. Auch unterhalb der Grenzwerte kann (und und darf) es zu suboptimalen Metriken kommen, allerdings sollte das mit kleinen, dezentralen Massnahmen behebbar sein, etwa mit Training on the Job oder durch allmähliches Refactoring nur der Systemkomponenten an denen gerade ohnehin gearbeitet wird.


In dieser Vorgehenslogik werden am Anfang der meisten agilen Transitionen einige grosse Massnahmen stehen. Wenn sich zwischen den organisatorischen Silos die Arbeit staut müssen diese neu zugeschnitten oder zusammengelegt werden, wenn Systeme ständig ausfallen muss Zeit in ihre Stabilisierung investiert werden, zu viele parallele Arbeit kann durch die Begrenzung gleichzeitig begonnener Projekte und Initiativen zurückgefahren werden, etc.


Sobald durch diese Massnahmen ein Unterschreiten der Grenzwerte stattgefunden hat kann die Verantwortung für das weitere Vorgehen dezentralisiert und auf die unteren Organisationsebenen verlagert werden. Welche der im vorletzten Absatz genannten (oder anderen) Massnahmen dort ergriffen werden sollte in der Verantwortung des jeweiligen Einheit bleiben - bis die Grenzwerte nicht wieder nach oben überschritten werden, dann müssen erneut stärkere Massnahmen erwogen werden.


Neben der Evidenzbasierung hat das Hammer and Dance-Modell noch weitere Aspekte die zu einem agilen Zielbild passen, als wichtigste seien hier die Subsidiarität und das kontinuierliche Inspect & Adapt genannt. Zu den Risiken gehört, dass in den Hammer-Phasen Selbstorganisations-Strukturen beschädigt werden und die Grenzwerte zum Setzen unrealistischer "ambitionierter Ziele" genutzt werden können. Solange die Ziele der Transformation klar formuliert sind kann man daran aber arbeiten


Zuletzt noch eine Frage die vielleicht dem einen oder anderen Leser im Kopf herumschwirrt: ist "The Hammer and the Dance" denn wirklich in irgendeinem Transformationsvorhaben im Einsatz? Die Antwort: ja, ist es. Zwar nicht unter diesem Namen, nicht immer mit der nötigen Klarheit und nicht mit explizitem Bezug auf das 2020 entwickelte Pandemiebekämpfungs-Modell, aber die Art des Vorgehens findet man immer wieder. Vielleicht wäre es Zeit ihm zur besseren Kommunizierbarkeit einen Namen zu geben. Warum nicht diesen?

Freitag, 5. Februar 2021

Die Grundlagen-Dokumente von Scrum (Update 2021)

Bild: Pexels / Suzy Hazelwood - CC0 1.0

Manchmal gibt es diese Momente: kurz nachdem ich im Sommer 2020 die Übersicht über die Grundlagen-Dokumente von Scrum erstellt hatte wurde eine neue Version des Scrum Guide angekündigt und nachdem dieser im November veröffentlich wurde folgten im Januar die neuen Versionen von Nexus und Scrum@Scale. Zeit für ein Update dieser Zusammenstellung. Dabei bin ich auch auf einige Feedbacks eingegangen, auf andere nicht. Mehr dazu ganz unten. Aber jetzt erstmal - auf in die Geschichte. Durch die folgenden Dokumente hat sich Scrum in seine heutige Form entwickelt:


Dieser von von den Wissenschaftlern Takeuchi und Nonaka verfasste Artikel über die Arbeit japanischer Fabrikteams ist das einzige Grundlagenwerk an dem die "Scrum-Väter" Jeff Sutherland und Ken Schwaber nicht beteiligt waren (statt Scrum wird auch noch vom "Rugby Approach" gesprochen). Aus heutiger Sicht beschreibt es noch nicht Scrum selbst sondern einige Prinzipien auf denen es beruht, u.a. crossfunktionale Teams und iterativ-incrementelles Arbeiten. Die 1990 erfolgte Übertragung des New New Product Development Game auf die IT durch DeGrace und Stahl war die Inspiration für die Entwicklung von Scrum in seinem heutigen Sinn, was Sutherland und Schwaber auch selbst betont haben.


Nachdem Sutherland und Schwaber Scrum in den ersten Jahren nur im Rahmen ihrer eigenen Software-Projekte einsetzten führte der Wunsch es bekannter zu machen zur Vorstellung durch die beiden auf der OOPSLA-Konferenz im Jahr 1995. Das Konferenz-Paper gilt als Initialzündung der weltweiten Verbreitung von Scrum, enthält aber vieles noch nicht was heute zentral ist. Umgekehrt sind noch Elemente vom Wasserfall-Vorgehen enthalten, etwa die Phasen "Pregame", "Game" und "Postgame". Anderes, wie der Sprint, das Sprint-Ziel, das Sprint Planning, das Sprint Review oder der Product Owner (noch als Leiter eines Product Management-Teams), existieren bereits. Scrum ist in dieser (und den nächsten) Versionen explizit ein Ansatz der Software-Entwicklung.


Dieses leicht despektierlich "Scrum-Plop" abgekürzte Gemeinschaftswerk einer ganzen Reihe verschiedener Autoren erwähnt zum ersten mal die Rolle des Scrum Masters, wenn auch noch als eine spezifische Form des Teamleiters, dem auch leitende und kontrollierende Funktionen zugeschrieben werden. Besonders interessant: zusätzlich zum Scrum Master wird auch ein (nicht genauer beschriebener) Coach erwähnt, der anscheinend zu dieser Zeit noch eine eigene Rolle war. Auch das 15-minütige Daily Scrum-Meeting taucht hier erstmals auf, genau wie das Commitment des Teams das Sprint-Ziel zu erreichen.


Das erste Buch über Scrum, gleichzeitig aber auch ein Werk das im Rückblick leicht wunderlich wirkt. Statt Scrum als eigenständigen Ansatz vorzustellen stellten Schwaber und Beedle in den Vordergrund, dass ein anderer methodischer Ansatz, Extreme Programming (XP), sich mit Hilfe von Scrum besonders gut umsetzen liesse. Hintergrund ist, dass XP um das Jahr 2000 herum populärer war als Scrum und die Verbindung dieser beiden Ansätze Scrum schneller bekannt machen konnte. Zusätzlich kannten und respektierten sich die Urheber von Scrum und XP (u.a. waren sie 2001 gemeinsam an der Entstehung des agilen Manifests beteiligt). Der halboffizielle Status einiger XP-Elemente in Scrum (User Stories, Story Points, Pair Programming) erklärt sich aus dieser Zeit.


In dieser Übersicht über die Scrum-Einführung in verschiedenen Unternehmen tauchen erstmals Skalierungs-Elemente auf. Zum Einen findet sich hier die Idee, dass auch die Management-Teams nach Scrum arbeiten können, zum Anderen wird hier zum ersten mal das Scrum of Scrums vorgestellt, ein wöchentliches Scrum-Meeting in dem sich Vertreter verschiedener Teams treffen um sich untereinander abzustimmen und die Arbeit an übergreifenden Themen zu koordinieren. Aus diesen Ansätzen entstand später das Skalierungsframework Scrum@Scale (siehe unten).


Im Vergleich zu den anderen Texten ein eher wenig wichtiger, es wird nicht wirklich etwas Neues hinzugefügt. Interessant ist aber, dass Ken Schwaber in ihm einen weiteren Aspekt aus dem Extreme Programming aufgreift: den Team-Raum (angelehnt an den Extreme Space, in dem alle Teammitglieder zusammensitzen). Mittlerweile aus dem offiziellen Teil von Scrum verschwunden ist er noch immer ein wichtiger Teil in vielen Umsetzungen.


Ein weiterer Artikel von Ken Schwaber, der diesesmal aber grössere Änderungen beschreibt. Das Sprint Planning wird unterteilt in Planning I (was machen wir?) und Planning II (wie machen wir es?). Im Daily werden die drei Fragen gestellt was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind. Erstmals findet am Ende des Sprints eine Retrospektive statt, die mittlerweile der zentrale Antrieb für den kontinuierlichen Verbesserungsprozess geworden ist und als das Scrum Meeting schlechthin gilt. Auch die später zum zentralen Abnahme-Kriterium gewordene Definition of Done wird hier erstmals erwähnt, allerdings noch eher beiläufig an verschiedenen Stellen im Fliesstext. Diese zentralen Änderungen tauchen dann auch 2004 in Schwabers Buch Agile Project Management with Scrum auf.


Selbst in der langfristigen Betrachtung ein kurioses Konferenz-Paper, gleichzeitig aber auch ein wichtiges. Der Bericht von Jeff Sutherland und seiner Frau Arline über den Einsatz von Scrum bei der Organisation von verschiedenen Kirchengemeinden ist die erste Primärquelle in der ein Einsatz des Frameworks in einem komplett IT-freien Kontext beschrieben wird. Damit nimmt es die offizielle Herauslösung von Scrum aus der Software-Erstellung um einige Jahre vorweg und bereitet den Weg für Varianten wie Hardware-Scrum, EduScrum, etc.


Ein Dokument das erst rückwirkend zum ersten Scrum Guide erklärt wurde, Sutherland und Schwaber veröffentlichten es zuerst unter dem schlichten Namen "Scrum". Es ist die letzte Version von Scrum in der sich Wasserfall-Elemente finden: zusätzlich zu den Sprint Plannings können langfristige "Release Plannings" durchgeführt werden und es gibt noch die Möglichkeit Integration und Testing in separate Sprints auszulagern. Auch die kontrovers benannten Rollen "Pig" (Teammitglied) und "Chicken" (Stakeholder) tauchen ein letztes mal auf. Der Scrum Master wird als helfender und coachender "Servant Leader" beschrieben, was erst 10 Jahre später zu "True Leader" geändert wurde. Mit der Festlegung, dass mehrere Teams ein gemeinsames Backlog haben können taucht ein weiterer Skalierungs-Aspekt auf.


Die letzten Wasserfall-Elemente verschwinden aus dem Scrum Guide, ausserdem alle spezifischen Bezüge zur Softwareentwicklung, womit Scrum auch offiziell auf andere Bereiche anwendbar wird. Auch die Pig- und Chicken-Rollen verschwinden. Das Grooming wird dagegen zu einem festen Bestandteil und die Rollen werden ausführlicher beschrieben als vorher. Im Wesentlichen entspricht diese Version von Scrum der die bis heute gültig ist, die späteren Änderungen sind kleiner.


Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.


Es werden Neuerungen und Ergänzungen in verschiedenen Bereichen eingeführt: die Teammitglieder sollen sich in den Daily Scrums nicht mehr nur fragen was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind, sondern auch welchen Einfluss das auf das Erreichen des Sprint-Ziels haben wird. Das (in manchen Ländern anstössige) Wort Grooming wird durch Refinement ersetzt. In diesem Zusammenhang wird es auch möglich Backlog-Einträgen den Status Ready zu geben, woraus die inoffizielle Definition of Ready abgeleitet werden kann. Die Teilung des Sprint Plannings in Planning I und Planning II wird aufgehoben, das Was und das Wie können jetzt beliebig erarbeitet werden. Eine kleinere Ergänzung kommt bei den Skalierungs-Aspekten dazu: mehrere Teams können eine gemeinsame Definition of Done haben.


Das erste offizielle Skalierungsframework von Scrum. Grundlage sind die beiden Skalierungs-Aspekte des Scrum Guide, die gemeinsame Definition of Done und das gemeinsame Backlog für Teams die an einem gemeinsamen Produkt arbeiten. Da gleichzeitig vorgegeben ist dass es nur einen Product Owner für ein Backlog geben darf wird daraus abgeleitet, dass der auch für alle derartigen Teams zuständig ist. Weitere Elemente sind die Aufteilung der Scrum-Meetings in jeweils einen übergreifenden und einen teamspezifischen Teil und die zusätzliche Mitgliedschaft von Experten und ausgewählten Teammitgliedern in einem übergreifenden Integration-Scrum Team, dass den anderen Teams dabei hilft sich selbst zu koordinieren. Ein sehr ähnliches, halboffizielles Framework ist Large Scale Scrum (LeSS).


Die "Scrum-Werte" Respekt, Commitment, Fokus, Offenheit und Mut werden in den Scrum Guide aufgenommen. Das ist keine vollständige Neuerung, da sie bereits 2001 im Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle enthalten waren. Ihre Wiedereinführung ist der bisher prominenteste Fall einer Scrum-Regeländerung die auf Wünsche aus der Anwender-Community zurückgeht.


Neben verschiedenen redaktionellen Änderungen gibt es drei grössere: die berühmten drei Fragen im Daily Scrum sind jetzt optional, der Scrum Master bewegt sich mehr Richtung Coach, da er nicht mehr für die Einhaltung der Scrum-Regeln sorgt sondern deren Verständnis fördert, und zuletzt muss in jeden Sprint mindestens eine Massnahme zur Verbesserung der eigenen Arbeitsweisen aufgenommen werden.


Das übergreifende Integration Team ist selbst kein Scrum Team mehr, um konkurrierende Mitgliedschaften zu vermeiden, es funktioniert jetzt eher wie ein um externe Experten erweitertes Scrum of Scrums. Darüber hinaus gibt es redaktionelle Änderungen, unter anderem um klarer herauszustellen, dass der Nexus Guide an den Scrum Guide angelehnt ist und nicht zu ihm in Widerspruch stehen kann.


Eine vergleichsweise kontroverse Neuerung. Anders als der oben erwähnte Nexus-Ansatz geht Scrum@Scale davon aus, dass das eigentliche Scrum Framework nur für einzelne Teams gedacht ist und nicht für grössere Organisationen. Skalierung funktioniert daher in diesem Modell nicht durch die Gruppierung von Teams um Backlogs und Product Owner sondern dadurch, dass es zwar übergeordnete Hierarchie-Ebenen gibt, diese aber aus Delegierten der jeweils nächstunteren Ebene bestehen, die sich auch als Scrum Teams organisieren. Dabei gibt es zwei parallele Hierarchien: die Scrum of Scrums, Scrum of Scrum of Scrums, etc. für die Scrum Master und die gleichartig gestaffelten Meta-Scrums für die Product Owner. Auf diesen höheren Ebenen entstehen auch die neuen Rollen des "Scrum of Scrums Master" und des "Chief Product Owner" (samt deren Steigerungen).


Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.


Je nach Betrachtung eine der umfangreichsten Änderungen überhaupt oder lediglich eine grundlegende redaktionelle Überarbeitung. Die offensichtlichste Neuerung ist die Einführung des Produktziels, an dem sich das Product Backlog ähnlich ausrichtet wie das Sprint Backlog am Sprint Ziel. Das Planning besteht jetzt aus drei Teilen, die den Fragen Warum, Was und Wie entsprechen. Die drei Fragen im Daily Scrum sind völlig verschwunden, ebenfalls die erst in der letzten Version eingeführte Aufnahme von Prozessverbesserungen in das Sprint Backlog. Dass Teams mit gemeinsamem Product Backlog auch einen gemeinsamen Product Owner haben müssen ist jetzt auch explizit beschrieben. Um den Eindruck konkurrierender Mitgliedschaften zu vermeiden gibt es innerhalb des Scrum Teams kein Entwicklungsteam mehr sondern nur noch Entwickler. Durch klarere Formulierung und Strukturierung ist diese Version mehrere Seiten kürzer als die letzte, dazu kommen angepasste Begrifflichkeiten, etwa True Leader statt Servant Leader.


Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt.


Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt. Darüber hinaus gibt es redaktionelle Änderungen und angepasste Begrifflichkeiten, beides mit dem Ziel, dass es genau wie bei der letzten Version des Scrum Guide zu einem geringeren Umfang und klareren Formulierungen kommen soll.


---


Honorable Mentions

Natürlich gibt es noch weitere Quellen die wertvoll für das Verständnis von Scrum sind, vor allem in Buchform. Von Schwaber und Sutherland sind das vor allem die ikonisch benannten Titel Software in 30 Days und The Art of Doing Twice The Work In Half the Time, es gibt Scrum and XP from the Trenches von Henrik Kniberg, Agile Product Management with Scrum von Roman Pichler, die Bücher von Mike Cohn, die Bücher von Craig Larman und Bas Vodde, den EduScrum Guide von Willy Wijnands und viele mehr. Sie alle haben Scrum aber nicht verändert sondern beschreiben lediglich seine Anwendungsmöglichkeiten und vermitteln bewährte Techniken und Praktiken, weshalb sie keine Grundlagen-Dokumente im eigentlichen Sinn sind (lesenswert sind sie natürlich trotzdem).


Zum Feedback zu dieser Seite

Einige Worte zu dem Feedback das ich angenommen oder nicht angenommen habe: neu in der Liste ist Scrum in Church, ausserdem auch die Übersicht über die einzelnen Versionen von Nexus und Scrum@Scale, statt wie bisher nur auf die jeweils neueste Version zu verlinken. Da die jeweiligen Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide inhaltlich zusammenhängen macht das Sinn.

Nicht aufgenommen habe ich dagegen Large Scale Scrum (LeSS), Scrum 3.0 und die Scrum-Varianten aus SAFe und Disciplined Agile (DA). Bei LeSS und Scrum 3.0 weil sie nichts Wesentliches hinzufügen was es nicht bereits von Schwaber und Sutherland gibt, bei SAFe und DA weil sie Scrum so stark beschneiden, dass das Ergebnis mit dem Original nur noch eingeschränkt zu tun hat.

Weiteres Feedback ist jederzeit willkommen, spätestens zusammen mit den nächsten Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide gibt es dann auch von dieser Seite eine neue Version in die es gegebenenfalls eingearbeitet wird.

Dienstag, 2. Februar 2021

Agile Bauprojekte (V)

Bild: Youtube / Jetfox - CC BY 3.0

Dass Tesla ein gutes Beispiel dafür ist wie man auch in Bauprojekten agil arbeiten kann hatte ich bereits geschrieben, in welchem Ausmass das der Fall ist erschliesst sich allerdings erst jetzt. Im (grundsätzlich sehr hörenswerten) Podcast The Agile Wire erzählt Joe Justice, der auf Hardware-Scrum spezialisierte Erfinder von eXtreme Manufacturing, von seiner Arbeit für Tesla, und dabei unter anderem davon wie hier "agil gebaut" wird.


Der auf den ersten Blick überraschende erste Schritt bei Bauvorhaben dieser Firma besteht in der Regel daraus, dass am Ort des zukünftigen Gebäudes, bzw. der Gebäudeerweiterung ein Zelt errichtet wird (Hauptlieferant dieser Zelte scheint die Firma Sprung Structures zu sein). Einmal darauf aufmerksam gemacht kann man derartige Behelfsgebäude in Fotos und Videos nahezu jeder Tesla-Fabrik finden. In diesem Zelt wird dann ab dem Tag der Errichtung die Arbeit durchgeführt für die das zukünftige Gebäude vorgesehen ist. Das gilt selbst dann wenn diese Arbeit aus der Fabrikmontage von Autos besteht.


Natürlich kann diese Montage noch nicht mit der Effizienz einer fertigen Fertigungsstrasse stattfinden, vieles muss noch provisorisch vor sich gehen, z.B. mit manueller Arbeit oder durch das Bewegen der Fahrwerke mit Gabelstaplern statt mit Fliessbändern. Das mag auf den Betrachter zunächst erscheinen wie ein Rückschritt in die Frühzeit der Industrialisierung, es dient aber auch einem anderen Zweck als der Effizienzzsteigerung. Es soll so von Anfang an ein funktionierender Wertstrom (→ eine Fertigungsstrasse) existieren, an den das nachträglich dazugebaute Gebäude optimal angepasst werden kann.



Diese Anpassung besteht schliesslich nicht nur daraus den bestehenden Wertstrom bestmöglich zu "ummanteln" sondern soll auch dann noch weitergehen wenn es eine Weiterentwicklung der Fertigungsstrasse in Richtung der Lean Management-typischen kontinuierlichen Flussoptimierung gibt. Mit anderen Worten: da die Fertigungsstrasse immer wieder umgebaut wird kann bei Bedarf auch das umgebende Gebäude umgebaut werden. Möglich wird das durch die Nutzung von Fertigbau-Modulen, mit denen nach und nach das Zelt ersetzt wird und die ggf. gegen andere ausgetauscht werden können.


Das Ausmass dieses Paradigmenwechsels verdeutlicht sich wenn man das hier beschriebene Vorgehen mit traditionell durchgeführten Bauprojekten vergleicht. Bei denen wird ein Gebäude gründlich geplant, über mehrere Jahre gebaut und erst nach Abschluss der Bauarbeiten eingerichtet und bezogen. Die seitdem stattgefundenen Änderungen in Organisation, Markt und Technik sind in diesem Fall kaum noch zu berücksichtigen, was oft dazu führt, dass Neubauten zwar den Bedürfnissen der Vergangenheit entsprechen, denen der Gegenwart aber nicht mehr. Der Tesla-Ansatz ist im Vergleich dazu zeitgemäss im wahrsten Sinn des Wortes.


Dass die bei Tesla übliche Art zu bauen auch ihre Nachteile haben dürfte sollte offensichtlich sein, die zu Beginn fehlende Effizienz gehört sicher dazu, der Verzicht auf ästhetisch anspruchsvolles Gebäudedesign ist ein weiterer, bei näherer Betrachtung dürften sicher noch weitere dazukommen. Wenn diese Nachteile sich im Vergleich zu der gewonnenen Effektivität und Flexibilität als nachrangig erweisen kann dieses "agile Gebäudebauen" aber zu bemerkenswerten Ergebnissen führen. Mit den Worten von Elon Musk: "Heiliger Strohsack!"