Mein Scrum ist kaputt | Agilität, Scrum, Kanban und mehr

Wir fahren fort mit unserer Serie „Scrum Events revisited“ und sprechen heute über das Sprint Review: Was hat sich seither im Scrum Guide getan? Was haben wir in den Jahren dazugelernt und wie würden wir heute ein Sprint Review durchführen? In einer unserer ersten Folgen, in Folge 10, sprachen wir bereits über das Sprint Review. Seither hat sich nicht nur in der agilen Welt einiges getan, auch wir haben viele Erfahrungen gesammelt, die uns haben hinterfragen lassen, ob wir heute noch ein Sprint Review durchführen würden, wie vor 4-5 Jahren? Die Antwort ist eindeutig: Eher nicht. Nicht nur gab es in der Zwischenzeit ein größeres Update des Scrum Guide, mit welchem Produktziele (Folge 101 – Das Product Goal) eingeführt wurden. So sprechen wir also über die drei Phasen, die wir typischerweise in einem Sprint Review sehen, darüber welchen Wert das Event hat und welche Tätigkeiten einem Sprint Review gut tun und welche eher nicht. Spoiler: Punktezählerei, Powerpoint-Schlachten und Abnahmen gehören nicht dazu Außerdem gibt’s einen Auszug unserer schlimmsten Sprint Review Erlebnisse. Viel Spaß beim Hören! Der Beitrag Folge 110: Das Sprint Review 1x1 im Jahr 2022 erschien zuerst auf Mein Scrum ist kaputt!.

Das Agile Manifest besagt, dass „funktionierende Software über umfassender Dokumentation“ stehe. Wir besprechen, was es damit auf sich hat und warum das nicht heißt, dass Dokumentation einfach wegfällt. Wenn es darum geht, Dokumentation im Agilen Kontext zu verstehen, ist damit keinesfalls gemeint, Dokumentation einfach über Bord zu werfen. Vielmehr geht es darum zu verstehen, dass Dokumentation an sich erst einmal eine „verschwenderische“ Tätigkeit ist, die keinen direkten Produktwert erzeugt. Mit diesem Wissen im Hinterkopf ist die agile Sichtweise eher diese: Wie kann Aufwände für Dokumentation sparen, indem ich diese Zeit an anderen Stellen investiere, damit ich diese Dokumentation gar nicht brauche? Wir sprechen in diesem Zuge über Automatisierung, Behaviour Driven Development (BDD), aber auch über User Stories und die 3C-Methode (Card, Conversation, Confirmation), warum ein enger Draht zu meinen Anwender:innen hilft, Dokumentation zu vermeiden und warum Dokumentation oft missbräuchlich benutzt wird, um Kommunikation zu ersetzen und (verlustbehaftete) Übergaben vermeintlich weniger verschwenderisch zu gestalten. Links zur Folge Folge 92: Epics, User Stories, Tasks und andere VorgangstypenFolge 88: PO Toolbox, Teil 2 – Gemeinsames VerständnisAgile Modeling: „Agile/Lean Documentation: Strategies for Agile Software Development“ Pick der Woche: „Jurgen Appelo – The unFIX Model for Versatile Organizations“ Lang ist’s her, aber tatsächlich haben wir endlich mal wieder einen Pick für euch: Sebastian teilt das „unFIX Model for Versatile Organizations“ von Jurgen Appelo, der damit eine Alternative zu SAFe, LeSS, Holacracy, Management 3.0, das „Spotify-Modell“ und Matrixorganisationen anbieten möchte. Viele lesenswerte Einblicke und Gedanken. Alle Links hierzu: Jurgen Appelo: The unFIX Model for Versatile OrganizationsHeidi Helfand: Dynamic ReTeaming*Matthew Skelton, Manuel Pais: Team Topologies*David Marquet: Turn the Ship Around!: A true story of turning followers into leaders* * Affiliate Links Der Beitrag Folge 109: Agile Dokumentation erschien zuerst auf Mein Scrum ist kaputt!.

Liberating Structures sind 33 Mikrostrukturen die dabei helfen alle einzubeziehen und sich zu beteiligen. Die Idee ist, dass bessere Ergebnisse erzielt werden, wenn Menschen in Teams gut zusammen arbeiten, alle bei der Suche nach der besten Idee beteiligt werden und zu Wort kommen. Es geht darum, dass die Menschen sich selbst organisieren und zusammen arbeiten wollen. Da wir hier viele Überschneidungen mit Scrum sehen, haben wir Daniel Steinhöfer, der gerade ein Buch zu dem Thema veröffentlicht hat, einmal eingeladen um uns darüber auszutauschen. Links Weitere Informationen zu Liberating StructuresLinkedIn-Profil von Daniel Steinhöfer Der Beitrag Folge 108: Liberating Structures (mit Daniel Steinhöfer) erschien zuerst auf Mein Scrum ist kaputt!.

Beim Sprint Planning hat sich in den Jahren seit unseren ersten Folgen zum Thema einiges getan: Wir haben neue Ideen, der Scrum Guide neue Formulierungen. Zeit, das Sprint Planning nochmal unter die Lupe zu nehmen und zu besprechen: Wie sieht ein Sprint Planning im Jahr 2021 aus? Bereits in Folge 54 und Folge 55 haben wir über die beiden Teile des Sprint Plannings gesprochen. Das war im Jahr 2018. Seither hat sich der Scrum Guide mit dem 2020er Update deutlich verändert und aus zwei Themen wurden drei Themen, die in der Sprintplanung bearbeitet werden: Die Vorstellung und Erarbeitung eines Sprintziels, die Auswahl der dazu passenden Product Backlog Items und die Erstellung eines Plans, wie dieses Ziel erreicht werden soll. Natürlich haben wir aber auch neue Erkenntnisse und Erfahrungen gesammelt, die teils unsere damaligen Aussagen unterstreichen, aber auch neue Ideen einbringen. Deshalb war es für uns an der Zeit (und von einigen von euch der Wunsch), dass wir uns nochmal mit den Scrum Events aus heutiger Sicht beschäftigen. Titelbild: Sage (Wiki Education Foundation) under CC BY-SA 4.0 Der Beitrag Folge 107: Das Sprint Planning 1x1 im Jahr 2021 erschien zuerst auf Mein Scrum ist kaputt!.

Oft haben wir im Podcast schon gesagt, das Product Backlog sei keine Ideenablage und aus Transparenzgründen kein Ort für „Man könnte ja mal“ oder „Vielleicht, wenn wir mal Zeit und Lust haben“. Aber wohin dann mit den Ideen? Wir sprechen deshalb darüber, wie und wo Ideen eigentlich verwaltet werden können und warum es gar besser ist, Ideen frühzeitig zu hinterfragen, statt sie zu managen. Wir besprechen, wie Personal Kanban Product Owner*innen dabei helfen kann, Ideen auf ihrem Weg zu Anforderungen zu visualiseren und nachzuverfolgen und inwiefern Tools wie „Portfolio Kanban“ dabei helfen können. Einen kurzen Blick werfen wir außerdem auf Frameworks (Lean Startup, Design Thinking, …), die gerade im Bereich der Product Discovery besonders stark sind, also dann, wenn selbst die Ausgangsfragen für ein Produkt noch völlig unklar sind. Links Jim Benson – Personal Kanban: Mapping Work | Navigating Life*Eric Ries – The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses*Portfolio Kanban * Amazon Affiliate-LinksTitelbild: flickr.com/Nestle (CC BY-NC-ND 2.0) Der Beitrag Folge 106: Wohin mit den Ideen, wenn nicht ins Product Backlog? erschien zuerst auf Mein Scrum ist kaputt!.

Welcher Background für Scrum Master „der Richtige“ ist, wird immer wieder diskutiert. Konstantin Diener von cosee hat sich vor Jahren entschieden nur noch Psychologen als Scrum Master einzustellen und hat damit gute Erfahrung gemacht. Er und seine „Scrum Masterin Nr. 1“ Carolin Huck berichten in dieser Episode wie es zu der Entscheidung kam, wie die Kollegen reagiert haben und wie der Einstieg lief. Außerdem erfahren wir wo die Beiden die Vorteile für diese Ausrichtung sehen. Was meint ihr dazu? Welchen Background findet ihr für die Scrum Master Rolle sinnvoll? Links Blog Artikel von CoseeLinkedIn-Profil von Konstantin DienerLinkedIn-Profil von Carolin Huck Der Beitrag Folge 105: Psychologen als Scrum Master erschien zuerst auf Mein Scrum ist kaputt!.

Ausgelöst durch einen Tweet von @BenMahr mit Verweis auf das Framework „Flight“ haben wir uns gefragt: Wenn es so viele schlechte Implementierungen von Scrum gibt, das Framework offenbar dazu einlädt, es falsch zu verwenden, ist dann vielleicht auch das Framework schuld? Dieser Fragestellung gehen wir auf den Grund, beleuchten die unterschiedlichen Seiten, woran es liegt und sprechen über Ansätze, wie man gegensteuern kann. Liegt es an der Beratung vor der Implementierung? Liegt es an der fehlenden Orientierung? Menschen mögen Blueprints und Kopiervorlagen – braucht es so etwas? Heute etwas philosophischer und ohne handfestes Ergebnis, aber vielleicht mit einigen Denkanstößen und wir freuen uns über eure Perspektiven! Links „Auslöser“, Tweet von @BenMahrTwitter-Thread zu „Flight“Stufen des Nichtwissens: Wissen und NichtwissenStefan Roock: Shades of Scrum: The Scrum Master Role Der Beitrag Folge 104: Ist das noch Scrum oder kann das weg? erschien zuerst auf Mein Scrum ist kaputt!.

Sebastian und Ina sprechen mit Tim Klein vom Product Owner Podcast „Die Produktwerker“ über das Product Ownership Evolution Model (POEM) und das Product Ownership Context Canvas (POCC). Zuerst klären die drei, was sie jeweils unter dem Begriff Product Ownership verstehen. Danach geht es genauer um das POEM, welches dabei hilft, die aktuell gelebte und zukünftig angestrebte Ausgestaltung von Product Ownership zu visualisieren, zu diskutieren und so gemeinsam weiterzuentwickeln. Schließlich wird das POCC vorgestellt, welches eine Reflektion der jeweiligen Handlungsfelder ermöglicht. Links Product OwnershipPOEM (Product Ownership Evolution Model)POCC (Product Ownership Context Canvas)Podcast „Die Produktwerker“ Der Beitrag Folge 103: Product Ownership Evolution Model (mit Tim Klein) erschien zuerst auf Mein Scrum ist kaputt!.

Zwei essentielle Elemente in Scrum sind das Daily Scrum und die Sprint Retrospektive. Doch was, wenn diese beiden Events dem Team eher schaden, weil fehlendes Vertrauen zu dysfunktionalem Verhalten führt? Im Blog von J. B. Rainsberger stießen wir auf einen Artikel mit der Überschrift“ Your Daily Scrum is killing your Team!“. Der Autor beschreibt, wie er immer unterschiedliche Methoden versuchte, um schlechte Dailies im Team endlich zu guten werden zu lassen, bis er feststellte, dass es dem Team fundamental an Vertrauen fehlte. Das führte zur Verhaltensmustern, mit denen sich Teammitglieder im Daily versuchten zu decken, ihre Arbeit auszuschmücken und all die lustigen Dinge taten, die man tut, wenn man sich nicht hinter die Fassade schauen lassen möchte. Die Lösung? Dailies abschaffen! Zumindest vorläufig. Oder … ? Genau hierüber haben Ina und Sebastian diskutiert und wir haben uns gefragt, wann diese Maßnahme überhaupt notwendig ist, welche Arten Vertrauensmangel es überhaupt gibt und wie sich Vertrauen eigentlich aufbauen lässt. Kurz gesagt: Es ist kompliziert. Umso mehr freuen wir uns auch auf eure Geschichten! Links JBrains.ca – Your Daily Scrum is killing your Team!Gefühlsmonster-Karten Der Beitrag Folge 102: Fehlendes Vertrauen - Wenn das Daily dem Team schadet erschien zuerst auf Mein Scrum ist kaputt!.

Mit dem Product Goal, oder Deutsch auch „Produktziel“, als eines der neuen Scrum Commitments, hat im großen 2020er Update des Scrum Guide eine besonders spannende und wichtige Änderung Einzug gehalten. Wir gehen auf die Fragen von Hörer Sven zum Product Goal ein und besprechen, ob Product Goal und Produktvision eigentlich synonym sind, was mit Dingen passiert, die nicht ins Ziel passen, wie man ein gutes Product Goal findet, was man damit dann anstellt und vor allem: Wie mache ich das eigentlich in Jira!?! Titelbild: Swen-Peter Ekkebus (CC BY 2.0) Der Beitrag Folge 101: Das Product Goal erschien zuerst auf Mein Scrum ist kaputt!.