Quadratisch. Praktisch. Gut. Über den Schnitt eines Scrum-Teams

Bei der Gründung neuer Scrum-Teams stellt sich (neben der Frage nach der Zusammensetzung) die Frage nach dem besten Schnitt. Vergleichbar ist das mit einer Maus in der Küche: Soll sie erst den Käse gründlich durchlöchern oder von Anfang an Brot, Marmelade und alles weitere verkosten? Bei kleinen, überschaubaren Produkten fällt die Antwort leicht: Das Team ist dann meist für die gesamte Applikation verantwortlich und kann, zusammen mit wenigen weiteren Teams, das gesamte Funktionsspektrum von der Pike auf entwickeln und modifizieren.Bei komplexeren Produktlandschaften mit großen, über die Jahre gewachsenen Systemen, einer Pluralität an Technologien und einer Vielzahl daran arbeitender Entwickler, gibt es vor allem zwei Möglichkeiten: 

1. Entweder arbeiten die Teams an Komponenten oder
2. sie arbeiten an Features.

 Die Aufteilung nach Komponenten bietet klare Vorteile: Die Teams können mit den jeweiligen Spezialisten für diese Komponenten bestückt werden. Und die Abhängigkeiten sind im täglichen Geschäft geringer, zumal jedes Team ungestört an „seiner“ Komponente werkeln kann. Beides - die Spezialisierung und die Isolierung - sind zugleich aber auch die Nachteile von Komponententeams. Denn wenn jedes Team nur noch für seine Komponente zuständig ist, fällt der Blick über den Tellerrand ungleich schwerer.Und der Koordinationsaufwand wird dadurch nicht geringer, sondern letzlich größer. Keines der Teams liefert nutzbare Produkt-Inkremente. Erst das Zusammenspiel bringt den Nutzen. Spätestens dann, wenn getestet wird, ob alle Komponenten so miteinander funktionieren, wie sie aus Sicht des Systems funktionieren sollten, wird der übergreifende Blick für das Ganze nötig. Das ist dann oftmals zu spät, um Fehlentwicklungen zu korrigieren. Feature-Teams sind dagegen gezwungen, von Anfang an das große Ganze zu denken. Sie begleiten die Abläufe von Anfang bis Ende (end to end) und erzeugen damit in jedem Sprint den „Durchstich“, der das Gesamtverhalten des Produktes erkennen lässt - und somit auch frühzeitiges Feedback ermöglicht.Feature-Teams können als Zumutung empfunden werden: Entwickler, die sich jahrelang auf die technischen und fachlichen Raffinessen eine Komponente spezialisiert haben, müssen plötzlich ganz von vorne anfangen. Und wenn zwei oder mehr Feature-Teams an den gleichen Komponenten arbeiten, kann leicht etwas kaputt gehen - ohne dass sofort klar ist, wer es gewesen ist.Diese Hürden lassen sich nur mit „interdiszplinären“ Teams überwinden, in denen das Wissen für den gesamten Prozess vorhanden ist und jeder bereit ist, Neues zu erlernen und Altes abzugeben. Ebenso wichtig ist ein hoher Qualitätsanspruch - also eine ehrgeizige Definition of Done. Feature Teams werden auf Dauer nicht mit modularen Tests auskommen. Automatisierte Integrationstests, End-to-End-Tests und teamübergreifender Austausch (Stichwort: Scrum of Scrums) sind unerlässlich, um möglichst noch im laufenden Sprint Feedback bei Unstimmigkeiten zu erhalten und zum Ende des Sprints einen grünen Build hinzubekommen. Das alles kann, je nach Komplexität und Alter des Produktes, einen großen Aufwand bedeuten. Wer aber agil entwickeln möchte, um am Ende eines jeden Sprints das Produkt (und nicht Teile davon!) inkrementell weiter zu entwicklen, der wird nicht umhin kommen, Feature-Teams zu gründen.Falls bereits Teams am Laufen sind, lohnt es sich, deren Kommunikationsverhalten zu beobachten. Fragt das eine Team im SoS ständig nach den Experten aus dem Print-Service, weil der Benutzer sich am Ende jedes Sprints freut, wenn die Rechnung nicht nur abrufbar, sondern auch ausdruckbar ist? Dann lohnt es sich vielleicht, das Team um jenen Experten zu ergänzen, und so den funktionalen Scope des Teams evolutionär zu erweitern. Auch hier gilt die alte Devise: Ask the team! Was am Reißbrett Sinn macht, muss noch lange nicht in der Praxis funktionieren. Literatur Mike Cohn: Suceeding with Agile. Addison-Wesley 2009.Dean Leffingwell: Agile Sofware Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley 2010.