On Lean and Agility

Dieses Video von der Large Scale Scrum (LeSS)-Conference Madrid 2024 ist gleich auf mehreren Ebenen sehenswert. Zum einen weil der LeSS-Erfinder Craig Larman hier etwas sehr Sinnvolles tut: am Beispiel von Conway's Law zeigt er auf, wie sehr manche bahnbrechende wissenschaftliche Papers mit der Zeit aus ihrem Kontext gerissen und mit zusätzlicher Bedeutung aufgeladen werden, bis zu dem Punkt, an dem vieles, was sie in der Aussenwahrnehmung ausmacht, gar nicht mehr aus dem Original ableitbar ist.

Auf einer weiteres Enene kann man aus diesem Video aber auch erkennen, warum LeSS, das ja egentlich ein sehr schlankes und agiles Framework ist, mitunter in der agilen Community skeptisch gesehen wird. Sein Schöpfer ist offensichtlich sehr davon überzeugt, Recht zu haben und sehr schnell bereit, anderen vorzuwerfen, ahnungslos oder im Unrecht zu sein (in diesem Fall geht das u.a. gegen die Verfasser der Bücher Team Topologies und Dynamic Reteaming). Wird der eigene Standpunkt auf diese Art vermittelt, ist klar, warum das nicht überall auf Begeisterung stösst.

Es ist wieder soweit - ein Hoch auf die Wissenschaft! Diesesmal auf eines der in Relation zu ihrem Einfluss viel zu unbekannten Research Papers, The Ironies of Automation, verfasst 1983 von der amerikanischen Psychologin Lisanne Bainbridge. Seine Kernaussage: anders als man denken könnte führt Prozessautomatisierung nicht zwangsläufig zu mehr Effektivität oder Effizienz, stattdessen kann es sein (und das ist die Ironie der Geschichte), dass danach alle genauso stark beschäftigt sind wie davor.

Für dieses Phänomen gibt es Gründe. Zum einen führt eine Automatisierung nachvollziehbarerweise dazu, dass der jeweilige Mensch sich weniger mit seinem eigentlichen Arbeitsgegenstand beschäftigt, da diese Aufgabe ja jetzt von einer Maschine oder einem Computer übernommen wird. Sobald ein Eingreifen dann doch nötig wird (und sei es nur um zu überprüfen ob die automatisierte Arbeit richtig ausgeführt wird), dauert das aufgrund der fehlenden Erfahrung länger und ist fehleranfälliger.

Des Weiteren entstehen durch die Automatisierung neue Aufgaben, die es vorher nicht gab. Die Maschine, bzw. die Computerprogramme müssen betrieben, gewartet, repariert und modernisiert werden, was zum einen arbeitsintensiv ist, zum Anderen im Vergleich zu der früher selbst durchgeführten eigentlichen Arbeit deutlich abstrakter und monotoner, was zu nachlassender Konzentration führt, mit der erneuten Folge, dass die Wahrscheinlichkeit von Fehlern (die dann repariert werden müssen) steigt.

Zuletzt entsteht durch die Notwendigkeit, sowohl den eigentlichen Arbeitsgegenstand als auch die Automatisierungstechnik zu beherrschen, eine hohe kognitive Belastung, die auch hier wieder zur Ursache menschlicher Fehler werden kann. Dabei kann es sogar zu einer "Automatisierungs-Ironie in der Automatisierungs-Ironie" kommen, wenn zur Reduzierung dieser Belastungen konzipierte Automatisierungen durch ständige Ergebnisberichte selbst kognitiv belastend werden.

Einen einfachen Ausweg aus diesem Dilemma bietet Lisanne Bainbridge nicht, stattdessen weist sie darauf hin, dass die Lösung nur daraus bestehen kann, ein einzelfallspezifisches Optimum an Automatisierung zu finden, das jeweils bestimmt wird durch Umfang und Komplexität der Prozesse, Änderungs-Häufigkeit, (In-)Stabilität der Umgebung und des Arbeitsgegenstandes, Auswirkungsgrad möglicher Fehler und Qualifikation des jewils eingesetzten Personals.

Auch hier läuft es damit einmal mehr darauf hinaus, sich in einer unbeständigen Welt durch Inspect & Adapt kontinuierlich neu auszurichten und das für den Moment beste Vorgehen zu finden, das sich aber bereits bald wieder ändern kann. Und selbst wenn Lisanne Bainbridges Ironies of Automation sich ursprünglich auf die Frühzeit der Digitalisierung in den 80er Jahren bezogen hat, sind die Parallelen zur heutigen KI-getriebenen Automatisierung offensichtlich.

PS: eine wichtige Differenzierung - die Ironies of Automation sind klar zu unterscheiden von den oberflächlich ähnlichen Rebound-Effekten. Auch die machen die Effektivitäts- oder Effizienzgewinne von Automatisierungen wieder zu Nichte, die dahinterliegenden Mechanismen sind aber komplett andere. Mehr zu den Rebound-Effekten steht hier.

Grafik: Pixabay / Geralt - Lizenz

Joe Foley: Delete to Accelerate: Boulders, rocks, pebbles - An Agile model that scales

Cliff Berg: Empowerment, Not Self-Organization

Sean Gödeke: How I ship projects at big tech companies

Paweł Huryn: 10 Sources of Waste in Product Management

Pim de Moree: Bayer's Bold Bet: How a 160-Year-Old Giant is Liberating 100,000 People

Bild: Unsplash / Miguel A. Amutio - Lizenz

Wenn von der Gruppe aller Menschen die Rede ist, die in irgendeiner Form agil arbeiten (oder denen das zumindest zugeschrieben wird) fallen häufig Begriffe wie "die agile Bewegung" oder "die agile Community". Was damit genau gemeint ist bleibt in der Regel offen, was aber keineswegs bedeutet, dass diese Gruppe nicht beschreibbar wäre. Tatsächlich gibt es in der Wissenschaft sogar eine ganze Kategorie sozialer Zusammenschlüsse, die hier passend ist: die der sozialen Bewegungen.

Ein wichtiges Merkmal an dem soziale Bewegungen erkennbar sind, sind übergeordnete, gesellschafts-verändernde oder gesellschafts-stabilisierende Ziele. Das ist offensichtlich bei Bürgerrechts- oder Umweltbewegungen, kann aber auch in Berufskontexten stattfinden. Hier ist die agile Bewegung neben New Work sogar eine der Wichtigsten. Ihr aus dem agilen Manifest abgeleitetes grosses Ziel: die Schaffung einer besseren, humaneren, nachhaltigeren und effektiveren Arbeitswelt.

Was soziale Bewegungen ausserdem von anderen Gruppen unterscheidet, ist die nur schwer überprüfbare Zugehörigkeit. Weder wird man in sie hineingeboren (wie in Familien oder Stämme) noch gibt es klar formalisierte Zugehörigkeits-Kriterien und Aufnahmebedingungen (wie in Unternehmen oder Vereinen). Was es stattdessen gibt sind Selbst- oder Fremdzuordnungen, die sich auch widersprechen können. Man denke z.B. an die Debatten, oder SAFe und OKRs agile Frameworks sind oder nicht.

Eine Folge dieser nicht-formalen Zugehörigkeit ist das weitgehende Fehlen von Macht-Mitteln und Ressourcen-Kontrolle. Bis zu einem gewissen Grad ergeben die sich zwar indirekt aus charismatischer Führung, bzw. der sich daraus ergebenden Gefolgschaft, es gibt aber keine Budgets, keine Karrierepfade und keine bei Fehlverhalten drohenden Konsequenzen. Das ist auch ein Hauptgrund für den in sozialen Bewegungen verbreiteten Idealismus, der als Motivator an die Stelle materieller Anreize tritt.

Dieser unklare und von materiellen Zielen getrennte Status wird allerdings weiter verkompliziert durch das Phänomen, dass es mit der Zeit zu Formalisierungen von Teilen sozialer Bewegungen kommen kann, die dann parallel zu den unformalisierten Teilen bestehen. Eines der bekanntesten Beispiele dürfte die Entstehung der grünen Parteien aus der Umweltbewegung sein, formalisierte Teile der agilen Bewegung sind u.a. die Agile Alliance oder die Scrum Alliance.

Diese letzten Beispiele zeigen auch ein Problem auf, dass soziale Bewegungen bekommen können, wenn sich Teile von ihnen formalisieren. Ob nur zur Finanzierung der eigenen Strukturen oder aufgrund einer Gewinnerzielungsabsicht - mit Formalisierung geht praktisch immer der ein Geldbedarf einher, der alleine aus Selbsterhaltungstrieb doch als materielles Ziel neben die ursprünglichen, idealistischen Ziele tritt - was von den nicht-formalisierten Teilen der Bewegung z.T. vehement abgelehnt wird.

Verstärkt werden derartige Konflikte durch ein weiteres Phänomen, den so genannten Sog der Addition. Er tritt auf, wenn ähnliche soziale Bewegungen gemeinsame Teilziele verfolgen und sich dadurch teilweise überlagern. Sobald diese Überlagerung eine kritische Masse überschreitet, werden auch ursprünglich nicht geteilte Ziele übernommen, im Fall weiter Teile der agilen Bewegung z.B. das Streben nach Basisdemokratie oder die Ablehnung von Shareholder Value-Orientierung.

Nochmal von einer anderen Seite betrachtet können Soziale Bewegungen derartige interne Konflikte aber besser bewältigen und kompensieren als stärker formalisierte Gruppen, zum Einen weil sie eben aufgrund der fehlenden Formalität und Ressoucenverteilung in einem weitgehend konsequenzfreien Raum operieren, zum Anderen weil ihre übergreifenden idealistischen gesellschaftlichen Ziele eine Bindekraft haben können, die grösser ist als die Zentrifugalkräfte der verschiedenen internen Interessen.

Eine kleine Anekdote: in einem meiner längeren Einsätze war ich mit der Begleitung einer agilen Konzern-Transformation beauftragt, in deren Rahmen ich über mehrere Monate Product Owner und Scrum Master ausbildete, Schulungen durchführte und bei der Erstellung einer neuen Aufbau und Ablauforganisation beriet. Im Großen und Ganzen ein Auftrag, auf den ich gerne zurückblicke - mit einer Ausnahme, bei der ich mich etwas fahrlässig verhalten habe.

In einem Workshop mit mehreren angehenden Scrum Mastern stellte irgendjemand einen der Klassiker unter den Einsteiger-Fragen: für was Scrum eigentlich die Abkürzung wäre.¹ Ich war gleichermassen amüsiert und leicht genervt, da ich den Ursprung dieses Namens bereits mehrfach erklärt hatte. Und aus einem Affekt heraus antwortete ich mit einem Witz: "Scrum steht für Scaled Corporate Rational Unified Model". Alle lachten kurz, ich dachte mir nichts dabei und der Workshop ging weiter.

Man kann sich vermutlich denken, was als nächstes passiert ist: Zu den Aufgaben der anwesenden neuen Scrum Master gehörte auch die Erstellung von Schulungsunterlagen, und als ich die zwei Wochen später zu Gesicht bekam, musste ich kurz nach Luft schnappen. SCRUM wäre eine Abkürzung, hiess es da, und sie würde stehen für Scaled Corporate Rational Unified Model. Mir war sofort klar, wo diese Fehldeutung ihren Ursprung hatte - bei mir.

Sensibilisiert durch dieses Erlebnis achte ich seitdem darauf, dass humorige oder sarkastische Bemerkungen von mir klar als solche zu erkennen sind, um nicht wieder zur Quelle für eine fehlerhafte Information zu werden. Und ich achte darauf, wo andere Agile Coaches versehentlich mit flapsigen Bemerkungen Falsch-Informationen verbritet haben. Und was soll ich sagen - selbst wenn es zum Glück nicht häufig ist, es kommt immer wieder vor.

Bei einem Kunden stand in der Dokumentation, dass die Kanban-Methode nach ihrem Erfinder Kenji Kanban benannt worden wäre. Bei einem anderen, dass SAD MF ein vielversprechendes Skalierungs-Framework wäre, dass man näher evaluieren sollte. Mehrfach habe ich erlebt, dass Jira erkennbar ironisch als agiles Framework bezeichnet wurde, einmal mit der Anmerkung, dass Entwickler die es benutzen nicht mehr selbst denken müssten. Offensichtlicher Sarkasmus, der aber nicht erkannt wurde.

Wie es zu derartigen Transfer-Missverständnissen kommt ist dabei einfach erklärbar: Für den Agile Coach ist sene Arbeit entweder Routine, die er durch Scherze aufzulockern versucht, oder eine Frustrationserfahrung, die in zu Sarkasmus verleitet. Die ihn umgebenden Menschen befinden sich dagegen in einer Sondersituation, sind noch unsicher was von dem neuen Wissen relevavant ist und verinnerlichen vorsichtshalber alles. Was daraus folgt ist offensichtlich.

Gerade aufgrund dieser Wissens-Asymetrie befindet sich der jeweilige Agile Coach in einer Position, in der er sich verantwortungsvoll verhalten muss. Wie oben gesagt, Humor und Sarkasmus sind in Ordnung, sie müssen aber als solche erkennbar sein, im Zweifel durch die Anmerkung, dass die letzte Aussage bitte nicht ernst zu nehmen ist. Das hilft allen anderen, hilft aber auch dem Agile Coach selbst, der sich weniger Sorgen machen muss, dass von ihm versehentlich das Falsche gelernt wird.

Die Entwicklung einer negativen Weltsicht durch viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) ist ein bedauenswertes, aber auch menschlich verständliches Phänomen - wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten", um zu zeigen, dass vieles auch gut läuft.

In dieser hier geht es um das Durchführen einer Konzern-Reorganisation. Besagter Konzern hatte in den Jahren zuvor bereits mehrere Reorganisationen durchgeführt, und alle Beteiligten waren sich einig, dass sie nur mittelgut verlaufen waren. Am Anfang hatte es zwar jedesmal gut durchdachten Pläne gegeben, sobald die auf die Realität trafen, hatten sie sich aber jedesmal als lückenhaft erwiesen. Die Anpassung an die Realität hatte dann jedesmal zu Bürokratie, Unordnung und Unzufriedenheit geführt.

Das neue Vorgehen, mit dem es diesesmal anders werden sollte, sah zunächst vor, die Veränderungen in Arbeitspakete aufzuteilen, die nach und nach, in Abständen von wenigen Wochen, ausgeliefert werden sollten. Das Besondere daran: spätere Schritte wurden bewusst noch nicht ausdetailliert, stattdessen wurde nach jeder Auslieferung ein Feedback-Prozess gestartet, auf dessen Basis die Detaillierung angepasst wurde. Sogar das Rückgängigmachen früherer Reorganisationsschritte war ggf. möglich.

Um es an Beispielen konkret zu machen: ein erstes Arbeitspaket war die grundsätzliche Aufteilung und Bündelung von Zuständigkeiten, ein zweites der darauf aufbauende Zuschnitt der Bereiche und Abteilungen, ein drittes die Besetzung der Leitungspositionen, ein viertes die Zuordnung derjenigen Mitarbeiter, deren Tätigkeitsprofil das eindeutig zuliess, ein fünftes die Zuordnung der nicht ganz so eindeutigen Fälle, ein sechstes die Verteilung der neuen Einheiten auf die Büros.¹

Der Feedback-Prozess, der nach der Fertigstellung von jedem dieser Arbeitspakete folgte, bestand aus mehreren Dimensionen. Zum einen gab es Versammlungen der (bisherigen) Standorte und Abteilungen, in denen Fragen, Bedenken und Hinweise geäussert werden konnten. Parallel dazu wurden Mitarbeiter aus allen Organisationseinheiten zu Teilzeit-Change Managern ernannt, die dort Ansprechpartner waren und Rückmeldungen sammelten. Zuletzt gab es physische und virtuelle Feedback-Briefkästen.²

Die Erkenntnisse aus diesen Feedbacks waren zum Teil sehr wertvoll. An einer Stelle wurde z.B. darauf hingewiesen, dass beim Abteilungsschnitt eine Zuständigkeitslücke gelassen wurde, an einer anderen Stelle, dass die Aufteilung bestimmer Aufgaben auf zwei Abteilungen zwar theoretisch möglich, in der Realität aber schwierig umzusetzen sein würde, da sie bisher von den selbem Personen durchgeführt wurden. Mehrfach führte das zu Anpassungen, die ebenfalls wieder Gegenstand von Feedback wurden.

Dass diese Anpassungen mit verhältnismässig gerigem Aufwand durchgeführt werden konnten, war vor allem dem Verzicht auf zu frühe Detailplanung zu verdanken. So wären in den beiden erwähnten Beispielen die Korrekturen der suboptimalen Abteilungsschnitte deutlich schwieriger gewesen, wenn zu dem Zeitpunkt bereits alle Versetzungen in diese Einheiten stattgefunden hätten. Da die Versetzungen jetzt erst in einem nächsten Schritt stattfanden, entstanden die Probleme gar nicht erst.

Als Nebeneffekt wurde auch die Kommunikation der Veränderungsmassnahmen deutlich einfacher. Statt alle Veränderungen auf einmal konsistent erklären und als Ganzes verstehen zu müssen, wurde jeweils nur auf das aktuelle Arbeitspaket vertieft eingegangen, bei den späteren reichte eine kurze Ankündigung des Inhalts und des geplanten Zeitpunkts. Sowohl im Kommunikationsteam als auch in der Belegschaft wurde das im Vergleich zu früheren Reorganisationen als deutliche Verbesserung empfunden.

Eine Pointe dieser Geschichte hier ist, dass das in ihr beschriebene Vorgehen, nie offiziell als "agil" konzipiert oder bezeichnet wurde. Stattdessen ging es nach Ansicht aller Beteiligten lediglich auf Common Sense und Erfahrungswerte zurück, aus denen sich ganz selbstverständlich die hier beschriebenen Schritte ergaben. Erst ganz zum Schluss fiehl einem Vorstand auf, dass es offensichtliche Parallelen zur agilen Produktentwicklung gab. Grösser thematisiert wurde das aber nie.

Dass es von jedem agilen Framework in der Realität sehr unterschiedliche Ausprägungen gibt, dürfte jeder wissen, der verschiedene agil arbeitende Unternehmen gesehen hat. Zu den Gründen dafür gehört zum einen ein bewusst offen gelassener Gestaltungsspielraum, zum anderen aber auch versehentliche oder absichtliche Verfremdungen der ursprünglichen Idee. Das trifft auf Scrum zu, auf Kanban, auf OKRs, aber auch auf das Scaled Agile Framework (SAFe).

SAFe ist dabei aber in einem Aspekt deutlich anders als die anderen Frameworks: während sich deren Variantenvielfalt u.a. daraus ergibt, dass sie sich in einem Spannungsfeld zwischen einem praxisnahen Graswurzel-Ursprung und einer später entstandenen starken Kommerzielisierung bewegen, ist SAFe bereits in seinen Ursprüngen kommerziell angelegt. Sämtliche seiner Varianten sind dadurch Teil des Beratungs- und Zertifizierungs-getriebenen agil-industriellen Komplexes.¹ Hier sind sie:

The Little Agile Release Train

Die vielleicht häufigste Variante, wenn auch oft mit anders benannten Namen und Rollen.² Drei bis zehn Teams arbeiten in synchronisierten Sprint-Rhythmen, es gibt eine übergreifende Quartalsplanung und oberhalb der Product Owner und Scrum Master einen Produktmanager / Chief Product Owner und Release Train Engineer / Chief Scrum Master, der ihnen jeweils übergeordnet ist. Für sich genommen eine noch relativ schlanke, agile und halbwegs unbürokratische SAFe-Umsetzung.

The Feature Factory

Die Grössenordnung, die die Aussenwahrnehmung von SAFe am stärksten prägt. Ab einer Größe von mehr als zehn Teams ist ein Release Train nicht mehr ausreichend, es werden mehrere parallel zueinander eingerichtet, über denen dann eine zusätzliche Hierarchieebene mit einem Solution Manager und einem Solution Train Engineer entsteht. Feedback-Schleifen und Nähe zwischen Entwicklern und Anwendern sind nur noch schwer möglich, es werden vor allem Feature Requests abgearbeitet.

Disruptive SAFe

Während der einzelne Release Train und die Feature Factory die alten Strukturen einer Firma noch weitgehend unangetastet lassen, hat SAFe einige optionale Elemente, deren Anwendung einiges durcheinanderwerfen würde, z.B. die Koppelung der Budgetierung an Teams statt an Features oder die Ausrichtung der Planungen an Value Streams statt an Roadmaps. Aus einer "agilen Perspektive" sehr wünschenswert, kommt aber in der Realität nur sehr selten vor.

Absorbed SAFe

Dort, wo (warum auch immer) alles in einem einzigen, grossen agilen Framework organisiert werden soll, die Auswirkungen von disruptivem Safe den Verantwortlichen aber zu weit gehen, ist es eine häufige Reaktion, so lange Anpassungen vorzunehmen, bis zentrale Elemente des bisherigen Vorgehens nicht mehr angetastet werden. Das Ergebnis können Hybrid-Frameworks wie SpotiSAFe sein, ggf. aber auch einfach eine Erweiterung oder Beschneidung des SAFe-Umfangs an entscheidenden Stellen.

Post-SAFe

Mittlerweile erstaunlich häufig anzutreffen sind Unternehmen, die sich irgendwann entschlossen haben, nicht mehr nach SAFe zu arbeiten, da die damit verbundenen Erwartungen nicht erfüllt werden konnten. Mitunter werden aber einzelne funktionierende Elemente beibehalten, z.B. das PI Planning oder die Rolle des Release Train Engineers. Man erkennt durch sie noch, dass SAFe hier einmal im Einsatz gewesen ist, der aktuelle Zustand hat aber nur noch eingeschränkt damit zu tun.

Und viele mehr ...

Wie immer bei solchen Aufzählungen ist auch diese hier nicht vollständig, in den Unternehmen dieser Welt kann man mit Sicherheit noch weitere SAFe-Varianten finden. Wichtig ist an dieser Stelle vor allem die zentrale Botschaft: es gibt verschiedene Ausprägungen dieses Frameworks, die sich z.T. sehr deutlich voneinander unterscheiden, wodurch es viel weniger eindeutig und einheitlich ist, als es auf den ersten Blick erscheinen mag.

Bild: Strassen NRW

Ab und zu wird man von der staatlichen Verwaltung positiv überrascht, in diesem Fall vom Landesbetrieb Straßenbau Nordrhein-Westfalen. Der ist u.a. verantwortlich für den Neubau einer Brücke, die ich in den letzten Jahren ab und zu benutzt habe, der Wupperbrücke Blombacher Bach in Wuppertal. Dieser Neubau wurde dieses Jahr in einer rekordverdächtigen Geschwindigkeit von nur wenigen Wochen abgeschlossen, und das mit Massnahmen, die jetzt zum Standard in NRW werden sollen.

Die erste dieser Massnahmen ist ein frühes Beteiligungsverfahren, an denen sich alle betroffenen Gruppen (in diesem Fall Anwohner, Pendler, Unternehmen, etc.) beteiligen und ggf. ihre Bedenken einbringen können. Das mag auf den ersten Blick wie eine Verzögerung wirken, sorgt aber später im Prozess für Geschwindigkeit, da durch die Einbeziehung derartiger Stakeholder die Wahrscheinlichkeit von Fehlplanungen und Gerichtsprozessen geringer wird.

Über die zweite Massnahme habe ich bereits an anderer Stelle etwas geschrieben: es ist die Modulbauweise. Die einzelnen Bauelemente können an einer anderen Stelle im Voraus gefertigt werden und werden vor Ort nur noch zusammengesetzt und durch eine so genannte Ortbetonergänzung verbunden (was für ein schönes deutsches Wort). Neben der Geschwindigkeit ergibt sich dadurch ein zweiter Vorteil - beschädigte Brückenteile können später einfacher ersetzt werden.

Die dritte Massnahme ist vermutlich für die deutsche Bürokratie am revolutionärsten, es handelt sich um die so genannte funktionale Ausschreibung der Bauvorhaben. Bei derartigen Ausschreibungen wird kein detaillierter Leistungskatalog mehr vorgegeben, sondern es wird nur das zu erreichende Ziel definiert (z.B. Abriss und Neubau einer Brücke) ggf. verbunden mit in diesem Rahmen zu erreichenden Kennzahlen (z.B. der Traglast dieser Brücke).

Dieses Vorgehen hat gleich mehrere positive Effekte: der Umfang der zu erstellenden und zu bearbeitenden Ausschreibungs-Unterlagen wird geringer, den Bauträgern wird es möglich gemacht, neue und innovative Bautechniken einzusetzen, ohne die Bauämter davon überzeugen zu müssen, diese in die Pläne aufzunehmen, und durch die geringeren Aufwände in diesen Ämtern ist der dort spürbare Fachkräftemangel ein weniger starker Verlangsamungsfaktor für Planungs- und Genehmigungsprozesse.