© istockphoto.com/artishokcs, © S&S Media
Wie Architekturstile agile Zusammenarbeit fördern oder behindern

Conway 2.0


Die Architektur Ihres Systems ist nicht allein eine technische Frage. Die Strukturierung des Systems, das Kommunikationsdesign und andere architektonische Fragestellungen setzen Grenzen für die Möglichkeiten des agilen Arbeitens, beeinflussen, wie Teams aufgestellt werden können und bestimmen mit, wie sich Architekturarbeit organisieren lässt. Dieser Artikel zeigt, was agile Softwareentwicklung uns über Teams und Zusammenarbeit lehrt und wie die technische Architektur hier helfen kann.

1968 formuliert Melvin Edward Conway eine Beobachtung, die später als „Conway’s Law“ Berühmtheit erlangen wird: „Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“ [1].

Conways Überlegungen werden meist mit der Definition von Schnittstellen und der Systemstruktur in Verbindung gebracht. So versuchen z. B. manche Organisationen, lose Kopplung durch organisatorische Ferne zu fördern. In der momentanen Diskussion zu Systemarchitekturen nimmt Conway, fast fünfzig Jahre nach seiner Feststellung, wieder eine prominente Rolle ein. Wie schaffen es Firmen wie Spotify, Netflix oder Amazon, im Großen sehr effektiv zu arbeiten? Wie können dort hunderte Entwickler an einem Produkt arbeiten, ohne an Dynamik und Reaktionsvermögen einzubüßen? Für schnelle Reaktion auf Marktänderungen werden längst nicht nur Zusammenarbeitsmodelle und Kommunikationsstrategien entwickelt – auch Architekturansätze werden als Teil der Gleichung erkannt. Henrik Kniberg sagt über Spotify: „The technical architecture is hugely important for the way we are organized. The organizational structure must play in harmony with the technical architecture. Many companies can’t use our way of working because their architecture won’t allow it.“ [2].

Ist es an der Zeit, nicht nur methodisch über agile Vorgehensmodelle nachzudenken, sondern auch die technische und fachliche Architektur der zu entwickelnden Systeme mit einzubeziehen? Immer mehr deutet darauf hin, dass die Antwort „ja“ lautet. In diesem Artikel werde ich deshalb zeigen,

  • welche Teamstrukturen für Flexibilität und Agilität wünschenswert sind.

  • wie Architekturentscheidungen agil getroffen werden können.

  • welche Architekturideen und -stile eine solche agile Arbeitsorganisation und Architekturarbeit fördern (oder behindern).

Da die gewonnene Flexibilität und Agilität stark mit Kompromissen und Herausforderungen verbunden ist, werde ich auch diese Seite nicht außer Acht lassen.

Teamaufstellung und agile Grundsätze

Agilität steht für schnelle Reaktion auf Veränderung, für stetiges Lernen und enge Zusammenarbeit auf vielen Ebenen. Für viele Unternehmen ist diese Idee charmant, verspricht sie doch Kundenzufriedenheit, schnelle Time-to-Market und die Minimierung typischer Projektrisiken. Bevor ich darauf zu sprechen komme, warum diese Versprechen mit vielen technischen Architekturen nicht eingelöst werden können, werfe ich einen Blick darauf, welche Projekt- und Teamorganisation überhaupt wünschenswert ist.

Teams sollten im agilen Sinne möglichst selbstorganisiert arbeiten. Das heißt, Teams sollen in der Lage sein, ihren Arbeitsmodus und ihre Entwicklungsarbeit selbstständig zu optimieren (vgl. Agiles Manifest – Prinzip 11). Qualität und Design liegen ebenfalls als Verantwortung beim Team. Direkte Kommunikation und lokale Entscheidungsmöglichkeiten sind zu fördern (vgl. Agiles Manifest – Prinzip 6).

Das gelingt bei Projekten mit nur einem Team meist gut – das Team muss allerdings auch die richtige Größe haben. Ist es zu klein, fehlen Ressourcen und Wissen, ist es zu groß, steigt der Aufwand für Kommunikation und Koordination, und eventuell bilden sich Subteams heraus (siehe Kasten: „Die ideale Teamgröße“).

Die ideale Teamgröße

Dr. Belbin schreibt über die Arbeit in der Europäischen Union, dass Entscheidungen effektiv nur in kleinen Gruppen möglich sind, und empfiehlt eine Gruppengröße von vier [3]. Ringelmanns Studien zu Gruppenverhalten deuten darauf hin, dass größere Gruppen zu „Social Loafing“ neigen, der individuelle Einsatz durch eine Gruppe also kaschiert wird und deshalb abnimmt. Bekannt ist das Phänomen als Ringelmann-Effekt [4]. Wittenberg nennt seine Studien zur optimalen Teamgröße „not conclusive“, legt sich jedoch auf einen Korridor von fünf bis zwölf Leuten fest, wobei sechs eine häufig genannte Zahl ist. Oft wird die ideale Teamgröße auch auf die berühmte 7+/-2-Formel zurückgeführt.

Fest steht: Ab einer zweistelligen Anzahl an Projektmitgliedern sollte man über die Aufspaltung in mehrere Teams nachdenken. Der teaminterne Effizienzgewinn ist dann meist höher als der Verlust durch die Hürde der Teamgrenze.

Erreichen Systeme eine Größe, die mehrere Teams rechtfertigt, stellt sich die Frage des Teamschnitts. Man möchte möglichst unabhängige Teams erreichen und landet im agilen Umfeld deshalb oft bei Featureteams. Ein Featureteam ist ein Team, das eine Reihe von Funktionalitäten umsetzen kann – aus Kundensicht vollständig und eigenständig [5]. Dafür ist es disziplinübergreifend zusammengesetzt, erklärt technische Belange also zur Querschnittsaufgabe. Diese Belange sollten jedoch nicht überhandnehmen, um die eigentliche Idee der Unabhängigkeit von Teams zu fördern. Sind Scrum of Scrums zu häufig technisch motiviert, handelt es sich um ein Warnzeichen, dass System- und Teamstruktur nicht zueinander passen. Wirklich agile Organisationen versuchen diese Verletzung von Conway’s Law zu adressieren:

  • Auf organisatorischer Seite etwa durch querschnittliche „Gilden“ (vgl. Spotify) oder andere Architekturpraktiken, die Fokussierung von Kommunikation fördern (siehe nächster Abschnitt).

  • Auf technischer Seite durch die Verringerung von Querschnittsthemen, etwa mit lokaler Entscheidungsgewalt für Technologien und Inkaufnehmen von technischen Inkonsistenzen (siehe Abschnitt: „Architekturkonzepte für mehr Lebendigkeit“).

Gelingt es Ihnen, kleine, unabhängige Teams zu schneiden, haben Sie im Sinne der Agilität schon einen großen Schritt getan. Andere agile Säulen, wie die enge Zusammenarbeit mit Fachexperten oder eine hohe Identifikation von Entwicklern mit dem Produkt, sind dann...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang