Agil im Großprojekt entwickeln – Der Teamschnitt und die Folgen für die Softwareentwicklung

Agil im Großprojekt entwickeln – Der Teamschnitt und die Folgen für die Softwareentwicklung

Agile Softwareentwicklung im Großprojekt bedeutet, dass die Entwicklung in mehreren Scrum-Teams parallel stattfindet. Dies führt zu der Fragestellung, welcher Teamschnitt für die Scrum-Teams gewählt werden soll. Weit verbreitet sind die Ansätze, die Teams entweder entlang der zu entwickelnden Komponenten (Komponenten-Teams) oder entlang der umzusetzenden Features (Feature-Teams) zu schneiden. Als Softwarearchitekten und Entwickler haben wir bei Q_PERIOR als Mitglieder von Scrum-Teams schon in den klassischen Komponenten- bzw. Feature-Teams Software entwickelt. Darüber hinaus haben wir in der Praxis auch hybride Ansätze erlebt. In diesem Artikel wollen wir die Auswirkungen der verschiedenen Ansätze auf unsere tägliche Arbeit als Architekten und Entwickler aufzeigen.

Komponenten-Teams: Ein Paradies für Entwickler

Ein Scrum-Team besteht aus dem Product Owner, dem Scrum Master und dem Development-Team. Dies ist interdisziplinär aus Architekten, Entwicklern, Testern und Business Analysten zusammengesetzt und umfasst in der Regel nicht mehr als neun Personen.

In der Abbildung sind drei Scrum-Teams A, B und C zu sehen. Jedes der Teams verantwortet eine festgelegte Anzahl an Komponenten in vollem Umfang. Für das Team bedeutet dies:

Die Grafik zeigt den Aufbau von Komponenten-Teams
  • Technologie Stack: Das Team kann den für die Aufgabenstellung und die vorhandenen Skills entsprechenden Technologie Stack in einem bestimmten Rahmen wählen.

  • Code Ownership: Die Code Ownership ist klar definiert. Das Team kann die Architektur, die Codierungsrichtlinien, den Programmierstil und die Qualität für sich festlegen. Es besteht eine Teamvision, wie „guter“ Code aussieht. Dies ermöglicht effizientes Arbeiten im Pair oder im Mob und für Teamreviews. In jedem Projekt entsteht über die Zeit die Notwendigkeit, Code zu refactorn. Besteht ein gemeinsames Qualitätsverständnis, herrscht in der Regel Einigkeit darüber, wo sich Refactoring lohnt und in welche Richtung es gehen soll.

  • Build Pipeline: Das Team ist alleinig für den Aufbau und das Funktionieren der Build Pipeline verantwortlich.

  • Testen: Das Team kann für sich den geeigneten Testansatz, das richtige Verhältnis zwischen Unit-Tests und integrativen Tests sowie die geeigneten Werkzeuge festlegen.

Übergreifende Abstimmungen: Für übergreifende Abstimmungen z. B. bezüglich Architektur und Test können die Teams ihre Meinung zunächst teamintern bilden. Danach können die Teams Abgesandte bestimmen, die die Meinung des Teams in den teamübergreifenden Boards vertreten.

Für die Entwickler bedeutet dies das Paradies, da sie eine definierte Verantwortung besitzen, in deren Rahmen sie weitgehend selbständig Entscheidungen treffen können. Lässt sich die Fachlichkeit isoliert in den jeweiligen Komponenten entwickeln, trägt dieser Ansatz aus Business-Sicht ebenfalls. Die Nachteile des Komponentenschnitts aus Business-Sicht kommen dann zum Tragen, falls die umzusetzenden Features mehrere Komponenten umfassen. Das hat zur Folge, dass das Business dafür Sorge zu tragen hat, die User Stories für die Features entlang der Komponente zu schneiden und die Abhängigkeiten zu steuern. Das Business muss außerdem dafür sorgen, dass alle Teams gleichmäßig ausgelastet sind. Lässt dies die Fachlichkeit nicht zu und bestimmte Komponenten-Teams werden zum Engpass, kommen als eine Lösung Feature-Teams ins Spiel.

Feature-Teams: Ein Paradies für das Business

Die Grafik zeigt den Aufbau von Feature-Teams

Die Abbildung zeigt das Vorgehen bei der Entwicklung in Feature-Teams. Ein Scrum-Team ist für die Entwicklung eines Features über alle Komponenten hinweg zuständig. Alle Entwickler müssen also in der Lage sein, in jeder Komponente Software zu entwickeln. Feature-Teams können dem Business helfen, stellen jedoch die Entwickler vor große Herausforderungen.

Das Arbeiten in Feature-Teams erfordert, dass die Entwickler in der Lage sind, in allen Komponenten zu entwickeln. Besonders anspruchsvoll für die Entwickler ist dies, wenn aufgrund der fachlichen und technischen Anforderungen die Notwendigkeit besteht, für die Komponenten verschiedene Technologie Stacks einzusetzen.
Darüber hinaus muss über mehrere Scrum-Teams hinweg eine einheitliche Vorgehensweise für die Architektur, Entwicklungsrichtlinien, Build Pipeline, Test- und Fehlermanagement festgelegt werden. Einigkeit muss jetzt nicht nur innerhalb eines Scrum-Teams sondern über mehrere Scrum-Teams hinweg erzielt werden. Dies kann insbesondere dann zur Herausforderung werden, wenn die Scrum-Teams inhomogen sind, da sie z. B. von verschiedenen Dienstleistern gestellt werden.

Ein entscheidender Knackpunkt ist die Code Ownership. Bei der Implementierung neuer Features oder der Erweiterung bestehender Features ist es unvermeidlich, dass man auf Code trifft, der aufgrund der sich geänderten Anforderungen, refactored werden sollte. In kleinerem Umfang kann dies nach der Boy Scout Rule geschehen oder für größeren Refactorings in Form einer dedizierten User Story z. B. im Rahmen eines Innovation Sprints.

Es stellt sich die Frage, wer sich für den Code verantwortlich fühlt. Die Erfahrung zeigt folgendes: Je mehr Entwickler für etwas verantwortlich sind und je größer deren Verantwortungsbereich ist, desto weniger wird die Verantwortung wahrgenommen. Der Grund dafür liegt darin, dass der Entwickler sich jetzt für die Entwicklung von Features verantwortlich fühlt und nicht für eine Komponente. Eine weitere Ursache liegt darin, dass er sich für das Durchführen eines Refactorings nicht nur innerhalb seines Teams, sondern über mehrere Teams abstimmen und für sein Refactoringvorhaben „werben“ muss. Die Folge kann sein, dass weniger refactored wird, sich die Codequalität verschlechtert und der Code inhomogener wird. Das Arbeiten in Feature-Teams kann für die Entwickler frustrierend sein.

Eine hybride Form: Win-Win-Situation für Business und Entwickler

Um die Verantwortung, qualitative Software zu entwickeln, für die Teams und die einzelnen Teammitglieder wieder greifbar zu machen, kann ein hybrider Teamschnitt eingesetzt werden. Dieser Teamschnitt trennt zwischen Code-Ownership und Feature-Entwicklung. Wie in der Abbildung dargestellt, ist ein Team für eine oder mehrere Komponenten verantwortlich, das Business kann aber weiterhin in Features denken und entwickeln lassen.

Konkret bedeutet das, dass jedes Team die vollumfängliche Verantwortung für die Codequalität der ihm zugeordneten Komponenten trägt. Jedes Team kann für sich eine Teamvision, wie „guter“ Code aussieht, entwickeln und verwirklichen.

Betrifft ein Feature mehrere Komponenten braucht das Business das Feature nicht mehr entlang der Komponentengrenzen zu schneiden, sondern kann die Entwicklung eines Features komplett einem Team übertragen – unabhängig von der Code-Ownership.

Bedeutet ein Feature nun, dass ein Team in Komponenten eines anderen Teams entwickelt, ist es dazu verpflichtet, dies nach den Vorgaben des Teams zu tun, das die Code-Ownership für die Komponente innehat. Somit ist sichergestellt, dass der Code für eine Komponente homogen bleibt. Organisatorisch kann dies z. B. durch verpflichtende Code Reviews in Form von Merge/Pull Requests sichergestellt werden. Aber auch im Vorfeld bieten sich Maßnahmen an, wie z. B. das Refinement für ein Feature teamübergreifend durchzuführen.

Die hier aufgezeigte hybride Form ist eine mögliche Ausprägung. In der Praxis kommen weitere Formen zum Einsatz. So kennt das Spotify-Modell z. B. die Möglichkeit Guilds zu bilden. Eine Guild ist eine Gruppe von Personen mit denselben Interessen – in diesem Fall die technische Verantwortung für bestimmte Komponenten.

Fazit

Jedes Entwicklungsprojekt muss den richtigen Teamschnitt für die jeweiligen Projektanforderungen finden. Neben den bekannten Teamformen wie Komponenten- und Feature-Teams sind auch hybride Formen denkbar. Das wertvolle am agilen Ansatz ist, dass durch regelmäßige Feedbackzyklen der gewählte Teamschnitt Teil der Retroperspektive ist und – falls die Notwendigkeit gesehen wird – der Teamschnitt geändert und ausprobiert werden kann.

Innovative Geschäftsmodelle basieren heute zunehmend zu einem hohen Prozentsatz auf IT. Das bedeutet, dass die Softwareentwicklung die von den Geschäftsmodellen geforderte Agilität unterstützen muss. Für die Geschwindigkeit der Softwareentwicklung im agilen Softwareprojekt ist es ein Schlüsselfaktor, für die Entwicklerteams den passgenauen Teamschnitt zu finden.

Mehr zum Thema

Können wir Sie unterstützen? Kontaktieren Sie unsere Experten!

Mit Q_PERIOR steht Ihnen ein starker Partner zur Seite.
Wir freuen uns auf Ihre Herausforderung!