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.

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.