Direkt zum Hauptbereich

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:

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

Kommentare

  1. Lieber Ja, ich kann dir gar nicht genug für diese Anleitung danken ❤️ Liebe Grüße, Andrea

    AntwortenLöschen
  2. Herrlich Dein Satz "Wir brauchen jeden, der mit anpackt." :-) Gute solide Anleitung für alle, denen der Kopf vor lauter "Methodenkoffer" schwirrt - demnach top!

    AntwortenLöschen
  3. Vielen Dank für diese gute und pragmatische Anleitung. Es ist eine gute Strategie, sich nicht von der eigenen Menge an Wissen blockieren zu lassen, sondern einfach und elementar zu starten. Iterativ, empirisch und adaptiv, eben agil, geht es dann Schritt für Schritt weiter.

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Selbstbewertungsfragen für den Alltag in Arbeitsgruppen aus Sicht von Mitarbeitenden

Welche Fragen können wir Mitarbeiter:innen stellen, um herauszufinden, ob agiles Arbeiten wirkt? Es gibt bereits eine Menge an Fragebögen. Aber ich bin nicht immer zufrieden damit.

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Microsoft Lists: mit Forms und Power Apps komfortabel mobil arbeiten

In meinem Kundenkreis sind viele Menschen, die den Arbeitsalltag nicht vorwiegend auf dem Bürostuhl sitzend verbringen, sondern "draußen" unterwegs sind. Vielleicht in Werkstätten oder im Facility-Management. Es ist so wichtig, dass die Schnittstellen zu den Abläufen im Büro gut abgestimmt sind. Microsoft 365 hat so einiges im Baukasten, man muss es nur finden und nutzen.  In diesem Artikel spiele ich ein Szenario durch, das auf Microsoft Lists, Forms und - für die Ambitionierteren - Power Apps setzt.

Wie Agilität den Kundennutzen steigert - Einige Argumente für Berater:innen

In Zeiten wirtschaftlicher Unsicherheit fragen sich viele, ob agile Beratung noch eine Zukunft hat. Die Antwort liegt in der konsequenten Orientierung am Kundennutzen. Qualität setzt sich durch, wenn sie messbare Verbesserungen bei Umsatz, Kosten und Leistungsfähigkeit bewirkt, anstatt sich in Methoden und zirkulären Fragen zu verlieren. Dieser Artikel zeigt, wie agile Beratung nachhaltige Veränderungen in Unternehmen schafft und warum gerade jetzt gute Berater:innen gebraucht werden, um Organisationen widerstandsfähiger zu machen.

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.

Warum eine Agile Transformation keine Reise ist

Die agile Transformation wird oft als eine Reise beschrieben. Doch dieser Vergleich kann viele Unternehmen in die Irre führen oder Bilder von unpassenden Vergleichen erzeugen. Transformationen sind keine linearen Prozesse mit einem klaren Ziel, sondern komplexe und dynamische Entwicklungen. Dieser Artikel zeigt, warum Agilität kein Weg mit einem festen Endpunkt ist.

Warum bringen Warum-Fragen so wenig?

Frust! Wieder gibt's am Ende des Meetings keine Lösungen, sondern nur Diskussionen darüber, wer was warum verbockt hat. Wieder geht nichts voran. Warum passiert uns das immer wieder? (Ha! Da ist sie wieder, die Warum-Frage.)