Derzeit erlebe ich, sehr konzentriert, welche Schmerzen es im Alltag verursacht, mehrere Scrum-Rollen gleichzeitig „in persona“ zu bedienen.

Viele Agile Coach und Scrum Master-Kollegen kennen dies, wenn sie mal eben den urlaubs- oder krankheitsbedingten Ersatzplayer mimen sollen.

1 Scrum Master : N Teams

Als Scrum Master [SM] seinen SM-Kollegen für seine drei Urlaubswochen in der selben Scrum-Rolle zu vertreten – zusätzlich zu den SM-Aufgaben für sein eigenes Team – stellt ganz spontan eine terminliche Kapazitätsherausforderung dar. Einen Rollen-Konflikt gibt es hiermit nicht. Vielleicht kennt man „sein“ Team sogar schon von regelmäßigen → Scrum Master Pairings und die → Kennenlern-Phase [1] ist damit leichter.

Mit dieser Doppelaufgabe einher ergeben sich allerdings auch schon sehr kurzfristig Qualitätsprobleme.

→ Impediments, zum Beispiel, können nicht mehr in der genügenden Tiefe, Ernsthaftigkeit und Dringlichkeit begleitet werden. Eine bisher seriös und mit entsprechendem Mindset unterstützte 40 Stunden-Woche für ein Team nun auch nur vorübergehend auf zwei Teams verteilen zu müssen, offenbart – ehrlich und transparent begleitet – an unzählbar vielen Stellen Defizite. Dazu vielleicht konkrete Erfahrungen aus der Praxis an anderer Stelle einmal mehr.

Erschreckend zu hören, wenn man von im Metier noch frischen Scrum Mastern hört, dass sie ganz normal drei oder mehr Teams begleiten (müssen?) – Tag aus, Tag ein.

Scrum Master als Entwickler – oder umgekehrt

„Beliebt“ im Projekt-Alltag sind die Konstellationen, in denen der Scrum Master aufgrund seines IT-Hintergrundes auch mal eben den Entwickler spielen soll – zusätzlich und obendrauf, nicht ausnahmsweise, sondern regelmäßig.

Begehrt und immer wieder anzutreffen ist der Versuch, dass der Chef-Entwickler – als vermeintliche Führungspersönlichkeit, „Laut“-Sprecher bzw. Team-Mitglied mit „speziellen“ Social Skills (→ „I’ll call him Bob“ [2]) – nun „…auch mal nebenbei den Scrum Master machen kann…“ [O-Ton aus einem mir sehr gut bekannten Projekt-Umfeld].

Product Owner-Proxy

Immer wieder erlebt man auch diese Variante:

ein spezielles Mitglied aus dem Entwicklungsteam unterstützt den Product Owner [PO] nicht nur im selbstverständlichen Sinn von Scrum – wie seine anderen Team-Kollegen dies auch tun – , sondern ersetzt den PO sogar komplett als PO-Proxy. Mit allem Drum und Dran („…wer hat dann gleich nochmal die Verantwortung …?“).

Manchmal ist dies aus der Not geboren, weil der PO nicht mehr im Unternehmen arbeitet. Hin und wieder aber auch aufgrund mangelnder Kenntnis der Product Owner-Rolle und einer damit fehlerhaften Kapazitätsplanung für seine Person, die ihn im Projekt „überraschenderweise“ erheblich mehr als geplant (vermutet?) fordert.

Die möglichen Gründe sind vielfältig.

Cross-functional Entwicklungsteam

Gewollt und sehr praxisgerecht sind natürlich die verschiedenen Rollen im Entwicklungsteam, in denen nach → Cross-funcitonal Manier kooperiert wird. Zum Beispiel

• unterstützt der Java-Spezialist die Tester,
• der UI-Spezialist lernt seine Kollegen an,
• der Architekt entwirft – integriert im und mit dem Team – Form und Struktur des Systems,
• oder der Backend-Guru verteilt sein Wissen sinnvoll im Team,

etc. – und alles selbstredend vice versa, den → „Bus Factor“ beachtend.

Alle Scrum-Rollen gleichzeitig ?

Verschiedentlich findet man in den Projekten, nicht nur bei ganz kleinen, Situationen vor, in denen eine Person so gut wie alle Scrum-Rollen gleichzeitig versucht zu bedienen (→ Beispiele [3]).

Selbst merke ich aktuell in zwei – demnächst vermutlich drei – von mir initiierten Non-Profit-Projekten, welche Schmerzen ich als überwiegend One-Man-Show erlebe. Sämtliche anfallenden Aufgaben müssen quasi gleichzeitig aus der jeweiligen Perspektive von Product Owner, Stakeholdern, Scrum Master und Entwicklungsteam („dort“ als Architekt, Tester, UI- und Server-Entwickler, etc.) organisiert, abgearbeitet und verantwortet werden.

Dabei spielt mir mein langjähriger und leidenschaftlicher Entwicklerhintergrund immer wieder Streiche.

Wenn ich beispielsweise in der Rolle des PO’s an den User Stories feile, diese bewerte und versuche über → Story Points, Business und RiskValue und sonstiger Kriterien den Anwendernutzen herauszuarbeiten, „funkt“ mir mein Entwickler-Teufelchen mit einer ungeahnten Kreativität und Reichhaltigkeit für „technische User Stories“ dazwischen. Diesen Ideen dann über Tasks, die sinnvoll User Stories zugeordneten werden, einen geordneten Fluss und Wert(!) zu geben, ist zumindest anfangs ungeübt eine Qual und immer wieder Gegenstand unzähliger Diskussionen zwischen Entwicklungsteams, Product Ownern und Scrum Mastern.

Allerdings, stellt man sich dieser deutlichen Herausforderung, ergeben sich durch das aktive Verschieben der Betrachtungswinkel deutlich klarere, strukturiertere, fokussiertere und damit wert-vollere, nicht so technik-verliebte Lösungen.

Dennoch, die Kontroversen, die sich durch den Mix verschiedener Rollen und Verantwortungen zunächst vielleicht nur für den betroffenen „All in One“ Mitarbeiter ergeben, schlagen schneller als vermutet insgesamt negativ auf das Projekt durch – nicht nur als zeitlicher Ressourcen-Konflikt.

Es kann, wenn überhaupt, nur eine sehr, sehr kurzfristige → Not-Lösung [4] sein…

Welche Erfahrungen hast Du
oder habt Ihr im Team damit gemacht,
wenn von einem Kollegen
mehrere Scrum-Rollen verlangt wurden?

Positive, negative, …?

CU
@ Boeffi  .net     aktualisiert am 24.05.2018

[1]
→ Teambildung hier in Bezug zum und mit dem Scrum Master

[2]
→ Best at argument != Best ideas – Esther Derby

[3]
→ Cargo Cult – “Impediments haben wir (eigentlich) keine!”
→ Product Backlog-Praxis – Hilfe, wir ertrinken…

[4]
Häufiger erlebe ich, dass Projekte über längere Zeit im „Not-Betrieb gefahren“ werden (Stichworte → „Wassermelonen grün“, → „rote Laterne“, „Fire Fighting“) und → Projektkrisen zur Normalität erhoben werden.