Heisst Agilität «alle machen alles»? Kürzlich ist diese Frage in einer Diskussion mit einem Scrum Master aufgetaucht. Er macht sich Sorgen, dass es in seinem Team zuviele «agile Spezialisten» gibt: Die Datenbankanbindung macht immer die gleiche Person. Nur eine einzige Mitarbeiterin hat sich in das Thema User Experience eingearbeitet. Das Web-Frontend machen immer noch die zwei Mitarbeiter, die schon seit Jahren Javascript beherrschen und vor der Einführung von Scrum zu einem reinen Frontend-Team gehörten. Müsste sich das mit der Einführung von Scrum nicht ändern? Und wenn ja, was genau könnte er in dieser Hinsicht machen? Wenn er das Thema aufbringt, stösst er in seinem Team auf eine richtige Mauer aus Widerstand.
Was heisst crossfunktional genau?
Woher kommt denn überhaupt die Idee, alle müssten alles machen? Im Scrum Guide ist von «crossfunktionalen Teams» die Rede:
Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
https://scrumguides.org/scrum-guide.html#scrum-team
Gemäss der «reinen Lehre» ist es also nicht nötig, dass in einem Scrum-Team jeder alles macht und keine Spezialisierung mehr vorhanden ist. Voraussetzung ist natürlich, dass die Spezialisierung nicht in einer Hierarchie oder strukturellen Abgrenzung mündet: Wir sind die drei Tester, wir kommen nicht ans Standup bzw. ich als Architektin und Vorgesetzte sage euch genau, wie ihr es machen müsst und ihr habt euch daran zu halten. Es müssen in einem Team nur alle Fähigkeiten vorhanden sein, um innerhalb eines Sprints «Wert» (mit direktem Kundennutzen) zu generieren. So weit, so gut – als Agile Coach kann ich also den Fragenden erstmal beruhigen: Nein, selbstverständlich kannst du auch bei richtig striktem Scrum weiterhin Spezialisten und Expertinnen in deinem Team haben.
Expertinnen und das Commitment: Die Vertrauensfrage
In der Praxis ist es dann allerdings subtiler. Das Thema taucht häufig beim Planning auf, wenn gemeinsam festgelegt wird, welcher Arbeitsumfang bis zum nächsten Sprintende erledigt wird. Der Scrum-Master fragt in die Runde: «Könnt ihr euch zu dem, was jetzt da steht, committen?»
Commitment als Team? Das würde ja heissen, ich übernehme die Verantwortung für Dinge, die ich gar nicht unter Kontrolle habe? Das tönt dann so: «Ich kann mich nicht committen! Weil ich doch nicht weiss, ob Babsy das mit dem Videoschnitt hinkriegt!» – «Was sagt denn Babsy?» – «Das ist easy, kann ich machen». «Trotzdem – ich möchte mich nicht committen».
Hier geht es ganz subtil eigentlich um das gegenseitige Vertrauen im Team. Vereinfacht gesagt: Je mehr Spezialismus in einem Team herrscht, desto grösser muss das gegenseitige Vertrauen sein. Nur dann kann sich das Team als Ganzes zu einem Arbeitspaket committen. Eine wichtige Folgefrage wäre hier: «Was können wir als Massnahme einplanen, damit dir das Commitment in zukünftigen Sprints leichter fallen würde?» Möglicherweise heisst die Antwort: «Ich möchte selber einen Kurs in Videoschnitt belegen», möglicherweise aber auch, dass sich das Team frühzeitig um die Entlastung von Babsy in anderen Aufgaben bemühen wird und ihre Auslastung gut im Auge behält. Manchmal löst sich das Problem von selber, wenn Babsy mehrfach beweisen konnte, dass sie ihre Fähigkeiten zuverlässig in den Dienst des Teams stellt.
Im Grunde ist auch die Formulierung des Commitments im Scrum Guide nicht so hart, wie es gewisse Teams manchmal auffassen:
The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.
https://scrumguides.org/scrum-guide.html#scrum-values
Es geht um gegenseitige Unterstützung und um den «bestmöglichen» Fortschritt im Bezug auf das anvisierte Ziel. Mühe mit dem Commitment kann auch darauf hinweisen, dass der Umgang mit Scheitern in der Organisation noch suboptimal ist. Werden Teams abgestraft oder blossgestellt, wenn sie das Ziel nicht erreichen, werden sie sich in Zukunft weniger gern committen. Das Vermeiden von Spezialisierung ist dann nur eine Scheinlösung für ein grösseres Problem.
Agile Spezialisten stören die Burndown-Chart!
Dennoch – Spezialistentum kann negative Effekte auf die Effizienz von Scrum-Teams haben. Dies ist an manchen Dailies zu beobachten: «Als nächstes mache ich… hmm, nein, die Datenbank, das ist das Thema von Josua… und hier, API festlegen… das würde wohl besser Chiara machen, wenn sie morgen wieder da ist?» Weniger erfahrene Mitarbeiter getrauen sich manchmal nicht, anspruchsvollere Aufgaben in Anspruch zu nehmen. Dies ist eine verlorene Gelegenheit zum Knowhow-Austausch und stört den Flow – man beginnt auf SpezialistInnen zu warten, die Auslastung der einzelnen Teammitglieder schwankt.
Umgekehrt gibt es auch folgende Situation: «Als nächstes implementiere ich die Schnittstelle für die «Kauffunktion», und dann auch noch für «Profiländerung», das muss ja auch ich machen… ah ja, und hier ist noch «Item löschen», das kann ich dann alles im gleichen Aufwasch erledigen.» Manche agile Spezialisten sammeln Aufgaben auf Vorrat in der Meinung, es sei besser, gleichartige Aufgaben miteinander zu erledigen. Schnell ist dies meist schon. Nicht ohne Grund steht bei Scrum allerdings das Vorgehen nach dem «Wert» im Vordergrund, nicht das «schnellste Vorgehen». Werden von diesen Funktionen schliesslich zwei nicht nutzbar fertig und auf später verschoben, muss möglicherweise die Aufgabe ein zweites Mal mit ganz veränderter Ausgangslage erledigt werden. Oft wäre es besser, die Spezialistin würde stattdessen auch Aufgaben ausserhalb ihres Spezialgebiets übernehmen.
Wie geht das Team mit Spezialistentum um?
Spezialisten und Expertinnen sträuben sich oft gegen die Einführung von Scrum. Oft sind die Mythen rund um crossfunktionale Teams oder falsch verstandene «Interdisziplinarität» der Grund. Man fürchtet, den Respekt der anderen zu verlieren und seine «Mastery» im Beruf nicht mehr leben zu können. Sorgen um die Qualität des Resultats sind ebenfalls ein legitimer Grund. All dies muss auch beim Einführen von Scrum wichtig und berücksichtigt bleiben.
Spezialistentum darf es geben, jedoch besteht in einem Scrum-Team kein Recht auf «Gärtchendenken». Es ist die Aufgabe des Scrum-Masters, darauf einzuwirken dass nicht nur nach aktueller Effizienz gehandelt wird, sondern auch Investitionen in die Zukunft des Teams gemacht werden. Die Frage ans Team wäre hier: «Wie können wir Qualität sicherstellen, auch wenn weniger erfahrene Mitarbeiter eine Aufgabe in Angriff nehmen? Wie können wir eine gute Balance zwischen Qualität und gleichmässiger Auslastung des Teams finden?» Die Antworten auf diese Fragen muss jedes Team individuell finden und auch immer wieder neu festlegen – ganz im Sinne der kontinuierlichen Verbesserung.