Leonid Lezner, der den wunderbaren Podcast “Firmenfunk“ macht, und ich hatten neulich eine Auseinandersetzung zu der Frage, ob ein Software-Architekt notwendig sei. Darauf aufbauend schrieb Reinald Kirchner einen Artikel, in dem er die folgende Beobachtung teilt: Software-Architektur gleicht zum einen oft Bebauungsplänen, die dann doch nie eingehalten werden. Zum anderen war lange Zeit der Aufstieg zum Software-Architekten einer der wichtigsten Karriereschritte für Software-Entwickler.
Emergente Architektur – diskutiert seit 2005
Warum bin ich mit Leonid überhaupt über seine These, es brauche einen Software-Architekten, aneinandergerasselt? Ich kann jetzt antworten, dass sich die agile Software Development Community mit dieser Frage bereits 2005 ausführlich auseinandergesetzt hat. Damals kam die Community zu dem Schluss, dass die Architektur von den Software-Entwicklern in den Teams gemacht wird und es keine ausgewiesene Rolle des Architekten mehr geben sollte. Auf Konferenzen und in unzähligen Artikeln haben wir darüber diskutiert, was überhaupt eine emergente Architektur ist und haben festgestellt, dass wir nur zu einer sinnvollen Antwort kommen, wenn wir am besten die Metapher der Architektur gar nicht verwenden, sondern eher jene des Gärtners. In sich ständig ändernden Umfeldern kann dann besser entwickelt werden, wenn sich Teams darauf verständigen, radikal auf testgetriebene Entwicklung zu setzen und eine entkoppelte Konstruktion für ihre Software-Applikationen zu wählen. Das nannte sich de-coupling und mündete u.a. – aber nicht zwingend – in Micro-Service-Netzwerken. Im Laufe der Zeit setzte sich auch die Erkenntnis durch, dass Conways Law nun einmal gilt. Damit wurde klar, dass Architektur in Unternehmen immer emergent ist und sich immer an der Organisation ausrichtet.
Doch diese Wiederholung des bereits Bekannten hilft ja nur zu verstehen, dass die moderne Software-Entwicklung, so wie sie von professionellen Teams gelebt wird, einen langen Weg gegangen ist. 2001 begann sich Extreme Programming als robuste Entwicklungsmethode mit ihren automatischen Tests so langsam in die Gehirne der Entwickler als neues Paradigma hineinzuarbeiten. Es wurde erbittert darüber gestritten, ob man alles automatisieren müsse und dann wurde auch darüber gestritten, wer denn diese Tests zu schreiben hätte. Klar — die Tester sahen sich bestärkt und wollten das machen. Doch erst als klar wurde, dass die Entwickler die Tests schreiben müssen, ging es mit dieser Bewegung voran. Scrum und Techniken des Extreme Programming haben Teams dazu gezwungen, sich etwas zu emergenten Architekturen zu überlegen, weil klassische Herangehensweisen zu langsam waren und sich jede langwierige Upfront-Planung als nicht effektiv erwies. Das waren nicht ein paar nebensächliche Überlegungen: Es mussten ganze Paradigmen zur Software-Entwicklung über den Haufen geworfen werden und wir mussten neue mentale Modelle entwickeln.
Haben sich diese Modelle bereits in allen Organisationen und in allen Entwicklergehirnen manifestiert? Reden wir alle nach 20 Jahren agiler Software-Entwicklung die gleiche Sprache und entwickeln heute alle Software-Entwickler anhand der in den letzten 20 Jahre entstandenen modernen Paradigmen? Beherrschen sie die Entwicklungs-Patterns oder schreiben sie selbsttätig nach dem Motto “Hinterlasse den Code, den du vorfindest, etwas besser als er war — kurz, bau die Codebasis ständig um”? Sicher nicht.
In der agilen Entwicklerszene werden die bereits vor vielen Jahren gewonnenen Erkenntnisse noch immer geleugnet. Noch immer betrügen sich viele Entwickler, Software-Architekten und Manager selbst, wenn sie meinen, es ginge nicht anders. Sie sind der Meinung: Ein Architekt oder sogar ein ganzes Team muss für die Entwickler denken und ihnen vorschreiben, in welchen Bahnen sie sich zu bewegen haben. Kirchner nennt es Bebauungspläne.
Es gibt noch immer die fixe Idee, man könne in einer Welt der nie dagewesenen Veränderungen solide und fest – also starr – bauen. Vielmehr sollten wir aber darüber nachdenken, wie Robustheit und Resilienz – oder besser Antifragilität – in die Applikationen Einzug halten können.
Stolperstein Status
Tja, ich denke, die Ursache dafür ist, dass es in viel zu vielen Projekten und Organisationen noch immer um das Thema Status geht. Es gibt eine soziale Hierarchie in Organisationen: Ganz oben steht das Business, dann kommen die Projektmanager, dann die Software-Architekten, dann die Entwickler, dann die Tester und am Ende steht der Betrieb. Aus diesem Grund werden immer noch Backlogs geschrieben, noch immer technische User Stories erdacht und Rahmenarchitekturen erträumt. Entwickler sollen dann das, was sich andere schöngeträumt und schöngeschätzt haben, so schnell wie möglich umsetzen. Am besten so, dass die Tester in Indien es möglichst einfach und kostengünstig testen können.
Wir träumen weiter, weil wir allem den agilen Mantel umhängen: Den Betrieb nennen wir DevOps, aus dem Anforderungsmanagement machen wir Design Thinking und aus den Lastenheften haben wir Backlogs gestrickt. Darin finden wir User Stories in einem Detaillierungsgrad, der zur Zeit des Lastenheftes undenkbar war. Wir liefern mit Hilfe von Release-Trains und suggerieren so Pünktlichkeit und Vorhersagbarkeit – obwohl wir wissen, dass wir kontinuierlich releasen sollten. Doch im Kern ist dieses Arbeiten sogar teurer als früher. Warum? Weil wir das Statusproblem — die Machtverhältnisse — nicht gelöst haben. So bleiben Organisationen politische Gebilde, in denen Silos dominieren und mehr nach innen, statt nach außen geschaut wird. Das Tragische ist: Inkompetenz und Unprofessionalität werden als State-of-the-art und “es geht nicht anders” verkauft, weil Regulierungen, Altsysteme, vorhandene Technologien und Tod und Teufel das angeblich erforderlich machen.
Die Regeln des Fraktals
Agile Entwicklung sollte — sie tut es viel zu wenig – aus fraktalen Teams bestehen, die aus unterschiedlichen Disziplinen divers zusammengestellt werden (das gilt für agiles Arbeiten an sich und für agile Organisationen erst recht). In diesen Teams sollen die Menschen sich und ihre Fähigkeiten gänzlich zum Wohle des Teams einbringen können (nennt sich jetzt Paint Drip People) – auf diese Weise entstehen tatsächlich diverse Teams. Teams, die die ursprüngliche Ideen von crossfunktionalen Teams komplementieren und Wirklichkeit werden lassen. In diesem Denken ist kein Platz für überkommene festgeschriebene Rollen wie Software-Architekten, Lead Developer, Test Leads oder Business Analysts. Denn das sind funktionale Rollen, die immer zu Bottlenecks werden. Spätestens dann, wenn die Person in dieser Rolle ihre Position verteidigen will, weil damit Geld, Boni und Ehre verbunden sind.
Will man das ändern und setzt man also wirklich auf fraktale Teams, wird man erfolgreich sein, wenn man ein paar simple Regeln einführt:
- Entkopplung als Prinzip
- Teams bleiben klein
- Teams sind end-to-end für ihre Funktionalitäten verantwortlich
- Jedes Team kümmert sich selbst um „seine“ User
- Das gesamte Netzwerk hat alle Informationen
- Dinge dürfen doppelt entwickelt werden
- Nicht Effizienz, sondern Geschwindigkeit ist das höchste Gut
Dann entsteht ein Netzwerk, das sich ständig verändern kann und am Ende viel effektiver und effizienter arbeiten kann.
Wer mir nicht glaubt oder es sich nicht vorstellen kann, der lese eine mehr als deutliche Beschreibung, wie es geht. Der Transfer auf die Realität der Software-Entwicklungsorganisationen sollte nicht allzu schwer sein. Viel Spaß beim Lesen von “Team of Teams“!
Foto: pixabay license, andreasfuchs8732