Die wohl bekannteste Form von Slacktime ist die (mittlerweile nicht mehr existente) Google 20% Regel. Wir sprechen über unsere eigenen Erfahrungen mit Slacktime und kommen darüber auch auf Hackathons, Coding Dojos und Gamejams zu sprechen.
Heute vor genau einem Jahr ist mit “Flying Dutchman” Scrum unsere allererste Folge erschienen. Wir lassen das Jahr Revue passieren und unterhalten uns über unsere jeweiligen Lieblingsfolgen, unsere generellen Highlights und geben einen kleinen Ausblick was demnächst alles so kommt oder kommen könnte. Ursprünglich wollten wir in der Beschreibung noch irgendwas mit “die große Geburtstagsfolge” schreiben, aber 20 Minuten sind einfach nicht groß.
Wir sagen vielen Dank für das Jahr, in dem ihr uns zugehört, mit uns diskutiert, uns Themen vorgeschlagen habt oder uns auch mal ganz spontan Lego ausgeliehen habt und hoffen, dass ihr uns weiterhin erhalten bleibt. Auf die nächsten 52 Wochen!
Etwas später als gedacht, haben wir es aber endlich geschafft eine vierte, finale, Folge zum Thema “Agil skalieren” aufzunehmen. Dominik klärt mit unserem Gast Birgit Mallow, selbstständige Beraterin / Agile Coach, nicht nur die Details darüber, wie das Scaled Agile Framework aufgebaut ist, sondern versucht auch direkt zu Anfang mit Birgit zusammen die Frage zu beantworten, warum SAFe so unbeliebt ist. Außerdem erfahrt ihr, was das alles mit Parkplätzen zu tun hat.
Hinweis: Im Podcast beziehen wir uns auf SAFe in der Version 4.0. Zum Zeitpunkt der Aufnahme war 4.5 erst seit kurzer Zeit erschienen.
Die Folge der vielen Versprecher! Mit viel Gestammel tauschen wir Anekdoten über kaputte und gute Taskboards aus, klären, wie die Definition of Done auf dem Board landet sowie die Frage, ob analoge Boards denn nicht Papierverschwendung sind.
Der klassischste aller Rollenkonflikte in einem Scrum Team ist, wenn eine Entwicklerin oder ein Entwickler gleichzeitig Scrum Master ist. Doch auch die Kombination aus Scrum Master und Product Owner oder Entwicklerin und Product Owner ist problematisch. Wir werfen einen Blick auf die verschiedenen Konstellationen und deren Probleme und wie man letztendlich damit umgehen kann.
Im Mai 2017 haben wir auf der JAX den Vortrag “Mein Scrum ist kaputt!” gehalten, der auch auf Video aufgenommen wurde. Mit freundlicher Genehmigung der S&S Media GmbH präsentieren wir euch die Tonspur unseres Vortrags, in dem wir diverse Phänomene beleuchten, die uns beim Einsatz agiler Softwareentwicklung immer wieder über den Weg gelaufen sind. Diese versuchen wir zu analysieren, wie sie entstehen und bieten Hilfestellungen an, um diese zu vermeiden oder, wenn sie bereits eingetreten sind, in Angriff zu nehmen.
Falls ihr euch lieber das Video anschauen wollt: Hier geht es zum Video.
Katrin Bretscher ist Sport-Mentaltrainerin und coacht ein schweizer Eishockey-Team. Außerdem ist sie auch gleichzeitig freiberufliche Scrum Masterin und hat in einem augenöffnenden Moment erkannt, dass sie viele Methoden aus dem Sport-Mentaltraining auf ihre Arbeit als Scrum Masterin anwenden. Sie erzählt uns, wie so ein Mentaltraining überhaupt aufgebaut ist, was die “individual zone of optimal functioning” ist und wie Superkompensation nicht nur beim Muskelaufbau, sondern auch im Beruf hilft. Aufgenommen auf dem Agile Coach Camp 2017.
Auf dem Agile Coach Camp 2017 hat sich Dominik mit Dana, Mick von Mayflower und Alexander von oose zusammengesetzt und die Fragestellung diskutiert, ob es so etwas wie viel Transparenz geben kann. Relativ ausführlich erzählen wir dabei von unseren Erfahrungen damit, welche Vor- und Nachteile Transparenz hat und überlegen uns, wie wichtig Timing, Relevanz, zielgruppengerechte Aufbereitung und Pull von Informationen sein kann.
Es kommt gelegentlich mal vor, dass ein Sprint abgebrochen werden muss. Der Scrum Guide ist zudem unerwartet ausführlich zu dem Thema (Zitat Sebastian: “Da steht fast mehr dazu drin als über die Aufgaben eines Scrum Masters”). Wir reden darüber, wann ein Sprintabbruch sinnvoll ist, wer ihn anordnen darf und versuchen herauszufinden, was in aller Welt der Scrum Guide mit dem Satz “Die bislang daran geleistete Arbeit verliert schnell an Wert, daher müssen diese Einträge häufiger neu geschätzt werden.” meint.
Schätzen ist ein leidiges Thema, besonders in der Softwareentwicklung – zu oft wird man auf ein Bauchgefühl festgenagelt. Wir suchen nach Gründen dafür, warum es sinnvoll ist in Storypunkten zu schätzen und welche Methoden es dafür gibt. Zum ersten Mal entfacht außerdem fast schon eine hitzige Debatte zwischen Sebastian und Dominik, wie sinnvoll es ist, die ursprüngliche Referenz für die eigene Schätzskala auf Dauer zu behalten. Zum Abschluss haben wir beide noch puren Trash in den Picks der Woche.