Über die letzten zwölf Jahre habe ich immer mal wieder eine Buchempfehlung in unserem Magazin agile review veröffentlicht. Einige alte Ausgaben sind mittlerweile leider vergriffen. In Ausgabe 2/2016 habe ich ein Buch gereviewt, das mir den Begriff „Digitalisierung“ bis heute am besten erklären konnte.
Über die letzten zwölf Jahre habe ich immer mal wieder eine Buchempfehlung in unserem Magazin agile review veröffentlicht. Einige alte Ausgaben sind mittlerweile leider vergriffen. Das heutige Buchreview stammt aus der Ausgabe 2/2016 und taucht in das dritte LeSS-Buch von Craig Larman und Bas Vodde ein.
Vor Jahren nahm ich mal an einem Planning eines Scrum-Teams teil. Neben viel Celebration fiel mir da vor allem ein Effekt auf, den ich auch heute noch – Jahre später – als Zeitverschwendung ansehe: das (vermeintliche) Commitment eines Scrum-Teams auf Basis einer Zahl wie der Velocity aus vorherigen Sprints.
Über die letzten zwölf Jahre habe ich immer mal wieder eine Buchempfehlung in unserem Magazin agile review veröffentlicht. Einige alte Ausgaben sind mittlerweile leider vergriffen. Das heutige Buchreview stammt aus der Sonderausgabe zu Kundenbegeisterung von 2016 und befasst sich mit kurzen Innovationswochen, die die Autoren Sprint nennen. In Abgrenzung zu Sprint aus Scrum nenne ich diese auch Google-Design-Sprints.
Die Geschichte von Scrum ist eine Geschichte voller Missverständnisse. Heute werfen ich mal einen Blick auf das, wozu in einigen Organisationen das Sprint Review verkommen ist, eine Sprint Demo mit Akzeptanz-Celebration. Für heute habe ich mir mal vorgenommen, von der positiven Seite zu argumentieren, warum das eine schlechte Idee ist. Mal gucken, wie gut mir das gelingt.
Wenn man lange genug im agilen Kosmos unterwegs ist, – gerade während Lock-Down-Maßnahmen während einer Pandemie – dann taucht irgendwann die Frage auf, welches Tool man denn für diesen ganzen agilen Kram am besten einsetzen sollte. Heute ist es Zeit, dass ich mich einmal dem widme, was ich Tool-Driven Development nenne. Denn: A fool with a tool is still a fool.
Ein weiterer agiler Unsinn in meinen Augen ist das weit verbreitete User-Story-Schema. In Schulungen sage ich immer, dass ca. 90% aller Scrum-Teams da draußen glauben, dass man mit Scrum auch User Storys machen muss, kommen allerdings dabei niemals über die „Stützräder-Phase“ von User Storys hinaus. Zeit, damit einmal ein wenig aufzuräumen.
In so gut wie jeder Schulung bekomme ich die Frage gestellt, was eigentlich eine Definition of Done ausmacht, was da so drin steht, und überhaupt, wie man eine perfekte Definition of Done zusammenstellt. Wie in Schulungen auch möchte ich hier nicht auf die Fragen eingehen, sondern vielmehr meine Perspektive zur Definition of Done (und vielleicht auch zur Definition of Ready) teilen auf einem höheren Level.
Sorry, für den Click-Bait. Für heute habe ich mal ein paar Dinge zusammengesammelt, die mir immer wieder als Missverständnisse bei SchulungsteilnehmerInnen und Beratungskunden unterkommen. Schauen wir mal, wie viele es werden.
Über die letzten zwölf Jahre habe ich immer mal wieder eine Buchempfehlung in unserem Magazin agile review veröffentlicht. Einige alte Ausgaben sind mittlerweile leider vergriffen. Die heutigen Buchreviews stammen aus der Ausgabe 1/2014. Die damalige Ausgabe hat sich mit dem Thema Skalierung auseinandergesetzt. Deshalb habe ich gleich eine ganze Reihe an Büchern zu agiler Skalierung zusammen gereviewt.