Kolumne: Groß und (fr)agil?

Architektur mit Tigern: Wie eine Anwendungsarchitektur auch bei mehreren Teams konsistent bleibt

Timo Becker, Christoph Niemann

(c) Shutterstock / eelnosiva

Wie bleibt eine Anwendungsarchitektur bei mehreren Teams konsistent? Klassischerweise gibt es dafür eine zentrale Architektur-Instanz, die genaue Vorgaben an die Entwickler-Teams weiter gibt. Doch scheint ein solches Vorgehen im Kontext agiler Software-Entwicklung nicht mehr zeitgemäß zu sein. Dennoch müssen gerade in großen Projekten, die mit mehreren Teams arbeiten, gewisse architektonische Entscheidungen übergreifend getroffen werden. In der Kolumne Groß und (Fr)agil stellt Timo Becker eine Lösung für dieses Problem vor: Die Architektur mit Tigern.

Groß und (Fr)agil?

Vielleicht kennen Sie die Situation: Man startet agil und alles läuft gut – bis das Team wächst und das Produkt von mehreren Scrum-Teams entwickelt wird. Schnell steht der agile Protagonist auf unbekanntem Terrain: Wie skalieren Product-Owner, Aufgabenverteilung und teamübergreifende Abstimmungen? In dieser Kolumne wollen wir erprobte Lösungspraktiken und Patterns aus bekannten Skalierungs-Frameworks aufzeigen.

Architektur mit Tigern

Agilität lebt von einer guten, konsistenten Architektur, die Adaptionen zulässt und wartbar bleibt. Doch in einem großen agilen Projekt erweitern mehrere Teams die Architektur. Konsistenz wird schnell zur Herausforderung, wenn Feature-Teams unabhängig voneinander an Komponenten arbeiten. Oft werden dann spezielle Architektur- oder Plattform-Teams eingeführt, die die Architektur sichern und die Nutzung eines Frameworks verantworten sollen. Dieser Ansatz ist aber nicht immer zielführend: Einerseits widerspricht das Vorgehen dem kundenzentrierten Ansatz von Feature-Teams. Andererseits führt er zu Abhängigkeiten zwischen Teams.

Aus unserer Erfahrung spricht stattdessen vieles dafür, zu Beginn eines Projekts ein sogenanntes Tiger-Team einzuführen. Ganz nach dem Leitsatz „Divide after you conquer“ entwickelt ein einzelnes Team, das Tiger-Team, zunächst Software und Kern-Architektur. Überschreitet die Arbeitslast die Kapazitäten dieses Teams oder soll die Projekt-Velocity erhöht werden, löst sich das Tiger-Team auf. An seiner Stelle entwickeln mehrere Feature-Teams das Produkt weiter. Die Mitglieder des ehemaligen Tiger-Teams teilen sich auf die Feature-Teams auf: Jedes Feature-Team hat mindestens einen ehemaligen „Tiger“. Er oder sie gibt die Grundzüge und Feinheiten der entwickelten Architektur an die neuen Teamkollegen weiter.

Lesen Sie auch: Makro- vs. Mikroarchitektur – Im Selbsttest zu mehr Architektur

Anschließend etablieren wir in Projekten eine Community of Practice (CoP) für Architekturfragen. Architekturfans aus allen Teams tauschen sich regelmäßig über Architekturfragen aus. Die CoP-Mitglieder tragen das erarbeitete Wissen in ihre jeweiligen Teams zurück und sind Ansprechpartner für Fragen in ihrem Team. Die Verantwortung bei der Entwicklung eines Features und der dazugehörigen Architektur liegt dann wieder autonom im Team. Neben der Architektur-Community kann es andere themenspezifische Gruppen geben, zum Beispiel für Testing, Infrastruktur oder Usability.

Wie werden Architektur-Fragen in Ihren Agile-Teams geregelt? Gibt es dafür dezidierte Architektur- oder Plattform-Teams? Oder haben Sie schon (postive/negative) Erfahrungen mit Architektur-Tigern gemacht? Wir freuen uns auf Ihre Kommentare!

Groß und (fr)agil?

In der Kolumne Groß und (fr)agil? stellen Christoph Niemann und Timo Becker (MaibornWolff) Lösungsansätze vor, um agile Entwicklung auf große Szenarien zu skalieren. Ganz nach dem Motto: Groß und agil – das muss kein Widerspruch sein!

Bisher erschienen:

 

Geschrieben von
Timo Becker
Timo Becker
Timo Becker ist Software-Ingenieur bei MaibornWolff und entwickelt aktuell Individual-Software in einem großen agilen Projekt.
Christoph Niemann
Christoph Niemann
Christoph Niemann ist IT-Consultant bei MaibornWolff. Er arbeitet am liebsten im agilen Requirements-Engineering an der Schnittstelle zwischen Fachbereich und Entwicklungsteam. Mit seiner agilen Erfahrung, besonders mit Scrum, hilft er Projekten beim Umbau vom Wasserfallmodell auf ein iteratives Vorgehen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: