Spezialisierung in Agilen Feature-Teams

Die Luft ist zum Schneiden, der Beamer rauscht auf höchster Stufe und die Hemden vieler Teilnehmer sehen alles andere als frisch aus. Erleichterte Blicke, als der PO dem Team dankt und das Planungsmeeting beenden will – „Aber“, fällt ihm da eine Entwicklerin aus der hinteren Ecke des Raumes ins Wort, „für meine Komponente gibt es in diesem Sprint noch überhaupt nichts zu tun.“ Also, alle wieder hinsetzen, alles zurück auf null und noch mal von vorne beginnen mit dem Zuweisen der Stories in den Sprint.

In vielen Scrum-Projekten, in denen ich über die letzten Jahre gearbeitet habe, gab es ein ähnliches Problem: Die benötigten Technologien sind sehr heterogen und die Entwickler daher zu spezialisiert, als dass sie in allen Bereichen des Projektes eingesetzt werden könnten. Im Folgenden erläutere ich daraus resultierende Probleme und zeige verschiede Lösungsansätze.

Besonders Projekte, die neue Technologien in einem größeren Legacy-IT-Umfeld einführen, neigen durch den Mix an Alt und Neu dazu, eine große Menge an Sprachen, Frameworks und Tools zu beinhalten. Als Beispiel ein Technologie-Stack aus einem aktuellen Projekt: PhoneGap, AngularJS, Node.js, Java-Middleware, XML-basierte Messaging-Sprache, Oracle Database. Dazu kommen all die kleinen Tools und Frameworks, die in agiler Software-Entwicklung vorausgesetzt werden. Wer agiles Vorgehen schon mit der Entwickler-Muttermilch aufgesogen hat, neigt dazu, den zusätzlichen Lernaufwand zu unterschätzen, den es braucht, um TDD zu verinnerlichen, Mockito zu verwenden, Maven-Skripte auf dem CI-Server und eine Test Coverage-Analyse in seiner IDE ausführen zu lassen. Die Menge an neuem Wissen und Vorgehen, die Menschen lernen können, ist begrenzt. Es gilt also, die richtigen Prioritäten zu setzen. Doch dazu später mehr.

Das Feature-Team

Die optimale Größe eines Development-Teams liegt laut Scrum-Guide bei drei bis neun Entwicklern. Möchte man Feature-Teams bilden, so sollten diese Entwickler in der Lage sein, ohne externe Hilfe einen Wert für den Kunden zu schaffen. Also Anforderungen komplett von der UI bis zur Persistenz zu entwickeln.

“Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Having more than nine members requires too much coordination.” (1)

“‘A feature team is a long-lived, cross-functional, cross-component team that completes end-to-end customer features—one by one.’ Feature teams are an essential element to scaling up agile development.” (2)

Der Scrum-Guide spricht explizit nur von Entwicklern, egal welche Rolle sie im Development-Team einnehmen. Trotzdem erkennen die Autoren an, dass es in einem Team Spezialisierungen geben kann, wobei die Verantwortung für die Entwicklung aller Teile immer beim gesamten Team verbleibt:

“Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”  (1)

Das Komponenten-Feature-Team

Schauen wir einem imaginären Project Manager über die Schulter, wie er ein Entwickler-Team für den oben genannten Technologie-Stack zusammengestellt hat:

• 2 Tester, da das Team wenig Erfahrung in Testautomatisierung hat.
• 1 UX / UI-Experte, verantwortlich für Design und Implementierung der Oberfläche.
• 1 PhoneGap-Entwickler.
• 1 JS-Entwickler, für AngularJS und Node.js.
• 2 Java-Entwickler, verantwortlich für die Middleware-Komponenten.
• 1 Entwickler für die XML-basierte Messaging-Sprache.
• 1 Oracle Datenbank-Spezialist.

Das Ergebnis ist ernüchternd. Um ein Feature-Team zu bilden, das alle Bereiche der Entwicklung abdecken kann, haben wir für die meisten Bereiche nur einen Entwickler.

Die negativen Folgen liegen auf der Hand: Es bilden sich Wissenssilos, Code-Reviews und Pair-Programming sind deutlich erschwert. Der Abgang eines Entwicklers kann das gesamte Projekt in Schieflage bringen. Die andere Seite ist, dass es einen deutlichen Overhead in der Planung gibt. Der eindimensionale Velocity-Wert ist zur Planung nicht mehr ausreichend. Das Commitment des Teams wird es nur geben, wenn es in keinem der Technologie-Bereiche einen Engpass gibt. Damit bleiben Product Owner und Entwickler während der Planung zwangsweise im alten Komponentendenken hängen. Es kann passieren, dass der Product Owner die User Stories wieder mehr als Komponenten-Stories schreibt, da diese scheinbar einfacher zu planen sind. Durch die Fokussierung auf Komponenten wird aber gegen zwei wichtige INVEST -Faktoren verstoßen – die Stories sind nicht mehr unabhängig voneinander und sie liefern alleine keinerlei Wert für den Kunden. Aus agiler Sicht ist diese Lösung daher eine der schlechtesten.

Lösungsansätze

1) Mehr Flexibilität der Entwickler

Die häufigste Antwort auf das geschilderte Problem ist, dass sich die Entwickler weiterbilden sollen und werden. Der Java-Entwickler lernt JavaScript und der Datenbank-Entwickler wird zum Teilzeit-Java-Entwickler. Der Feature Team Primer spricht davon, dass die Teams zum Lernen gezwungen werden.

A feature team organization exploits speed benefits from specialization, as long as requirements map to the skills of the teams. But when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint. Feature teams balance specialization and flexibility. (2)

Aus meiner Erfahrung funktioniert dies in vielen Fällen nicht. Wie weiter oben bereits erwähnt, sind der Wille und die Fähigkeit zum Lernen begrenzt. Die Einführung von agilen Feature-Teams beinhaltet schon viel Neues. Auch für Entwickler, die schon länger mit agilen Methoden arbeiten, gibt es – ganz im Sinne von Continuous Improvement – immer noch vieles zu lernen und zu verbessern. Wenn Sie wählen müssten, ob ein Kollege agiles Vorgehen wie Test-Driven-Development verbessert, oder ob er ein mittelmäßiger Teilzeit-Frontend-Entwickler wird. Nun ja…

Eine gewisse Spezialisierung ist hilfreich, damit sich Expertentum bilden kann. Nur Experten werden in ihrem Bereich sehr gute Lösungen finden und implementieren können. Nur Experten werden Verantwortung für zukunftsfähige Lösungen in ihrem Bereich übernehmen.

Fazit: Die Flexibilitätssteigerung ist erstrebenswert, aber sie kann nur für solche Teams eine Lösung sein, die schon länger agil entwickeln und in denen es eine sehr hohe Lernbereitschaft gibt.

2) Komponenten-Teams

Eine Möglichkeit, die Komplexität und Anzahl der Technologien zu reduzieren ist Komponenten-Teams einzuführen. Anstatt eines gibt es zwei Entwicklungsteams, die zum Beispiel Frontend und Backend-Technologie untereinander aufgeteilt haben. Es gibt Vorteile: Die Scrum-Meetings sind fokussierter. Die Zusammenarbeit im Team wird erleichtert, die Verantwortung für die entwickelten Komponenten wächst. Die Teamaufteilung ist in vielen Unternehmen näher an der klassischen (gewohnten) Organisation.

Die Nachteile aber sind vielfältig:

• Dadurch, dass keine User Stories, sondern Komponenten-Stories bearbeitet werden, steigt der Planungsoverhead. Es müssten Integrationsphasen und daraus entstehende Rückläufer eingeplant werden.
• Das Risiko von unnötigem Aufwand steigt: Komponenten werden „auf Halde“ erweitert, ohne zu wissen, ob darauf aufbauende Features von anderen Teams jemals umgesetzt werden.
• Durch falsch verstandene Schnittstellen können leicht Bugs entstehen.
• Komponententeams können weniger Feedback zu Produktdesign und Implementierungsmöglichkeiten geben. Das Warum geht verloren, wenn Teams detaillierte technische Komponentenstories als Input erhalten.
• Nicht-funktionale Anforderungen sind schwieriger einzuhalten, da die Verantwortlichkeit dafür diffundiert.
• Es ist schwieriger Tester schon während der Entwicklung einzubeziehen.

Fazit: „It depends“ – Komponenten-Teams können in bestimmten Umgebungen Vorteile bieten, doch haben sie gegenüber Feature-Teams in der agilen Entwicklung insgesamt eine erhebliche Anzahl an Nachteilen. Lassen sich Komponententeams nicht vermeiden, so können einige der Nachteile durch überlappende Plannungsmeetings und automatisiertes Contract-Testing abmildern.

3) Größere Teams

Ein naheliegender Ansatz ist es, das Team zu vergrößern. Der Vorteil dieser Lösung ist die sehr einfache Umsetzung. Bereiche mit dem Bus-Faktor von 1 können sehr schnell personell verstärkt werden. Ich habe schon Scrum-Teams mit 16 Entwicklern gesehen.

Es gibt allerdings auch hier einige Nachteile. Erstens wird die Aufteilung in gefühlte Komponententeams innerhalb des Scrum-Teams noch zunehmen. Der zweite Nachteil nennt bereits der oben zitierte Scrum-Guide: Der Aufwand für Kommunikation und Koordination im Team nimmt stark zu. Möchte man, dass alle Teammitglieder täglich ein paar Worte direkt miteinander wechseln, sind in einem 8-köpfigen Team 28 Gespräche nötig. Bei 16 Personen müssten täglich schon 120 Gespräche geführt werden. Durch die Größe des Teams steigt auch die Velocity stark an. Klingt erst mal gut. Doch bei zu vielen User Stories in einem Sprint wird es schwierig den Fokus zu behalten. Die täglichen Standup-Meetings, wie auch Planung und Demo, dauern zu lang. Schnell passiert es dann, dass Entwickler nicht mehr aktiv teilnehmen, da der Nutzen im Vergleich zum Aufwand infrage gestellt wird.

Fazit: Die Vergrößerung des Teams scheint eine schnelle Lösung sein, um ein Wissenssilo oder einen Engpass abzubauen. Komponentengrenzen können so aber nicht aufgelöst werden. Langfristig überwiegen auch hier die negativen Folgen.

4) Reduktion der Technologien

Ein weiterer möglicher Lösungsansatz ist es die Anzahl der verwendeten Technologien zu reduzieren. Man würde sich wünschen, dass für jede neue Technologie mindestens eine alte aus dem Projekt entfernt wird. Wie in einem guten Bücherregal, aus dem man für jedes neue Buch auch eines herausnehmen muss – und so für eine stetige Qualitätssicherung und Perfektionierung sorgt. In der Praxis geschieht diese Technologie-Reduktion leider aus unterschiedlichsten Gründen oft nicht. Dabei sollten die hier zuvor genannten Probleme und Herausforderungen deutlich machen, dass es nicht unbedingt sinnvoll ist, neue Technologien einzuführen, wenn man alte dafür nicht ablösen kann.

Ist es nicht möglich, die Anzahl der Technologien im Projekt zu reduzieren, kann eine andere Strategie helfen. Im DDD gibt es das Konzept der Anti-Corruption-Layer (ACL), die verhindern, dass das eigene Domänenmodell durch unsaubere externe Schnittstellen verschmutzt wird. Durch ein technologisches ACL kann man eine Legacy-Technologie vor einem Entwicklungs-Team verbergen. Ob es die moderne REST-Fassade vor einem alten Hostsystem ist, oder die moderne Messaging-Technologie als Adapter zu einem alten selbstentwickelten System. Auf diese Weise können Komplexitäten verringert werden.

Fazit: Die Reduktion der verwendeten Technologien ist die nachhaltigste, aber auch die am schwierigsten umzusetzende Lösung. Beim Starten agiler Projekte sollte darauf geachtet werden, nicht leichtfertig neue Technologien einzuführen, wenn dafür nicht auch alte entfernt werden können. Frameworks wie Vaadin könnten dabei helfen, Barrieren zwischen Frontend- und Backend-Entwicklern zu verringern. Andere Firmen haben sich für Node.js im Frontend- und Backend entschieden, um einen homogeneren Technology-Stack zu haben. In einer heterogenen Umgebung können Legacy-Technologien durch technologische ACL verborgen werden.

Zusammengefasst: Ein heterogener Technologiestack stellt jedes Entwicklungsteam vor eine Herausforderung. Eine Flexibilitätssteigerung des Entwicklungsteams ist erstrebenswert. Notwendig ist, dass sich für jede Technologie neben dem/der Experten/in weitere Entwickler Basiswissen erarbeiten. Langfristig wird es sich auszahlen, die Anzahl der Technologien zu reduzieren.

Keine der oben genannten Lösungsansätze ist einfach oder kommt ohne Nachteile aus. Gerne stelle ich daher die Frage nach weiteren Strategien und Lösungen an die Leser: Kennt ihr die beschriebene Problematik und habt ihr weitere Ideen zur Verbesserung? Ich freue mich über eure Kommentare.