Was verspricht Scrum?
Spätestens nach 30 Tagen steht den Kunden eine neue und nutzbare Version des Produkts zur Verfügung.
Das ist der Kern von Scrum.
Unternehmen, die Scrum einführen, versprechen sich genau das davon. Und die vorrangige Aufgabe eines Scrum Masters ist es, dieses Versprechen für das Unternehmen einzulösen. Darin besteht sein Wert.
Unerfahrene Scrum Master stehen damit nicht selten vor einer Herausforderung.
Erst letzte Woche hat mich ein Scrum Master um Hilfe gebeten. Er schrieb mir, dass sein Team nicht in der Lage sei, die User-Stories in zwei Wochen abzuschließen. Da ich überzeugt bin, dass er nicht der Einzige mit diesem Problem ist, formuliere ich meine Antwort für alle.
Da jede Situation anders ist, kann ich natürlich kein Kochrezept mit der perfekten Lösung geben. Jedoch würde ich mir diese Fragen stellen:
Frage 1: Wie lassen sich die User-Stories kleiner schneiden?
Meine erste Reaktion:
Wahrscheinlich sind die User-Stories zu groß für einen Sprint.
Um User-Stories kleiner zu schneiden, haben mir bisher diese Fragen am meisten geholfen:
- Wenn wir diese User-Story an nur einem Tag umsetzen müssten, worauf würden wir uns konzentrieren? Was könnte später erledigt werden?
- Was ist die kleinstmögliche und einfachste Möglichkeit, diese User-Story zu implementieren?
- Welche Schritte durchlaufen die Benutzer, wenn sie die in dieser User-Story beschriebenen Funktionen nutzen? Welchen dieser Schritte können wir jetzt implementieren?
- Welche der Geschäftsregeln, die für diese User-Story wichtig sind, haben den geringsten Einfluss? Auf welche können wir vorerst verzichten?
- Wie sehen die „Happy“- und „Unhappy“-Pfade für diese User-Story aus? Auf welche Pfade können wir verzichten?
- Auf welche der Akzeptanzkriterien für diese User-Story können wir verzichten, wenn wir sie später implementieren?
- Welche CRUD-Interaktionen (Create, Read, Update, Delete) haben die Nutzer mit dieser User-Story? Welche können wir später implementieren, ohne dass dies jetzt große Auswirkungen hat?
Eigentlich sollten diese Fragen deinem Team im Product-Backlog-Refinement oder Sprint-Planning helfen. Das Ziel ist, die User-Stories so aufzuteilen, dass sie in einem Sprint erledigt werden können.
Ist die Größe nicht das Problem, dann solltest du dich fragen:
Frage 2: Welche nicht offensichtlichen Gründe gibt es?
Was meine ich mit dieser Frage?
Wenn User-Stories nicht in einem Sprint abgeschlossen werden können, dann ist das offensichtliche Vorgehen, sie kleiner zu schneiden.
Funktioniert dies aber nicht, dann sollten wir nach dem Nicht-Offensichtlichen Ausschau halten.
Softwareentwicklung ist ein sozio-technisches Problem. Das heißt, die Lösung besteht aus mehreren Bereichen, die miteinander in Beziehung stehen.
Die Bereiche lauten:
- Arbeitsstruktur: Wie ist die Arbeit beschrieben? Werden technische Arbeiten beschrieben oder nutzbare Funktionalitäten?
- Teamstruktur: Wie ist die Struktur des Teams? Hat es alle Fähigkeiten, eine nutzbare Version des Produkts eigenständig zu erstellen? Kann das Team alle Änderungen an der Codebasis selbst vornehmen oder ist es auf die Hilfe anderer Teams angewiesen?
- Produktstruktur: Besteht das Produkt aus kleinen, in sich geschlossenen Komponenten? Können diese Komponenten unabhängig voneinander geändert werden?
Greifen diese Bereiche nicht passend ineinander, führt dies zu Problemen.
Ein Beispiel: Wenn das Team nicht in der Lage ist, User-Stories so klein zu schneiden, dass sie in einem Sprint abgeschlossen werden können, kann dies an einer unpassenden Teamstruktur liegen. Dem Team könnte es an Fähigkeiten und Expertise fehlen. Werden etwa die UI-Designs von einem separaten Team erstellt, kann dies dazu führen, dass die Funktionalität sehr groß ist, die in der User-Story beschrieben wird. Da das Team aber keinen Einfluss auf das Design hat, kann es die User-Stories nicht kleiner schneiden.
Eine weitere nicht offensichtliche Ursache könnte auch Folgende sein:
Frage 3: Fehlt es den Entwicklern an Fantasie?
Diese Frage klingt etwas herablassend.
Keine Angst, lass mich dir erklären, worauf ich hinauswill. Angenommen, ich hätte noch nie funktionierendes Scrum gesehen. Vielleicht kenne ich aus meinem Unternehmen nur Projekte mit Laufzeiten von einem Jahr. Zu Beginn des Projekts werden erst einmal alle Anforderungen erhoben, dann wird ein Konzept entwickelt, bevor es zur Umsetzung kommt. Nachdem der Kunde die Software abgenommen hat, kommt es am Ende des Jahres zur Auslieferung. Dann kann ich mir vielleicht einfach nicht vorstellen, dass es möglich ist, Software innerhalb von 30 Tagen oder weniger auszuliefern. Vielleicht fehlt es mir ganz einfach an Vorstellungskraft und Fantasie. Sollte dies auf dein Team zutreffen, dann kannst du hierbei als Scrum Master Abhilfe schaffen. Organisiere eine Team-Safari.
Hier die Schritte dafür:
- Finde ein Team, welches Software in 30 Tagen oder weniger liefern kann.
- Besuche mit deinen Entwicklern dieses Team. (Alternativ kannst du auch einen Experten dieses Teams für einen Vortrag zu euch einladen.)
- Führe nach der Safari eine Sprint-Retrospektive mit deinem Team durch, um Erkenntnisse und Einsichten zu sammeln.
Aus meiner Erfahrung fällt es Teams leichter, konkrete Veränderungen zu identifizieren, nachdem sie gesehen haben, dass es möglich ist, Software in 30 Tagen oder weniger zu liefern.
Manchmal kann es aber auch der folgende Grund sein:
Frage 4: Haben die Entwickler bereits resigniert?
Diese Situation erkennst du an den Aussagen:
„Haben wir bereits probiert, das funktioniert hier nicht.“
Ich weiß nicht, wie häufig ich diese Antwort bereits auf meine Vorschläge gehört habe. Und was ich über die Jahre gelernt habe:
Argumentieren ist jetzt Zeitverschwendung.
Jemand, der in seinen Augen schon alles Erdenkliche versucht hat, ist schwer zu überzeugen. Ihm zu erklären, dass es dennoch funktioniert, klappt nur in den seltensten Fällen.
Was ist in einer solchen verfahrenen Situation stattdessen zu versuchen? Es hilft, die Person zum Nachdenken anzuregen. Und zwar zum Nachdenken über ihr eigenes Denken. Manchmal führt dies zu einem Sinneswandel.
Hier mein konkretes Vorgehen:
- Ich formuliere die Aussage, was nicht geht, indem ich sie mit meinen eigenen Worten wiederhole. Und dann frage ich mein Gegenüber, ob ich die Aussage gut zusammengefasst habe. Dies mache ich so lange, bis ich die Aussage richtig wiedergeben kann. Etwa: „Sich nur auf den ‚Happy‘-Pfad zu konzentrieren und den ‚Unhappy‘-Pfad zu ignorieren, führt nicht dazu, dass wir die User-Story in weniger als zwei Wochen umsetzen können.“
- Dann frage ich nach einer Zahl auf einer Skala von 1 bis 10 für das Vertrauen in diese Aussage. Außerdem möchte ich wissen, welche Gründe die Person für diese Zahl hat. „Du bewertest dein Vertrauen mit einer 8, weil Erfahrungen aus den letzten Sprints gezeigt haben, dass der ‚Unhappy‘-Pfad oft unerwartete Probleme aufwirft.“
- Nachdem ich die Zahl kenne, stelle ich noch eine weitere Frage: „Warum nicht niedriger?“ „Du sagst, eine niedrigere Zahl wäre nicht gerechtfertigt, weil der letzte Sprint gezeigt hat, dass es nicht funktioniert. Dort wurde Tom krank und niemand hat die Frontend-Funktion weiterentwickelt. Woraufhin am Ende des Sprints nichts fertig war, obwohl du die Funktion im Backend abgeschlossen hattest.“
- Nachdem die Person ihre Gründe genannt hat, konzentriere ich mich im restlichen Gespräch nur auf diese Gründe. Ich höre zu, fasse zusammen und wiederhole. Ich unterstütze mein Gegenüber beim Denken, ohne mir eine Meinung zu erlauben.
Die Konzentration auf die Gründe führt manchmal dazu, dass mein Gegenüber seine Position aufgibt. Dadurch öffnet sich mein Gegenüber für neue Ideen. Es funktioniert nicht immer und meistens auch nicht sofort. Trotzdem war es bis jetzt immer erfolgreicher, als die andere Person mit logischen Argumenten überzeugen zu wollen.
Zum Abschluss ein Appell:
Die Arbeit als Scrum Master kann sehr frustrierend sein.
Häufig stehst du mit deiner Position allein da. Jeder im Team sagt dir, dass es nicht möglich sei, die User-Story in zwei Wochen abzuschließen, und du bist anderer Meinung. Hier standhaft zu bleiben, das zeichnet erfolgreiche Scrum Master aus.
Erfolgreiche Scrum Master wissen: Sie könnten dem Team zustimmen, lieber Sprints von 6 Wochen zu machen, damit die User-Stories im nächsten Sprint auch fertig werden. Allerdings würden sie dem Team dann etwas rauben.
Sie würden das Team der Chance berauben, etwas zu lernen.
Sprints mit anschließender Retrospektive ermöglichen es Teams, mehr über ihre Arbeitsweise zu lernen und sie zu verbessern.
Lernen sicherzustellen, ist die Aufgabe eines Scrum Masters.
Wenn du dabei Unterstützung suchst, dann besuche mein nächstes „Professional Scrum Master – Advanced“-Training. Dort lernst du nicht nur, wie ein erfolgreicher Scrum Master zu handeln. Du kannst auch Kontakt zu vielen anderen Scrum Mastern knüpfen, welche sich auf dem gleichen Weg wie du befinden.