Wann sollte ein Scrum Master bei Problemen eingreifen?
Inhaltsverzeichnis
Das Sprint Planning ist ein einziges Chaos. Ein Entwickler jammert: „Unsere Meetings könnten kürzer sein, wenn wir uns mal fokussieren würden!“ Auf die Frage nach Verbesserungsvorschlägen folgt nur ein Schulterzucken: „Keine Ahnung, du bist doch der Scrum Master!“ Klingt vertraut?
Als Scrum Master sitzt du oft zwischen den Stühlen – ständig bemüht, das Team zu unterstützen, aber auch darauf bedacht, ihre Selbstorganisation zu stärken. Doch wann wird eine kleine Herausforderung zu einem echten Problem? In diesem Beitrag erfährst du, wie du Konflikte im Team frühzeitig erkennst und effektiv darauf reagierst.
Was ist ein „Problem“ in Scrum?
Ein Problem im Scrum-Kontext ist jede Situation, die das Team daran hindert, maximalen Wert zu liefern. Ob Herausforderungen, Blocker oder Impediments – sie alle beeinträchtigen die Teamleistung. Dabei gibt es unterschiedliche Arten von Problemen, die man z.B. folgendermaßen unterscheiden könnte:
- Zum einen Probleme mit dem Produktwert: Diese gehören in den Aufgabenbereich des Product Owners, da sie den Anwendernutzen beeinflussen. Ein Beispiel hierfür ist die mangelnde Benutzerfreundlichkeit einer neuen Funktion, die dazu führt, dass Anwender Schwierigkeiten haben, sie zu nutzen und daher auf alternative Lösungen ausweichen.
- Zum anderen Wertschöpfungsprobleme: Diese betreffen die effiziente Nutzung von Ressourcen und fallen in die Domäne des Scrum Masters. Ein Beispiel hierfür ist die unzureichende Kommunikation im Team, die zu Verzögerungen führt, weil Aufgaben doppelt bearbeitet werden oder wichtige Informationen nicht rechtzeitig ausgetauscht werden.
Daher ist es wichtig, diese Probleme frühzeitig zu erkennen, um die Leistungsfähigkeit des Teams zu sichern.
Wie erkenne ich Probleme im Scrum-Team?
Ein Problem sollte zeitnah adressiert werden, wenn es die Leistungsfähigkeit des Teams stark beeinträchtigt.
- Fehlende Personen: Relevante Personen fehlen regelmäßig bei Meetings.
- Zeitmanagement: Die Zeit in Meetings übersteigt die Zeit für operative Arbeit.
- Ressourcenengpässe: Es gibt Flaschenhälse bei einzelnen Teammitgliedern.
- Kommunikationsprobleme: Abwesenheiten werden nicht kommuniziert.
- Verzögerungen: Unvorhergesehene Abhängigkeiten in andere Abteilungen oder zu Dienstleistern.
- Stakeholder-Engagement: Stakeholder nehmen selten oder nie an Reviews teil.
- Überlastung: Ein Teammitglied arbeitet dauerhaft über seiner Kapazität.
Zusätzlich sind subtile Hinweise wie „Ja, das hatten wir schon mal“ oder „Ich warte da schon eine Weile drauf“ oft der Beginn eines werdenden Problems. Zum Beispiel könnte ein Teammitglied, das immer über seine Kapazität arbeitet, bald nicht nur Projekte, sondern auch seinen eigenen Gesundheitszustand gefährden – ein klassisches Beispiel für Multi-Tasking der unangenehmen Art.
Wann sollte ein Scrum Master bei Problemen eingreifen?
Diese Indikatoren sollten als Gelegenheit gesehen werden, proaktiv einzugreifen, um größere Probleme zu verhindern. Aber wann ist der richtige Zeitpunkt dafür?
Ein Problem wird zur Herausforderung, die sofortiges Eingreifen erfordert, wenn die Entwickler in ihrer Arbeit gestört werden – sei es durch Einflüsse von außen (z.B. U-Boot-Projekte, ‘kleine’ Gefallen, die länger dauern) oder durch interne Problemstellungen (z.B. fehlendes Werkzeug, fehlendes Knowhow).
Nicht immer sollte ein Scrum Master direkt ein Problem selbst lösen, um die Selbstorganisation des Teams zu stärken. Es ist wichtig, das Team dazu zu ermutigen, Probleme selbst zu lösen und sie dabei zu unterstützen. Je nach Reifegrad des Teams ist mehr oder weniger Eingreifen sinnvoll. Fehler zuzulassen kann lehrreich sein, solange es das Projekt nicht gefährdet.
Wie spreche ich Probleme im Scrum-Prozess an?
Es gibt mehrere Gelegenheiten innerhalb des Scrum-Prozesses, um Probleme zu thematisieren:
- Daily Scrum: Tägliches Meeting, um Hindernisse in Bezug auf das Sprintziel transparent zu machen und ggf. Änderungen am Sprint Backlog vorzunehmen.
- Review: Inspektion der Arbeitsergebnisse und Einholen von Feedback. Nutze dieses Meeting, um Stakeholder einzubeziehen und ihre Erwartungen zu managen.
- Planning: Planung des nächsten Sprints und Identifikation möglicher Risiken. Hier können mögliche Probleme frühzeitig erkannt und Maßnahmen zur Prävention geplant werden.
- Retrospektive: Rückblick auf den vergangenen Sprint, um Verbesserungsmöglichkeiten zu identifizieren. Fördere eine offene Diskussion und ermutige das Team, Probleme und deren Lösungen gemeinsam zu erarbeiten.
Nachhaltigkeit in der Problemlösung
Wenn das Team ein Problem selbst lösen kann, sollte gemeinsam die Ownership geklärt werden. Zum Beispiel: „Wer macht was bis wann, um das Problem zu lösen?“ Falls das Team ein Problem nicht selbst lösen kann, sollte der Scrum Master es (insofern möglich) selbst lösen und transparent machen, wie es gelöst wurde. Dies fördert das Lernen und die Kompetenzentwicklung im Team.
Fazit
Die Rolle des Scrum Masters ist es, das Team zu unterstützen und die Selbstorganisation zu fördern. Ein Eingreifen ist notwendig, wenn ein Problem die Leistungsfähigkeit des Teams erheblich beeinträchtigt. Durch proaktives Erkennen und Thematisieren von Problemen kann das Team effizienter und effektiver arbeiten – und letztendlich erfolgreicher sein. Denn ein Team, das Probleme frühzeitig erkennt und löst, bevor sie eskalieren, arbeitet nicht nur produktiver, sondern auch zufriedener.
Philipp Tintschl
Verwandte Artikel
Warum dein Unternehmen über cross-funktionale Teams nachdenken sollte
Cross-funktionale Teams können dein Unternehmen transformieren! Erfahre, wie sie die Zusammenarbeit verbessern und deine Innovationskraft steigern.
Chaos durch mehrere Product Owner: Unsere Lösung
Was passiert, wenn es mehre Product Owner gibt? Chaos! Erfahrt, wie unser Scrum Master die Situation rettete.
Confluence Whiteboards: Vorteile und Integration im Vergleich zu Miro
Confluence Whiteboards integrieren sich nahtlos in Atlassian-Produkte. Wir vergleichen sie mit Miro und beleuchten die Vorteile und Einsatzmöglichkeiten beider Tools.