Alle können nicht alles wissen. Dass das auch für ein Entwicklungs-Team gilt und auch gar nicht nötig ist, haben wir im ersten Teil dieser Blogserie unterstrichen. Dieser Blogeintrag thematisiert eine weitere, spannende Frage, die auf der folgenden Erkenntnis beruht:

Selbst wenn ein Scrum-Team [1] aus der (fast) perfekten Mischung aus Spezialisten und Generalisten besteht, kann es vorkommen, dass das Team eben nicht „das gesamte Wissen und die Fähigkeiten, die für das Projekt nötig sind“ [2] hat. Wie geht das Entwicklungs-Team damit um, dass es für einen oder mehrere Sprints einen Spezialisten braucht?

Viele Beiträge weichen dieser Frage aus, indem sie schreiben, dass das Entwicklungs-Team cross-funktional ist. [3] An dieser Stelle lädt die Realität allerdings zum Weiterfragen ein.

Aus dem Scrum Guide entnehmen wir dazu folgende Rahmenbedingungen:

„Während des Sprints […] [b]leibt die Zusammensetzung des Entwicklungs-Teams konstant.“ [4]

Führt man sich vor Augen, dass sich genau dieses Team zur Umsetzung von User Storys verpflichtet hat, wäre ein neues Teammitglied, dem diese Beziehung zu den User Storys fehlt, fatal. [5] Ein fehlender Spezialist kann also keine Rechtfertigung dafür sein, ein Scrum-Team während eines Sprints anders zu besetzen.

Wird nun aber, z. B. im Daily-Scrum, eine Wissenslücke als Hindernis (engl. impediment) identifiziert, muss das Entwicklungs-Team gemeinsam mit dem Scrum-Master klären, in welchem Umfang ein Spezialist gebraucht wird und anschließend mit dem Product-Owner Rücksprache halten. Die Bereitschaft, Probleme offen zu diskutieren, soll an dieser Stelle hervorgehoben werden. Sie ist ein Beleg dafür, dass das Scrum-Team wirklich als Team zusammenarbeitet und dass die Kommunikation im Team auf der Basis gegenseitigen Vertrauens beruht und funktioniert.

Bei der Klärung der Frage, welche Kompetenzen dem Entwicklungs-Team fehlen, um das Sprintziel zu erreichen, hilft es, zwischen menschlichen und fachlichen Aspekten zu unterscheiden. [6] Fehlt es an Fachwissen, sollten Sie klären: Reicht es, einen Spezialisten zu einem Interviewtermin einzuladen (Anforderungsermittlung mit einem Stakeholder) oder sollte er während des gesamten Sprints als Teil des Entwicklungs-Teams an der Umsetzung der User-Storys arbeiten? [7] Binden Sie nicht einen Spezialisten nach dem anderen in Ihr Team ein. Zum einen wird das Team so immer größer und ggf. ineffizienter (Integration und Kommunikation mit dem „Neuling“ binden Ressourcen). Zum anderen besteht die Gefahr, dass sich die Verteilung der Arbeit im Entwicklungs-Team verschiebt und die ursprünglichen Teammitglieder immer weniger zu tun haben.

In der Retrospektive bespricht das Scrum-Team offen, was im letzten Sprint gut gelaufen ist und was verbessert werden kann. Da das fachliche Soll bereits im Sprint Review abgenommen wurde, stehen in der Retrospektive Aspekte wie Kommunikation und Umgang miteinander im Mittelpunkt. Das Team untersucht sich selbst, um Verbesserungen „in Bezug auf die Mitarbeiter, Beziehungen, Prozesse und Werkzeuge“ [8] zu identifizieren.

Wie so oft gibt es auch für die Einbindung eines Spezialisten in Scrum kein Patentrezept. Die Einbindung bedarf einer Situationsanalyse und darf nicht im Widerspruch zu den Spielregeln von Scrum stehen.

Stichwort Spielregeln: Feedback an uns widerspricht garantiert keiner Spielregel!

Zu guter Letzt noch der Hinweis auf den dritten Blogteil dieser Serie. Er wird sich mit der Frage beschäftigen, ob es Sinn macht, einen Requirements-Engineer in das Scrum-Team zu holen. Und ohne Ihnen die Spannung zu nehmen – Sie können sich denken, dass die SOPHISTen diese Frage mit einem aus voller Kehle erschallendem Ja beantworten.

———————————————–

Quellen:
[1] Mehr Informationen zu Scrum finden Sie auch neuen Auflage unseres Bestsellers: Chris Rupp & die SOPHISTen: Requirements Engineering und -Management. Aus der Praxis von klassisch bis agil. Hanser 2014.