Agiler Beipackzettel

INSPIRATION: Der Scrum-Ansatz ist in der agilen Praxis prominent. Seine Besonderheit: Er wartet mit einer Teilung der Führungsfunktion auf. Der Product Owner soll die Interessen des Kunden und weiterer Stakeholder vertreten. Der Scrum Master soll die Prozesse im Entwicklungsteam gestalten. Aber eigentlich gibt es noch eine dritte Führungsfunktion: das Team.

Aber dazu später. Im Beitrag der Autor:innen (Agiles Projektmanagement) geht es vor allem um die beiden ersten Rollen. Da es sich bei den Autor:innen um Wissenschaftler:innen handelt, haben sie eine Ungereimtheit gefunden, die sie aufklären wollen. In der einschlägigen Literatur würde zwar zumeist auf die Funktionen und Aufgaben der beiden Scrum-Rollen eingegangen. Unklar bliebe jedoch zumeist, welche konkrete Anforderungen an die Rolleninhaber damit verbunden sein sollen.

---

Anzeige:

Wir sind Experten für 360° Feedback-Instrumente und für Mitarbeiterbefragungen, die wirklich etwas verändern. Unser erfahrenes Team unterstützt unsere Kunden in allen Projektphasen, also von der Konzeption über die Ein- und Durchführung bis hin zur Arbeit mit den Ergebnissen. Unsere innovativen Tools sind 'Made & hosted in Germany', werden inhouse entwickelt und ständig optimiert. Neugierig? Zur Webseite...

---

Es fehlt schlicht eine professionelle Anforderungsanalyse, die empirisch beschreibt, wie man diese Rollen kompetent ausüben kann. Damit sollte auch die Unterscheidung beider Rollen in spezifischen Anforderungssituationen klarer werden.

Von 2 Seiten in die Zange genommen

Die Wissenschaftler:innen haben 32 Personen, die im Schnitt sieben Jahre Erfahrungen mit den agilen Rollen hatten, mit der Methode der kritischen Ereignisse intensiv befragt. Zudem wurden jeweils fünf Mitarbeitende, die in den beiden agilen Rollen seit über neun Jahren arbeiteten, ebenso intensiv mit der Repertory-Grid-Technik befragt. Beide Methoden sind bewährt, schauen aber aus etwas unterschiedlichen Blickwinkeln auf die Materie. Bei der ersten geht es eher um konkretes Verhalten, die zweite fokussiert mehr auf überdauernde Eigenschaften. Das heißt, sie ergänzen sich gut bei der Anforderungsanalyse.

Auf diese Weise ergaben sich „über 400 Beschreibungen produktiven und unproduktiven Verhaltens, die inhaltsanalytisch ausgewertet und zu Anforderungsprofilen für beide Rollen verdichtet“ wurden. Eine Heidenarbeit, mag man anerkennend anmerken. Diese Beschreibungen wurden nun dem Great-Eight-Kompetenzmodell nach Bartram zugeordnet.

In ein deduktives Kompetenzmodell übersetzt

Dieses Modell hat drei Ebenen mit insgesamt 112 Einzelkompetenzen. Auf dieser untersten Ebene spiegeln sie konkrete, gut beobachtbare Verhaltensweisen. Auf der mittleren Ebene werden diese zu 20 übergeordneten Kompetenzdimensionen zusammengefasst. Und auf der obersten Ebene werden diese zu acht Kompetenzclustern, die von grundsätzlicher Bedeutung für Arbeitsleistung sind, aggregiert: Führen und Entscheiden, Kooperieren und Unterstützen, Interagieren und Präsentieren, Analysieren und Interpretieren, Kreieren und Konzeptualisieren, Organisieren und Ausführen, Anwenden und Anpassen, Unternehmen und Leisten. – Und so ließen sich die Anforderungsprofile ermitteln:

• Scrum Master: Unter den neun Anforderungsmerkmalen stechen Team- & Prozessorientierung, Organisationsfähigkeit & Problemlösekompetenz sowie Teambuilding- & Coaching-Fähigkeiten heraus. Sie werden am häufigsten genannt (jew. ca. 20%).
• Product Owner: Unter den acht Anforderungsmerkmalen stechen „Ziel-, Produkt- & Nutzenorientierung“ sowie „Kommunikationsfähigkeit & Beziehungsmanagement“ heraus. Sie machen zusammen über 50% der Nennungen aus.

Legt man nun die beiden Profile übereinander, zeigen sich deutliche Unterschiede – die nun bis auf Verhaltensebene herunter dekliniert werden können. Die Wissenschaftler:innen belassen es aber nicht dabei, ein schönes Chart zu liefern, sondern beschreiben auch typische Situationen, die die beiden Rollen meistern müssen.

Kritische Situationen für Scrum Master

• Disput im Scrum Team: Das Entwicklungsteam ist beispielsweise mit den Zielvorstellungen des Product Owners unzufrieden. Job des Scrum Masters ist es, eine Konfliktlösung zu moderieren.
• Probleme bei der Erreichung der Teamziele: Job des Scrum Masters ist es, diese zu erkennen und bei der Beseitigung zu helfen.
• Leitung von Scrum Events: Daily Scrum oder Retrospektiven müssen nach den Regeln der Kunst stattfinden und kompetent moderiert werden.

Kritische Situationen für Product Owner

• Interessenkonflikte zwischen Stakeholdern und Scrum Team: Die externen Kunden haben beispielsweise Erwartungen, die an die Grenzen (Kapazität oder Leistungsfähigkeit) des Scrum Teams gehen. Der Product Owner muss solches an die Stakeholder vermitteln.
• Probleme im Aufstellen von Zielen und Visionen: Weil unausgesprochene Erwartungen an ein Produkt existieren oder die Anforderungen an das Produkt noch zu unklar sind, müssen solche implizitzen Erwartungen expliziert und potenzielle Zielkonflikte geklärt werden.
• Umgang mit technischen Anforderungen: Der typische Konflikt aus der Welt des Außendiensts bekannt – wenn der Innendienst die Augen verdreht. Hat der Kunde unrealistische Vorstellungen, der Product Owner zu viel versprochen oder kann oder will das Team nicht liefern? Der Product Owner muss dolmetschen und verhandeln.

Weitere Anwendungsideen

Wenn man die Lage schon einmal so klar und verhaltensnah auf dem Tisch hat, liegt der nächste Schritt auf der Hand: Der schlaue Eignungsdiagnostiker konzipiert sogleich ein AC für die beiden Rollen. Was man natürlich auch für die Personalentwicklung nutzen kann als Verhaltensplanspiel. Gut gefallen hat mir die Idee, dabei einen systematischen Rollentausch von Product Ownern und Scrum Mastern zu ermöglichen.

Aber gefehlt hat mir bei all dem die Rolle des „dritten Manns“: des Teams. Führung wieder auf die beiden Rollen – Product Owner und Scrum Master – zu verkürzen, erscheint mir angesichts der Kritik am Konzept der Agilität (Auf dem Holzweg) doch arg fahrlässig. Das Thema Selbstführung von Teams dürfte nicht minder spannend zu erforschen sein. Vielleicht lesen wir demnächst ja mehr über dieses Thema.