Ehe – erklärt für Scrum Practitioners

Ehe

Einführung

Scrum, ein agiles Prozess-Framework, wird von Scrum Fanatikern gerne in allen Lebenssituationen appliziert. Daher liegt es nahe, dass Scrum auch auf die Ehe (besonders, beim Lebensbund zweier Scrum Practitioners) Anwendung findet.

Dieses Standardwerk zeigt wie Scrum auf eine Ehe appliziert werden kann.

Projektvision

Wie jedes Scrumprojekt, muss auch ein Projekt, welches mit Scrum für die Ehe abgewickelt wird, eine Vision haben, welche von allen Beteiligten geteilt wird: Liebe.

Rollen

Scrum Master

Da die Ehe oft als eher komplexes Projekt erlebt wird, wird bei Scrum für die Ehe der Rolle des Scrum Master eine sehr hohe Bedeutung zugewiesen. Deshalb wird diese Rolle auch doppelt belegt – durch die Trauzeugen. Diese Redundanz bietet Vorteile bezüglich Verfügbarkeit in Notsituationen und Kompetenz zu allen Lebensfragen.

Product Owner

Obwohl auf den ersten Blick die offensichtliche Lösung, dass beide Ehepartner die Product Owner Rolle einnehmen, einleuchtet, ergeben sich wegen unterschiedlicher Priorisierung von alltäglichen Dingen (z.B. Schuhe gegen Stereoanlage) oft Probleme. Daher ist die meist angewandte Version, die des Single Product Owner – sprich die Ehefrau übernimmt diese Rolle zu 100%.

Team

Das Team beim Scrum für die Ehe besteht somit noch aus dem Ehemann und ab Sprint zwei zusätzlich aus den Kindern. Das Team, das ausführende Element innerhalb des Scrum Prozesses, ist stets besorgt, dass die Ziele, welche durch den Product Owner vorgegeben werden, erreicht oder besser sogar übertroffen werden.

Weitere Stakeholder

Weitere Stakeholder sind alle Personen, welche Interesse am oder Einfluss auf das Projekt haben.

Typische Stakeholder in Reihenfolge des Einflusses sind:

  • Schwiegermütter
  • Tanten
  • Schwägerinnen
  • Freundinnen der Ehefrau
  • Restliche Bekannte und Verwandte

Prozesselemente

Sprints

Im Gegensatz zum herkömmlichen Scrum Prozess, sind die Sprints in Scrum für die Ehe nicht konstante time-boxed Perioden. Ein Sprint wird terminiert durch die Geburt von Nachwuchs.

Dies bedeutet, dass die Hochzeit den Startpunkt für den ersten Sprint definiert und die Geburt des ersten Kindes, dessen Ende. Der zweite Sprint läuft dann, bis zum zweiten Kind und so weiter.

Ein Sprint gliedert sich wie folgt:

  1. Sprintplanung
  2. Daily Rituals
  3. Release-Build
  4. Sprint Review

Sprintplanung

Folgt unmittelbar nach Beginn des Sprints.

Ausnahme, wenn ein Sprint 0 (Verlobung) abgehalten wird. Dann findet die Planung für den ersten Sprint oft schon in Sprint 0 statt.

Das Team sitzt mit dem Product Owner zusammen und der Product Owner (zur Erinnerung: dies ist die Ehefrau) erklärt, was das Sprintziel ist, und welche Wünsche sie umgesetzt haben möchte. Das Team schätzt, wie viele dieser Wünsche – genannt User Stories – umgesetzt werden können in der geschätzten Time-box des Sprints.

Bei fortgeschrittenen Sprints, kann hier auch auf die Velocity zurückgegriffen werden (siehe Velocity für Details).

Daily Rituals

Diese bilden die Grundlage für die tägliche Synchronisation des Teams mit dem Scrum Master.

Je nach Projekt ergeben sich sehr unterschiedliche Möglichkeiten:

  • Gutenmorgenkuss
  • Gutnachtkuss
  • Ehefraubetrittwohnungundehemannhat­nichtaufgeräumt.
  • Gemeinsames Zeitungslesen, Kaffeetrinken, Essen usw.
Release-Build

Wie in allen agilen Methoden, wird dem Releasebuild grosse Aufmerksamkeit geschenkt. Dieser ist zum grössten Teil automatisiert und dauert immer rund neun Monate, bis das Product Increment (auch bekannt als Familenzuwachs) das Licht der Welt erblickt.

Sprint Review

Sprint Reviews sind Meetings, an welchem allen Stakeholdern, das Product Increment vorgestellt wird.

Die Stakeholder geben hier ihre Ratschläge und Feedback dem Team und Product Owner bekannt.

Schwiegermütter müssen in diesem Meeting besonders gut koordiniert werden. Hier können auch die Scrum Master eine grosse Hilfe sein.

Artefakte

In Scrum für die Ehe wird versucht, die Anzahl der Artefakte auf ein Minimum zu reduzieren. Bei jedem Artefakt muss hinterfragt werden wie es um den Return on Investment steht.

Unumgänglich sind jedoch folgende Artefakte:

  • Die Produktinkremente
  • Hohe Telefonrechnungen (Telefonate Product Owner mit Stakeholdern)
  • Dreckige Windeln ab Sprint 2

Velocity

Die Velocity wird als Grundlage für die Planung der Releases verwendet.

Die Berechnung erfolgt durch folgende Formel:

Velocity = Z / ((S * W * H) + D)

mit

S: Anzahl Nächte pro Woche ohne Schlaf

W: Anzahl Waschgänge pro Woche

H: Anzahl Heulkrämpfe pro Produktinkrement und Monat

Z: Zeit Product Owner ohne Team

D: Zeitdilatationsfaktor (dynamisch gefühlte Zeit pro Realzeiteinheit an Familienessen)

Ablehnung der Haftung

Obwohl wir alle Anstrengungen unternommen haben, alle Informationen aus vertrauenswürdigen Quellen zu beziehen, lehnen wir jegliche Haftung ab für Fehler, Irrtümer oder Resultate welche auf Grund dieser Informationen entstehen.

Alle Informationen sind ohne Garantie für Vollständigkeit oder Genauigkeit und ohne Zusicherung jedwelcher Art.

In keinem Fall werden wir deshalb verantwortlich sein für euch oder irgendjemand sonst oder für jedwelche ausgeführte Aktion aus Vertrauen zu den Informationen dieser Veröffentlichung.

Die Information dieser Veröffentlichung sollte nicht als Ersatz für professionelle Beratung gebraucht werden. Vor jedwelcher Entscheidung oder Aktion solltet ihr einen Berater konsultieren.

About the author

Urs Enzler

5 comments

By Urs Enzler

Recent Posts