Folgender Artikel flog gerade auf Mastodon an mir vorbei (Danke an https://podcasts.social/@thomas_michl@mastodon.social fürs Teilen)!
https://www.scrum.org/resources/blog/scrum-no-excuse
Meine Gedanken dazu:
These 1: In Scrum sind Prognosen nötig.
Der Artikel sagt:
Ein häufiger Irrtum besteht darin zu glauben, dass Scrum bedeutet, dass keine Prognosen erstellt oder Termine eingehalten werden können. Tatsächlich ist es wichtig, realistische Fristen zu setzen und einzuhalten, um die Vorhersagbarkeit, das Vertrauen und die Transparenz zu erhöhen. Die Produktprognose liegt in der Verantwortung des Product Owners, der dabei die Geschichte des Teams sowie den Inhalt und die Reihenfolge des Product Backlogs berücksichtigt.
Das ist schon richtig, aber in der Praxis schwer umzusetzen. Worauf soll die Prognose basieren? Klar, auf der Vergangenheit - sprich auf der Velocity. Doch wovon ist die Velocity abhängig? Eben von der Vergangenheit. Was wir in der Softwareentwicklung aber machen, ist in der Regel eben immer neu und daher nicht prognostizierbar. Die Velocity ist eine Messung des Managements. Ich bleibe dabei: Scrum ist eher ein Tool des Managements. In dem Agilen Manifest oder auch in den Agilen Prinzipien ist nirgendwo die Rede von Prognosen oder Deadlines. Im Gegenteil - es geht darum kontinuierlich Wert zu liefern. Und das in kleinen Schritten. Eben nicht in großen Happen - den Iterationen - alle 2 oder 4 Wochen. Auch wenn es hier nur am Rande passt: Führt Euch mal das Wort "Sprint" genauer vor Augen... Wie will man den permanent sprinten?
These 2: Scrum schafft Ordnung
Der Artikel sagt:
Scrum bedeutet nicht, dass man wahllos die Richtung ändern oder jeder Anfrage zustimmen sollte, nur weil man "agil" ist. Ein klar formuliertes Produktziel ermöglicht es dem Product Owner, Arbeit abzulehnen, die nicht dem Produktziel dient, und das Backlog so zu ordnen, dass die wertvollste Arbeit zuerst erledigt wird.
Auch hier erstmal Zustimmung. Agil heißt nicht schnell. Agil schließt planvoll nicht aus. Aber: Wer ist denn der Product Owner? Doch der Kunde, oder? Daher ist doch die Konsequenz, dass der Kunde (gemeinsam mit dem Team) die Planung macht und "das Produktziel" im Auge hat. Und was ist schon das Produktziel? Sprechen wir hier nicht über die Produktziele? Liefert nicht jede Story einen Wert der zu der Erreichung des Produktziels beiträgt?
These 3: Machen, was wir wollen
Der Artikel sagt:
Scrum ist keine Entschuldigung dafür, dass das Scrum-Team tun kann, was es will. Selbstverwaltung bedeutet, dass das Team intern entscheidet, wer was, wann und wie macht, innerhalb der vom Unternehmen und vom Scrum-Framework festgelegten Grenzen.
Egal ob Scrum oder andere agile Methoden: Nie macht das Team "zum Spaß" was es will. Immer verfolgt das Team Ziele. Ob die Grenzen, die Scrum setzt, gut sind für das Team, lass ich hier mal offen.
Was meint Ihr?