Wenn alle Teammitglieder nicht 100% für die Arbeit in Sprints zur Verfügung stehen, dann würde ich mir fragen wieso man nach Scrum arbeitet. Eine wichtige Voraussetzung damit Scrum richtig funktioniert ist, dass die Teammitglieder 100% für die Arbeit im Scrum-Team verfügbar sind. Hier einige Gründe warum das so ist:
- Scrum Teams planen was sie im Sprint machen werden und geben ein Commitment dafür ab. Wenn Menschen sich parallel für verschiedenen Sachen verpflichten, dann entstehen unvermeidlich Interessenskonflikte und Verzögerungen. Sie müssen dann selbst entscheiden welche Bälle sie fallen lassen, das geht immer auf Lasten einer der Aufgaben die gerade parallel erledigt werden müssen.
- Scrum Teams lernen aus der Vergangenheit. Sie messen wieviel sie in einem Sprint schaffen und verwenden diese Information um zukünftige Sprints zu planen. Das geht nicht wenn sich die Verfügbarkeiten ständig ändern und Mitarbeiter mal mehr, mal weniger Druck bekommen andere Dinge parallel zu machen.
- Diese Teil-Commitments verursachen endlose Eskalationsmeetings wo Führungskräfte für die eigenen Interessen kämpfen müssen. Ich für mein Projekt, er für seine Ziele. Das kostet der Organisation nicht nur viel Zeit sondern auch Motivation von Mitarbeiter und Führungskräfte.
In vielen Fällen lässt sich das Problem einfach lösen, indem:
- Teamstrukturen angepasst werden. Zum Beispiel von Komponententeams zu Feature-Teams. Wenn ein Mitarbeiter immer wieder in verschiedenen Teams arbeiten muss, dann liegt es in den meisten Fällen daran, dass die Teams nicht richtig "geschnitten" sind. Vielleicht hat die Struktur mal seine Berechtigung gehabt und die Umstände haben sich geändert. Dann sollte die Struktur angepasst werden.
- Zuweisung von Aufgaben zu Teams korrigiert werden. Manchmal ist es so, dass die Aufgaben eines Mitarbeiters in 3 verschiedenen Teams zerstreut sind. In solchen Fällen müssen die Aufgaben besser zu den Teams zugewiesen werden damit ein Product Owner (PO) ein stabiles Team hat und er bestimmt welche Aufgaben dieses stabile Team lösen soll. Das geht zwischen Scrum Teams sehr einfach, wenn die POs zusammenarbeiten und an einer gemeinsamen Roadmap arbeiten.
Einige Fälle die oft auftreten wo solche Situationen entstehen:
- Es gibt ein Team für Entwicklung und eins für Fehlerbehebung. Wenn ein Kunde ein Fehler meldet, dann wird immer wieder ein Mitarbeiter aus der Entwicklung geholt um das Problem zu lösen. Lösung: Entwicklung und Fehlerbehebung für ein Produkt (oder Teilprodukt) in einem Team. Damit ist der PO derjenige der entscheidet ob was neues entwickelt wird oder ob Kundenprobleme gelöst werden sollen. Somit wird der PO vom Produktentwicklungsowner zum Product-Owner befördert.
- Es gibt in einem Team ein Spezialist der von anderen Teams immer wieder benötigt wird. Das passiert oft am Anfang, wenn Scrum gerade eingeführt wird. Lösung: So eine Situation muss ständig und mit hoher Priorität gelöst werden indem die Wissens- oder Erfahrungslücke durch Einstellung fehlender Mitarbeiter oder durch Weiterbildung und Erfahrungsaustausch gefüllt wird. Oft können solche Spezialisten mit weniger Aufwand als anfangs befürchtet durch andere Mitarbeiter ersetzt werden.
- Ein Mitarbeiter wird einen Scrum-Team zugeteilt und bringt ein Sack voller Aufgaben mit. Er verpflichtet sich zu 80% für die Sprint-Ziele und lässt 20% offen für sein eigenes (verstecktes) Backlog an Aufgaben. Lösung: dem PO die Verantwortung für diese mitgebrachten Aufgaben geben. Er muss dann entscheiden in welcher Intensität sein Team an welchen Aufgaben arbeiten muss. Die Zuweisung der Aufgaben ist nicht mehr zu einem Mitarbeiter, sondern zu einem Scrum-Team.
Generell, damit Scrum gut funktioniert müssen die Teammitglieder zu 100% für ein Team arbeiten. Die Zuweisung von Mitarbeiter zu Team kann sich mit der Zeit ändern (aber nicht zu oft!) Die prozentuale Verteilung von Mitarbeitern zu verschiedenen nebenläufigen Aufgaben oder Projekte ist kontraproduktiv. Fortschritt wird überall langsamer und die Lage wird generell unübersichtlicher. Einfacher (und auch effektiver) ist wenn ein Product Owner entscheidet an welchen Themen die Mitarbeiter eines Teams arbeiten müssen. Damit werden Interessenskonflikte, Verzögerungen und Chaos vermieden.
Oft höre ich, dass eine Firma zu klein oder ein Ziel zu sportlich ist um sich leisten zu können, dass ein Mitarbeiter/Team nur an einer Sache arbeitet. Das ist ein Widerspruch. Wenn er sequenziell immer nur an einer Sache arbeitet, dann geht es schneller voran. Es ist also nur eine schlechte Ausrede um eine schlechte Organisation schönzureden.
