Mit dem 2020er Update erfährt der Scrum Guide die wohl umfassendste Überarbeitung seit seiner Einführung im Jahr 2010. Mit dem Ziel den Scrum Guide deutlich zu entschlacken und besser verständlich zu machen, hat sich der Umfang von fast 20 Seiten auf nur noch 13 reduziert. Nicht nur Formulierungen wurden angepasst, sondern auch inhaltlich gibt es neben dem neu eingeführten „Product Goal“ oder der nun fehlenden „Velocity“ einige Änderungen.
Wir haben den Scrum Guide 2020 genau unter die Lupe genommen und sprechen über alle Änderungen, die aus unserer Sicht erwähnenswert finden, was wir glauben, welchen Einfluss diese neuen Änderungen haben werden und inwieweit sich das generelle Verständnis von Scrum mit dem neuen Scrum Guide ändern dürfte.
Jubiläumsumfrage zur 100. Folge
Da wir uns im Endspurt zu unserer 100. Folge befinden und wir das natürlich mit euch feiern möchten, haben wir eine kleine Umfrage vorbereitet. Sie dient uns als Retrospektive und gleichzeitig möchten wir gerne eure Erlebnisse und Erfahrungen im Zusammenhang mit „Mein Scrum ist kaputt“ hören. Um euch für eure Mühen zu danken, verlosen wir unter allen Teilnehmenden einen 30€ Amazon-Gutschein und für unsere Jubiläumsfolge winken noch ein paar weitere schöne Goodies 🙂
Hier geht’s zur Umfage: https://forms.gle/EeaJs3fQtU473myU9
Picks
Bereits vor einer Weile stellte uns Hörer Markus die folgenden zwei Fragen mit der Bitte um Beantwortung in einer Folge:
Wie geht man damit um wenn das Entwicklungsteam fast ausschließlich aus externen Mitarbeiter*innen besteht?
Und wie, wenn das Entwicklungsteam hauptsächlich aus internen Mitarbeiter*innen besteht, die aber bloß z.B. zu 60% für das Entwicklungsteam abgestellt sind und die restlichen 40% nicht da sind und andere Aufgaben haben?
Wir nehmen das als Anlass, um die Zusammenstellung von Scrum-Teams generell zu erörtern und versuchen im Anschluss diese beiden Fragen zu beantworten.
Quelle des Titelbildes: https://commons.wikimedia.org/wiki/File:Gemeinderat.jpg
Picks
Möchtet ihr besser verstehen, wie Spieleproduktion wirklich funktioniert? Was da alles schieflaufen kann? Dann haben wir da was für euch: In diesem neuen Crossover-Podcast mit The Pod / Auf ein Bier spricht Dominik mit Producer-Gott und Entwicklungs-Master Ralf Adam über die Feinheiten der (agilen) Software-Entwicklung. In dieser ersten Ausgabe sprechen die beiden über die Vorproduktionsphase der Entwicklung: Was ist die Pre-Production, was macht man da eigentlich und vor allem auch: Was für Fehler werden da gerne gemacht?
Links
Spätestens seit Google’s Projekt „Aristotle“ ist der Begriff der Psychologischen Sicherheit so richtig en vogue. Der Begriff wurde vor allem durch die Harvard-Professorin Amy Edmonson geprägt und beschreibt, vereinfacht ausgedrückt, dass sich alle Mitglieder eines Teams in ihrem Umfeld so sicher fühlen, dass sie keine Angst davor haben, Dinge anzusprechen oder auszudrücken. Sie wissen, dass sich alle Teammitglieder auf eine positive Art damit auseinandersetzen und gesagte Dinge nicht gegeneinander verwenden werden.
Wir sprechen mit Michael May über das Konzept der Psychologischen Sicherheit, grenzen den Begriff ab zur Emotionalen Sicherheit und Psychischen Sicherheit, diskutieren woran man sie erkennt und wie man sie fördert. Michael hat Psychologie studiert und arbeitet als Agiler Coach bei der Mayflower GmbH.
Buchtipp
Amy Edmondson: The fearless Organization https://amzn.to/3j1GSyd (Ref-Link)
Links
Bildquelle: https://commons.wikimedia.org/wiki/File:CISV_trust_game.JPG (CC BY-SA 3.0)
Der Release Sprint gilt gemeinhin als Anti-Pattern. Wir graben in unserer Vergangenheit nach eigenen Erfahrungen mit Release Sprints und versuchen zu erörtern, ob wir sie gut oder schlecht fanden und ob wir sie heute nochmal – aller Anti-Pattern zum Trotz – nicht dennoch erneut einsetzen würden
Picks
Sage und schreibe 4 Jahre ist es nun her, dass wir mit „Flying Dutchman Scrum“ am 2. September 2016 die erste Folge von „Mein Scrum ist kaputt“ veröffentlicht haben. 4 Jahre und 93 Folgen später feiern wir dieses Ereignis und lassen das letzte Podcast- sowie private Jahr Revue passieren.
Und da wir in den bisherigen Geburtstagsfolgen Ankündigungen für die Zukunft abgegeben haben, die nie eingetreten sind, lassen wir für die Kategorie diesmal der Vorstellungskraft freien lauf – warum etwas Realistisches planen, wenn man gleich die eigene Großveranstaltung planen kann?
„Das hast du wirklich gut gemacht!“ – so oder so ähnlich fallen Sätze im Arbeitsalltag, wenn es darum geht, dass wir unseren Kolleg*innen Anerkennung ausdrücken möchten – und dann aber vielleicht eher ins Tätscheln verfallen.
Lob vs. Anerkennung ist das, worüber wir heute sprechen möchten. Wir möchten herausfinden, ob es Unterschiede gibt wenn ja: Wie sehen diese aus? Und wenn eines der beiden blöd ist, wie mache ich das Andere richtig?
Links
Picks
Auch in dieser Folge widmen wir uns einem Hörervorschlag. Themole wollte wissen, welche Vorgangstypen es denn eigentlich gibt und welche sinnvoll sind. Dabei müssen wir zuallererst mit einiger Verwirrung aufräumen, die es – wohl auch gerade dank JIRA – rund um die Begriffe Epics, User Stories, Tasks, Subtasks und anderer solcher „Vorgangstypen“ gibt. Wir lösen uns dabei von JIRA und schauen, welche Begriffe denn überhaupt gängig sind und was sie üblicherweise bedeuten und was wir darunter verstehen.
Abschließend widmen wir uns auch der Frage, wie und wann diese unterschiedlichen Einheiten überhaupt entstehen und zum Einsatz kommen und, was wir glauben, warum sich Thomale mit dieser Unterteilung in seinem Projekt im Embedded Systems Umfeld schwer tut.
Kurzer Hinweis in eigener Sache: Wir mussten die Folge aufgrund einer Unterbrechung in zwei Teilen aufnehmen und reißen in dem Zusammenhang auch kurz das Thema an, wie man eigentlich als Moderator mit Störungen und Unterbrechungen umgeht.
Picks
Sounds
Beitragsbild von Jacopo Romei, Published under CC BY-SA 2.0
Heute widmen wir uns einem Thema von Zuhörer Alexander, der in unserem Slack vorgeschlagen hat, doch mal über „Verbranntes Scrum“ zu reden: Ein Team hat bereits einmal versucht, Scrum einzuführen und das ist dermaßen in die Hose gegangen, dass das Thema durch ist – verbrannte Erde, verbranntes Scrum.
Wie schafft man es nun mit dem Team einen zweiten Anlauf zu starten, wo doch keiner mehr Lust darauf hat und die Worte Planning, Daily oder Retrospektive nicht mehr hören kann?
Picks
