Direkt zum Hauptbereich

Wie fühlen sich Backlog Refinement, Sprint Planning und Daily Scrum an?

Das populärste agile Framework hat seinen Namen von einer Mannschaftssportart bekommen. Scrum bedeutet Gedränge. Beim Rugby bekommt man ein Gefühl für die Zusammenarbeit im Team. Gibt es auch Vergleiche für die Scrum Ereignisse? Hier ist mein Vorschlag.


Umkleidekabine (Quelle: Wikimedia)
Wie kann man die Scrum Ereignisse besser intuitiv verstehen. Es gibt fünf Ereignisse:
  • Der Sprint selbst bildet den Container für alle anderen Scrum Ereignisse und die eigentliche Arbeit.
  • Der Sprint beginnt mit dem Sprint Planning, in dem das Scrum Team ein Sprint Ziel festlegt. Es plant ganz konkret, wie es das Ziel erreichen will. Vor dem Sprint Planning gibt es das Backlog Refinement.
  • Das Daily Scrum dient dazu, sich im Team immer wieder auf das Sprint Ziel zu fokussieren.
  • Im Sprint Review sieht sich das Scrum Team die Ergebnisse an, um über die Zukunft zu entscheiden.
  • In der Sprint Retrospektive legt das Scrum Team 1-2 Verbesserungsmaßnahmen fest, um die Lieferfähigkeit im nächsten Sprint zu verbessern.
 Vergleichen wir das nun mit einem Teamsport.
  • Der Sprint ist im Prinzip die Zeit zwischen zwei Spielen incl. des Spiels selbst. Wir sehen gleich, wann er beginnt und endet. Der Vergleich passt nicht ganz, weil die Sprintlänge nicht immer gleich wäre. Aber der Rhythmus ist zu erkennen.
  • Beim Sprint Planning ist das Team schon in der Kabine. Das Team weiß, gegen wen es heute spielt. Es weiß, ob es gewinnen muss oder ob ein Unentschieden reicht. Keiner hat seine Trikots vergessen. Die Trinkflaschen sind aufgefüllt. Vorher gibt das Refinement. Dort wird geklärt, wer den Bus fährt, wer die Trikots einpackt usw.
  • Das Daily Scrum ist mit den Teambesprechungen auf dem Spielfeld zu vergleichen. Immer wieder werden die Züge abgestimmt, um das Ziel zu erreichen.
  • Im Sprint Review wird der Sieg gefeiert oder die Niederlage betrauert.
  • In der Sprint Retrospektive wird das Spiel ausgewertet und das Team entscheidet, was bis zum nächsten Spiel verbessert wird.
Was passiert nun, wenn sich das Team nicht um das Refinement kümmert? Im schlechtesten Fall kann es gar nicht antreten, weil Spieler oder Material fehlen.

Was passiert, wenn es kein klares Ziel gibt? "Wir wollen gewinnen" ist genauso so leer wie "Wir setzen Backlog-Einträge 45-48 um".

Was passiert, wenn sich die Retrospektive weder auf das abgelaufene noch auf das nächste Spiel bezieht? Das Team verbessert sich nicht. Die Ideen sind zu unkonkret.

Kennt jemand noch andere Vergleiche?

Kommentare

  1. Vergleichen wir die Scrum Ereignisse dem Umbau eines alten Hauses mit der Hilfe von Freunden und, noch gefährlicher, Familie.

    Der Sprint ließe sich klassisch gestalten. Je nach eigener Schmerzgrenze und Vertrauensbasis kann dieser von 1- 4 Wochen laufen.

    Das Sprint- Planning findet klassischerweise zwischen Bohrmaschine, Baudreck und leeren Zigarettenschachteln statt, in dem Raum, der später einmal die Küche werden wird. Hier ist besonderes Geschick des Scrum Masters gefragt, um das Entwicklungsteam auf die Vision des Auftraggebers einzuschwören. Jeder hat sein Handwerkszeug dabei, alle Materialien sind organisiert. Vorher gibt es das Refinement. Wieder dabei: der Kasten Bier, wieder in der der späteren Küche. Es wird geklärt, wer die Rigipsplatten abholt, wer die Kupferrohre beim Händler bestellt.

    Das Daily Scrum findet statt, wenn alle freiwilligen Helfer nach dem eigenen Feierabend auf der Baustelle ankommen. Erstmal ein Bier aufmachen. "Wie weit bist du gestern mit dem Fußboden gekommen? Ich muss Freitag mit der Heizung anfangen." Nach zwei Kippen kann es losgehen.

    Im Sprint Review wird das Ergebnis gefeiert oder die Rückschläge betrauert. Egal was von beidem, die Flasche Bölkstoff bleibt fest in der einen, der Inhalt der Hosentasche des Handwerkerstramplers in der anderen Hand.

    In der Sprintretrospektive wird das Zusammenspiel des Teams ausgewertet und das Team entscheidet, wie es zukünftig besser miteinander auskommen könnte, auch wenn bei jedem mal die Emotionen überkochen und die Wände zum Wackeln bringen. Hier ist wieder die Sensibilität des Scrum Masters für die Stimmungen der einzelnen Teammitglieder einzufangen. Für eine lockere Atmosphäre empfiehlt sich Bockwurst, Kartoffelsalat … und Bier.

    Was passiert, wenn der Product Owner keine klare Vision ans Team vermittelt? Ruckzuck findet sich der Auftraggeber in einem Badezimmer wieder, das dem des Schwagers verdächtig ähnlich sieht. Oder die Steckdosen sind so verteilt, das sie perfekt auf den Haushalt eines wenig technikaffinen Singlemannes passen.

    Was passiert, wenn das Team das Zusammenspiel nicht regelmäßig reflektiert? Die zukünftigen Familienfeiern werden in jedem Falle spannender.

    Was passiert, wenn der Scrum Master nicht für Biernachschub in ausreichender Menge sorgt und die Teammitglieder an die Ordnung auf der Baustelle erinnert und auch mal selber die Bierdeckel, Schrauben und Kippenstummel von den Fensterbrettern sammelt.




    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.

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!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch 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.