Schwimmen mit den schnelleren Fischen - Teil 3: Das fehlende Glied bei agilen Transformationen

Das Konzept der traditionellen Konstruktion könnte keine schlechtere Metapher für die Softwareentwicklung sein. Und doch wurde es lange Zeit genau so gemacht. Bei dieser Art von formalem architektonischem Konstruktionsprozess wurden die "richtigen" Anforderungen im Voraus festgelegt und in Blaupausen umgesetzt, die dann implementiert wurden, in der Hoffnung, dass ein ausreichendes Design im Voraus jegliche Unsicherheiten auf dem Weg dorthin verhindern würde. Da sich die Anforderungen an Software jedoch ständig ändern, war dieses Verfahren zum Scheitern verurteilt, bevor die erste Zeile Code geschrieben werden konnte.

Die agile Transformation 

Die Lösung für das Rätsel des Wandels war die Einführung eines agilen Softwareentwicklungsprozesses. Durch die Aufteilung des langen, starren (Wasserfall-)Prozesses in kürzere Sprints konnten Unternehmen das Risiko eines Fehlschlags verringern, indem sie die Zeit zwischen Entwurf und Auslieferung verkürzten. Die Umstellung von einer hierarchischen Organisation auf eine Organisation, die sich an den Geschäftsfähigkeiten orientiert, versprach weniger Koordination und mehr Bandbreite während dieser kurzen Zyklen. Die Einführung von Methoden wie Scrum und Kanban hat die Leistung vieler moderner Unternehmen verbessert, aber die Erfahrung zeigt, dass eine Änderung des Prozessmanagements nur die halbe Miete ist.  

Autonome Teams

Wirklich agile Teams arbeiten autonom und ohne Zwang. Sie definieren ihre eigenen Anforderungen zusammen mit dem Unternehmen und entwerfen oder entwickeln Lösungen nach eigenem Ermessen. Ihr ständiger Fokus liegt auf der kontinuierlichen Schaffung von Mehrwert für den Kunden. Mit dem Versprechen einer radikalen Veränderung der Leistung investierten viele Unternehmen in die agile Umstrukturierung und hatten oft einen positiven Effekt. Aber viel mehr waren noch skeptisch und konnten insgesamt keine signifikanten Auswirkungen auf ihre Leistung messen.

In Schwimmen mit den schnelleren Fischen - Teil 2: Der Weg zum technischen Gewinn In diesem Artikel erkläre ich das duale Conway'sche Gesetz, eine Theorie, die besagt, dass Unternehmen, die ihre Software so modellieren, wie sie organisiert sind, auch dazu neigen, sich so zu organisieren, wie ihre Softwarelösungen aufgebaut sind. Mit anderen Worten: Die Flexibilität eines Unternehmens ist die Folge der Flexibilität seiner Architektur.

Wie kann ein Team also eigenständig Software entwickeln, wenn das Design und die Bereitstellung eine vollständige Abstimmung mit anderen Entwicklungsteams erfordern? Um die Flexibilität und Leistung eines Unternehmens zu verbessern, nutzen Sie die Dualität zu Ihrem Vorteil.

Die technische Seite der agilen Transformationen

Die Kehrseite einer erfolgreichen agilen Transformation ist eine Investition in eine Softwarearchitektur, die eine agile Arbeitsweise unterstützt und anregt und beide Teams technologisch aufeinander abstimmt, aber locker koppelt. Durch die Abkehr von der Vorstellung, dass Software-Architekturen hochgradig kontrollierbare und starre Strukturen sind, erhöht eine agile Architektur die Flexibilität des Teams und reduziert den Koordinations- und Verwaltungsaufwand, der erforderlich ist, um von der Idee zur Produktion zu gelangen.

So wie die Umstellung auf eine agile Arbeitsweise ohne eine organisationsweite Akzeptanz und Annahme ihrer Regeln und Grenzen nur schwer zu bewerkstelligen ist, sollten Unternehmen bei der Implementierung des Gegenstücks zur Softwarearchitektur dieselben Grundsätze definieren und befolgen. Denn letztendlich geht es nicht um die Idee,Ihr Unternehmen agil zu machen oder Ihre Software mit einem"microservices"inspirierten Design zu erstellen; es geht um die Ausführung unter Wahrung der zentralenPrinzipien. Denn agil nur dem Namen nach, aber ohne Engagement in jeder Schicht Ihrer Organisation und Architektur, ist ein sicheres Rezept für Enttäuschungen.