Wie starte ich ganz konkret mit einem neuen Scrum Team?

Manche Agilisten fühlen sich überfordert, schnell ein Scrum-Team aufzusetzen. Sie haben ein Seminar nach dem anderen besucht und kennen so viele Techniken und Methoden, dass sie am Ende gar nichts davon anwenden. Das war nicht der Sinn des Scrum Guides. Hier ist mein Vorschlag für einen Teamstart.

Es ist ja toll, wenn sich Leute, die neu in der agilen Szene sind, mit vielen Techniken beschäftigen. In den diversen Ausbildungen wird man allerdings mit einer Unmenge an Ideen bombardiert. Das darf nicht dazu führen, dass man sich nicht mehr an die Arbeit traut. Wir brauchen jeden, der mit anpackt. Es gibt noch so viele Unternehmen und Institutionen, in denen Scrum für Entlastung und Weiterentwicklung sorgen würde. Macht es also nicht so kompliziert. Haltet Euch an den Scrum Guide.

Hier die Schritte in der Übersicht:

• Vorbereitung: Fragen aus dem Scrum Guide klären
• Product Owner Workshop: erstes Backlog aufbauen
• Erstes Product Backlog Refinement mit dem Scrum Team
• Das Team auf Scrum vorbereiten
• Den Scrum Master vorbereiten

Wie starte ich konkret mit einem Scrum Team (Quelle: Andrea Schwarz)

Erinnerung: Scrum Guide lesen und Fragen klären

Bevor wir loslegen, erinnern wir uns, was zu Beginn des Scrum Guides steht: "[Scrum] fordert ..., dass ein:e Scrum Master:in ein Umfeld fördert, in dem

1. ein:e Product Owner:in die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert;
2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt;
3. das Scrum Team und dessen Stakeholder:innen die Ergebnisse überprüfen und für den nächsten Sprint anpassen;
4. diese Schritte wiederholt werden."/1/

In diesem Absatz erkennen wir schon, welche Fragen wir klären müssen, bevor wir den ersten Sprint starten:

• Wer ist die Product Ownerin? 
• Was ist das komplexe Problem genau? Was steht im Product Backlog?
• Wer ist im Scrum Team? Haben wir alle Fähigkeiten im Scrum-Team, um einen Zwischenstand zu erzeugen?
  
• Was ist dieser vorzeigbare Zwischenstand genau? Was für Feedback bekommen wir damit?
  
• Welche Stakeholder brauchen wir, um gutes Feedback zu bekommen?
• In welchem Takt wollen wir arbeiten?

Diese Fragen sind als erstes zu klären. Da braucht man auch keine speziellen Techniken. Redet miteinander. 

Vor dem ersten Sprint brauchen wir ein Backlog.

Erstes Refinement vorbereiten und durchführen

Das Product Backlog ist die einzige Quelle, aus der sich das Scrum-Team die Arbeit holt. Oft sehe ich sehr technische Beschreibungen des Projekts. Das hilft uns aus verschiedenen Gründen nicht. 

Für Software und Dienstleistungen ist es sehr viel einfacher, mit den Geschäftsprozessen aus Benutzersicht zu starten. Bei Maschinen zerlege ich das Produkt in Funktionen und Unterfunktionen.

Meist mache ich dies in einem Workshop (1/2-1 Tag) mit der Product Ownerin und weiteren Personen (wichtige Stakeholder, erfahrene Entwicklerinnen).

Fragt nach: 

• Wenn die Software/der Service/die Maschine fertig ist: Was machen die Benutzer damit?
• Sind da noch andere Benutzer, vielleicht indirekte?
• Gibt es Schnittstellen zu anderen Softwareprodukten/Dienstleistungen oder Maschinen?
• Was passiert vor oder nach der Benutzung?
  

Jeder Prozess oder jede Funktion kommt auf eine Karte, damit wir damit weiterarbeiten können. 

Wenn wir auf diese Einträge blicken, frage ich weiter: 

• Was ist das eigentliche Ziel hinter dem Produkt, das wir erreichen wollen?
• Welche Benutzergruppen profitieren am meisten von dem neuen Produkt? Was bedeutet für sie Wert?

Hier finde ich die Technik Story Mapping von Jeff Patton als sehr hilfreich./2/ Story Mapping schlägt die Brücke vom Produktziel zum ersten Product Backlog. Aber auch jede andere Art und Weise, mit der sich eine Gruppe ein Gesamtbild erzeugt, ist nützlich. Ich bitte gern Anwesende, Skizzen zu erstellen. Das erleichtert die Kommunikation unter den Beteiligten.

Nun kommt das restliche Scrum-Team dazu und wir verfeinern das Product Backlog:

• Was ist eine gute Reihenfolge, um schnell etwas zu zeigen?
• Welche Einträge haben einen hohen Wert für unsere Feedbackgeber?
• Wie schätzen die Umsetzer den relativen Aufwand der Prodcut Backlog Einträge untereinander ein (Magic Estimation)?

Diese Informationen werden auf jeder Karte notiert. Bevor wir den ersten Sprint starten, brauchen wir eine Definition of Done:

• Unabhängig von dem einzelnen Prozess oder der Funktion, die im Backlog steht: Welche Arbeitsschritte müssen erledigt sein, damit wir nicht nacharbeiten müssen?
• Im Hinblick auf die Definition of Done und die ersten Einträge im Backlog: Gibt es etwas, um das wir uns jetzt kümmern müssen, bevor der erste Sprint beginnt? Haben wir alles um loszulegen? Wenn nicht, wer kümmert sich darum?
  

Das Team auf Scrum vorbereiten

Kennt sich das Team mit den Scrum-Begriffen und Ideen dahinter aus? Nein? Dann würde es helfen, wenn sich das Team mit Scrum auseinandersetzt. Ein Tag ist besser als ein halber Tag, ein halber Tag ist besser als 2 Stunden usw.

Folgende Punkte sind mir wichtig:

• Wir müssen die Scrum-Begriffe (3-5-3) und ihre Bedeutung erklären. Es geht z. B. nicht darum, ob jemand den Titel PO hat, sondern welche Verantwortung damit verbunden ist.
• Scrum ist kein neuer Prozess, der den alten Projektprozess ersetzt. Scrum ist ein übergeordneter Prozess, mit dem der eigentliche Entwicklungsprozess erstellt wird. Ziel ist nicht Scrum, Ziel ist die gute Entwicklung des neuen Produkts.
• Jedes Element in Scrum hat eine Geschichte und eine Bedeutung. Deswegen steht es im Scrum Guide. Wir machen ein Daily Scrum nicht, weil es der Scrum Guide "vorschreibt". Wir machen ein Daily Scrum, weil wir wissen, dass es die Produktivität des Scrum Teams verdoppelt.
• Mit Blick auf die Scrum-Werte sollte das Team seine eigenen Werte und Umgangsregeln klären.

Nun können wir anfangen zu sprinten.

Den ersten Sprint planen

Es gibt eine Product Ownerin. Wir kennen das Produktziel. Wir haben geordnetes und geschätztes Product Backlog. Es gibt eine Definition of Done und wir wissen grundsätzlich, was wir mit einem Inkrement zeigen wollen.

Nun können wir den ersten Sprint wie im Scrum Guide beschrieben planen:

1. Warum machen wir den ersten Sprint?
2. Welche Backlogeinträge nutzen wir, um das Sprintziel zu erreichen?
3. Welche Aufgaben müssen wir erledigen, um einen Backloeintrag abzuschließen?

Ich bin ein großer Fan von kurzen Sprints (1 Woche). Jedes meiner Teams konnte mir nach der ersten Woche schon etwas zeigen. Nach dem ersten Sprint waren die Fragen im Team zur Umsetzung deutlich spezifischer, weil man ja schon etwas gemacht hatte. Keine Angst vor kurzen Sprints.

Den Scrum Master vorbereiten

Die Rolle Scrum Master ist am Anfang für ein neues Scrum Team und die Stakeholder in der Organisation sehr unklar. Der Scrum Master ist nicht der Zeremonienmeister. Das wäre viel zu teuer.

Jeff Sutherland hat im August 2021 dazu einen interessanten Kommentar bei LinkedIn hinterlassen: "Der Job des Scrum Masters wurde als Halbtagsjob konzipiert. Die meisten der großartigen Scrum Master, mit denen ich gearbeitet habe, waren im Team und haben am Sprint Backlog mitgearbeitet. Seit kurzem müssen Scrum Master bei Scrum Inc, wo wir keine Manager haben, operative Verantwortung übernehmen (Dinge, die Manager oft tun), so dass wir sie zu einer Vollzeitstelle machen." /3/

Es wäre also OK, wenn Scrum Master auch Entwicklungsaufgaben hätten.

Neue Scrum Master müssen sich bei mir mit folgenden Dokumenten vertraut machen:

• Den Artikel "The New New Product Developmen Game" von Nonaka und Takeuchi
• Die Scrum Patterns im Scrum Book.

Der Artikel von Nonaka und Takeuchi war nicht nur Namensgeber für Scrum ("Moving the Scrum downfield"). Er beschreibt, wie man gute Entwicklungsteams aufbaut. Ein neuer Scrum Master sollte durch die Brille dieses Artikels auf sein Team schauen:

• Wie gut können PO und Management begeisternde Ziele für das Team formulieren?
• Wie selbständig und autonom kann das Scrum Team handeln?
• Wie schnell kann das Scrum Team etwas Vorzeigbares herstellen? Wie gut kann es das Feedback wieder einarbeiten?
• Wie lernen die einzelen Mitglieder im Scrum Team? Wie bringen sie sich gegenseitig das nötige Wissen bei?
• Welche subtilen Kontrollmechanismen können wir nutzen, damit das Schiff nicht kentert? (Zum Wackeln bringen ist ok.)
• Wie kommt das neue Wissen in die restliche Organisation? Wie kann sie das Scrum-Team unterstützen?

Das Scrum-Patterns-Buch enthält ganz viele Arbeitsmuster. Dort gibt es Erklärungen, Hintergründe und Literatur zu einzelnen Muster. Ein Scrum Master kann einfach mit irgendeinem Muster starten und prüfen, wie gut es im Team schon umgesetzt wurde bzw. was die nächsten Schritte dazu sind.

Ihr wollt mehr über Scrum wissen? Wir haben eine Übersichtsseite zu Scrum, über die man sich in die wichtigsten Artikel in diesem Blog einlesen kann.

Anmerkungen

• /1/ Siehe Scrum Guide, Version vom November 2020, dt. Version S. 3, https://scrumguides.org/ 
• /2/ Von Jeff Paton gibt es eine Kurzanleitung zum Story Mapping auf seiner Webseite: https://www.jpattonassociates.com/story-mapping-quick-ref/ 
• /3/ Sutherland, LinkedIn Kommentar vom 18.08.2021. https://www.linkedin.com/feed/update/urn:li:ugcPost:6828020451994832896?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A6828020451994832896%2C6828771854312898560%29
• /4/ Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard business review, 64(1), 137-146. https://hbr.org/1986/01/the-new-new-product-development-game
  
• /5/ Sutherland, J., & Coplien, J. O. (2019). A Scrum book: The spirit of the game. Pragmatic Bookshelf. http://scrumbook.org/