Weil man Scrum sicherlich am besten versteht, wenn man es in täglichen in Fleisch und Blut übergegangenen Tätigkeiten ausführt und gerade dort die Vorteile von Scrum zu schätzen lernt, haben einige Scrum Bekenner, wie Boris Gloger, sich wohl das Scrum Cooking ausgedacht. Jedenfalls werden die Scrum Master Trainings mit Teamkochen u.a. auch von der Wibas GmbH angeboten.
Ich finde diese Idee sehr gut. Es ist nicht immer leicht einen Praxisbezug für Trainings, gerade im Bereich der Projektarbeit, herzustellen. Oft sind die Trainings schon an einer Branche orientiert, was gelegentlich den Blick über den Tellerrand erschwert. Das ist gerade bei Scrum in großem Maße die Softwareentwicklung.
Wenn es also kein Budget für Weiterbildungen mehr gibt oder man sich unsicher mit Scrum in einem konkreten Projekt ist oder man es einfach nur einmal ausprobieren möchte, bleibt die Möglichkeit eines Selbstversuchs. Ich kenne diese Koch-Trainings nicht im Detail und weiss nicht wo die Scrum-Techniken in den Cookings tatsächlich beginnen, möchte das ganze aber einmal als Anregung zum Selbstlernen für Teams weiterspinnen.
Eine Gruppe aus Kollegen, die Scrum in der Theorie kennt, könnte sich einen Tag reservieren und mit ein wenig Geldeinsatz selbst ein Essen für sich und andere veranstalten und dabei noch etwas lernen. Ganz zu schweigen von der abschließenden Selbstbelohnung mit einem leckeren Essen.
Als erstes benötigt man ein Grundverständnis von Scrum. Man sollte sich mit den Rollen, Prozessen und Artefakten auskennen. Dazu gibt es hervorragende Lektüre, wie die hier genannten Bücher:
Bücher bei amazon.de:
Danach folgt die Umsetzung der Inhalte beim Kochen.
Das Teamkochen
Sind die Basics von Scrum in den Köpfen des Scrum-Teams, sollte für das Teamkochen ein Tag eingeplant werden. Das ganze sollte im Vorfeld nicht zu sehr durchorganisiert werden, da es der Realität entsprechen soll und Scrum nur so voll zur Entfaltung kommt. Im Vorfeld sollte lediglich geklärt werden, wieviel jeder auszugeben bereit ist, wo man einkaufen kann, wo gekocht wird und wo gegessen wird, damit die Rahmenbedingungen stimmen.
Die Rollen
- Theoretisch benötigen wir einen Kunden. Also jemanden der das Essen finanziert und eine klare Vorstellung davon hat, was die Konsumenten unseres Essens erwarten soll. Das könnte das Scrum-Team selbst sein. Das entspricht zwar nicht ganz den Rollen in Scrum, aber für die Durchführung eines solchen Cookings benötigt man ein paar Euro und wenn sonst niemand einlädt, bleibt die Möglichkeit, es eben selbst zu finanzieren.
- Wir benötigen Benutzervertreter, also einige Konsumenten des Essens, die das Endergebnis beurteilen, vielleicht Freunde, die wir bekochen wollen. Eventuell stellt sich aus den Reihen der Freunde ein Kunde zur Verfügung. Er sollte dem Product Owner in jedem Fall als Ansprechpartner zur Verfügung stehen und bei den Anforderungen, also der Erwartung an das Essen, unterstützen.
- Der Product Owner. Idealerweise jemand, der später auch beruflich diese Rolle wahrnehmen soll, wird für den Prozess des Kochens permanent zur Verfügung stehen und im Dialog mit Kunden und Team bleiben.
- Der Scrum Master kümmert sich um die die Hindernisse und die Teammeetings und sollte ein akzeptiertes und geachtetes Individuum sein. Er sorgt dafür, dass der Scrum Prozess funktioniert. Auch hier sollte es eine Person sein, die später im Job für diese Rolle prädestiniert ist.
- Das Team besteht, gemäß der Millerschen Zahl, aus 7 ± 2 Mitgliedern. Das Team sind diejenigen, die das Essen von A-Z umsetzen. Für ein gemeinsames Kochen reichen eventuell 5 Personen, denn man will sich je nach Küche nicht zu sehr im Weg stehen. Außerdem kommen noch der Auftraggeber, Product Owner, Scrum Master und Benutzerverterter hinzu, die schließlich mitessen sollen. Ein Essen für 10 Personen ist gerade noch überschaubar und sollte für den Zweck des Selbstversuchs unbedingt reichen.
Die Produktvision und das Produktkonzept
Üblicherweise entwickelt der Product Owner zusammen mit dem Kunden eine Produktvision und ein Produktkonzept. Da wäre also das Menü als Vision und das Konzept das grob darstellt aus welchen Elementen es bestehen soll. Man legt die Gänge fest, wie eingedeckt werden soll, welche Getränke ausgeschenkt werden, etc. Gemäß dem Kano Modell können hier schon Begeisterungsmerkmale des Menüs untergebracht und Leistungsmerkmale von Basismerkmalen abgegrenzt werden. Auch Budget und Zeitpunkt des Essens werden festgezurrt. Auf Basis des Zeitrahmens lässt sich die Sprint Planung machen und man könnte ein Risikobudget zurücklegen, falls Equipment fehlt oder Lebensmittel nachgekauft werden müssen.
Der Anforderungsworkshop
Im Anforderungsworkshop wird konkret besprochen, was genau und in welcher es am Ende auf dem Tisch stehen soll. Ein guter Zeitpunkt auch die Definition of Done zu besprechen. Sie sagt aus, in welcher Form Dinge geliefert werden und was fertig wirklich heisst. So könnte man sich darauf einigen, dass am Ende eines Sprints der Arbeitsplatz für den nächsten Sprint benutzbar sein muss oder Werkzeuge gereinigt zur Verfügung stehen. Das Product Backlog wird mit erforderlichen Tätigkeiten gefüllt und vom Product Owner priorisiert. Risiken werden abgeschätzt und bei der Priorisierung berücksichtigt.
Für das zubereiten eines Menüs sind neben den Rohmaterialien auch einige Arbeitsgänge nötig. Z.B. Einkaufen, Lebensmittel waschen und schälen, Tisch decken, Abspülen, etc. Ins Backlog lassen sich die benötigten Schritte als User Stories gemäß des: wer? (Rolle), was? (Ziel), wofür? (Nutzen) eintragen.
Dafür muss man dann auch vorbereitende Arbeitsgänge definieren:
Als Koch möchte ich das Gemüse geschält und geschnitten erhalten, um mit die Gemüsebeilage kochen zu können.
Oder das Endprodukt betreffende Zustände:
Als Gast möchte ich einen gemütlichen Platz haben, an dem ich mich beim Essen wohlfühle.
Der Kunde, Benutzervertreter, Product Owner, Scrum Master und Team stellen die Anforderungen zusammen und das Team schätzt grob die Aufwände. Man einigt sich auf die Sprint Länge und wieviele der Inkremente man benötigt. Ab jetzt pflegt und detailliert der Product Owner regelmäßig das Product Backlog.
Das erste Sprint Planning
Das Scrum Team (Team, Product Owner, Scrum Master) bereitet das Sprint Planning vor. Der Product Owner definiert das Ziel des beginnenden Sprints. Idealerweise sollte der Fokus auf der Fertigstellung von Teilabschnitten liegen. Scrum will nach jedem Sprint ein releasefähiges Produkt. Das passt gut zum Kochen, denn man benötigt fertige Abschnitte, um weitermachen zu können.
Beim Kochen könnten je Sprint folgende Sprintziele vorgeschlagen werden:
- Sprintziel: Alle Zutaten sind eingekauft.
- Sprintziel: Alle Zutaten sind zum Kochen vorbereitet.
- Sprintziel: …
Wie gesagt, diese Ziele sind Vorschläge und können sich im Rahmen des Kochens völlig anders entpuppen. Hier liegt eine Eigenschaft und klarer Vorteil von Scrum.
Im Planning befüllen Team und Scrum Master mit Blick auf das Sprint Ziel das Sprint Backlog und schätzen die Aufwände. Dabei werden Items aus dem Product Backlog ggf. detailliert und als Tasks ins Sprint Backlog übertragen. Dabei sollte das Team darauf achten, dass es sich für die Arbeitsgänge nicht zu viel zumutet und sich mit seiner Teamgeschwindigkeit einpendelt.
Die Detaillierung erfolgt wiederum als User Stories, die mit entsprechenden Akzeptanzkriterien versehen werden:
Als Koch möchte ich die Karotten gewaschen, geschält und geschnitten erhalten, um die Karottenbeilage kochen zu können.
Akzeptanzkriterium: Ca. 3 mm dicke Scheiben.
Das Daily Scrum
Sagen wir, dass der Tag, der uns zur Verfügung steht, etwa 11 Stunden – 9 bis 20 Uhr – inklusive Pausen hat. Ca. 45 Minuten hat der Product Owner für die Produktvision und danach 45 Minuten Anforderungsworkshop für alle. Danach beginnen die Sprints mit je 2 Stunden. Im 2 Stunden Sprint kann man 15 Minuten für das Sprint Planning, 15 Minuten für Review und 10 Minuten für Retrospektive unterbringen. Das Daily Scrum würde hier zu einem Hourly Scrum verkommen, was anbetracht der vorhandenen Zeitfenster absurd wäre. Während des Sprints sollte das Daily Scrum durch gute Kommunikation mit dem Scrum Master und dem Product Owner aufgefangen werden. Im echten Leben, ist das Daily Scrum meines Erachtens das wichtigste Meeting. Also bitte nicht aus dem Teamkochen rausgehen und im Job dieses Meeting vergessen!
Das Sprint Backlog
Idealerweise benutzt man in Scrum Karteikarten, um seine Tasks in Form von User Stories zu formulieren. Das ist gerade beim Kochen interessant und hilfreich. Die Karten aus dem Sprint Backlog können nämlich perfekt an ein Task Board übertragen werden, von dem sich das Team gewissermaßen seine Aufgaben pflückt. Erst wenn ein Task der Definition of Done entspricht, wird sie als erledigt ans Task Board zurückgehängt.
Das Sprint Burndown Chart
Der Scrum Master trägt die erledigten Tasks in ein Burndown Chart ein und illustriert so die Geschwindigkeit des Teams. Je nach Schwierigkeitsgrad der Tasks werden die erledigten Punkte heruntergezählt.
Das Sprint Review Meeting
Im Sprint Review präsentiert das Team dem Product Owner und ggf. anderen Stakeholdern seine Ergebnisse, wobei der Scrum Master die Moderatorenrolle übernimmt. Der Product Owner nimmt die Ergebnisse ab, teilt mit ob das Ziel erreicht ist und entlastet das Team. Nicht fertiggestellte oder unzureichend erstellte Tasks wandern zurück ins Product Backlog.
Das Sprint Retrospective Meeting
Im Sprint Retrospective bespricht sich das Scrum Team, was gut und schlecht lief und versucht den Prozess für die nächsten Sprints zu verbessern. Das ist bestimmt interessant, wenn sich beim Kochen völlig ungeahnte Qualitäten und Defizite der Gruppe herausstellen.
Das Impediment Backlog
Die Sprint Retrospective ist auch ein guter Zeitpunkt einen Blick auf das Impediment Backlog zu werfen. Der Scrum Master kann sich hier unter Beweis stellen. Er wird während der Sprints – eigentlich im Daily Scrum – mit den Behinderungen der Teammitglieder konfrontiert und hat für Beseitigung der Behinderungen zu sorgen. Sollte ein Kochfeld, ein Schäler, Geschirr fehlen oder etwas behindern, was dem Team die Arbeit erschwert, hat er für Entspannung zu sorgen. Er könnte z.B. auf das Risikobudget zurückgreifen, Kontakte oder seinen eigenen Haushalt nutzen, um die notwendigen Mittel zu organisieren.
Nach dem Sprint ist vor dem Sprint
Der erste Sprint ist jetzt beendet. Alle sollten sich eine Pause gönnen und sich entspannen. Im weiteren Prozess wird dann wieder mit einem Sprint Planning begonnen, zu dem sich alle einfinden.
Die weiteren Sprints
In jedem weiteren Sprint Planning werden die Tätigkeiten für den aktuellen Sprint geplant. Dabei greift das Team auf seine Erfahrungen aus der vergangenen Sprint Retrospective zurück. Man bekommt hier allmählich ein Gefühl für die eigene Geschwindigkeit und lernt die Tätigkeiten besser einzuschätzen. Meine persönliche Erfahrung ist, dass ich für die alltäglich Dinge tatsächlich kein gutes Zeitgefühl habe, obwohl ich sie regelmäßig erledige. Gerade was das Kochen angeht. Ich verschätze mich generell beim Waschen, Schälen Schneiden von Gemüse. Sehr zum Leidwesen meiner Familie.
Der Prozess läuft nun wie im ersten Sprint weiter, bis der letzte Sprint beendet ist. Auf dem Weg dorthin, wird noch einiges passieren, was den Product Owner und das Team dazu zwingt, Dinge umzudisponieren. Wenn die Zeit bis zum Servieren knapp wird, muss man vielleicht den Umfang reduzieren. Wenn ungeplante, nicht im Kalkül befindliche Zwischenfälle auftreten und den Scrum Master herausfordern, kann er sein Talent zeigen.
Das Release Burndown Chart
Im Release Burndown Chart trägt der Product Owner die über die Sprints „heruntergekochten“ Anforderungen ein. Hier sieht er, wie sich das Team unserem fertigen Menü nähert.
Guten Appetit
Vielleicht habe ich mit diesem Beitrag ja beim einen oder anderen einen Funken entzündet, solch ein Kochen einmal selbst auszuprobieren. Ich wäre natürlich brennend daran interessiert, wie das Cooking schlussendlich verlaufen ist. Am besten mit einem Abschlussbericht in Form eines Gastbeitrags in diesem Blog. Ich selbst werde wohl demnächst auf die Suche gehen, um geeignete Teammitglieder zu finden und den Selbstversuch gewissermaßen als Proof of Concept durchführen, denn ein gutes Essen lasse ich nur ungern aus 😉
Viel Spaß und guten Appetit!
Weitere Bücher zum Thema Scrum bei amazon.de:
Antworten