Das Wesen von Scrum: Es ist ein Werkzeug; es geht nicht um Liebe oder Hass

In Kürze: Das Wesen von Scrum: Es ist ein Werkzeug

Regelmäßig erscheinen Artikel von Entwicklern, in denen detailliert dargelegt wird, warum „Agile“ im Allgemeinen und das Wesen von Scrum im Besonderen unsere kollektive Geringschätzung verdienen.

Was mir in dieser Diskussion immer aufgefallen ist, ist die Emotionalität der Beteiligten. Tatsache ist, dass Scrum ein Werkzeug ist, das nützlich ist, um eine primäre Aufgabe zu erfüllen: den Kunden von neuen, in komplexen Umgebungen entstehenden Produkten einen Mehrwert zu bieten und gleichzeitig die Risikoexposition eines Unternehmens zu mindern.

Wenn also Scrum in einer Organisation nicht funktioniert, liegt das vielleicht daran, dass Scrum von vornherein auf die falsche Situation angewendet wird. Oder, dass es mechanisch umgesetzt wird, angetrieben von Leuten, die nicht wissen, was sie tun. (Im Ernst, wie kompliziert kann Scrum schon sein, wenn das Handbuch 18 Seiten umfasst?)

Die Frage lautet daher: Warum sollte ich ein Werkzeug „hassen“, das für den beabsichtigten Zweck ungeeignet ist oder inkompetent angewendet wird? Würde ich einen Hammer dafür verabscheuen, dass dieser nicht in der Lage ist, eine Schraube präzise in einen Holzbalken zu drehen? Wahrscheinlich nicht, denn der Hammer wurde nicht für diesen Zweck konstruiert, und weder die bloße Willenskraft noch Aufstampfen mit den Füßen werden daran etwas ändern.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 34.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Die Aufmerksamkeitsökonomie von Hacker News und DZone

Haben Sie als Autor schon einmal davon geträumt, bei Hacker News oder DZone groß rauszukommen?

Das ist einfach; lassen Sie mich Ihnen helfen: Schreiben Sie etwas darüber, wie schrecklich „Agile“ und das Wesen von Scrum sind. Diese starren Methodologien verwandeln Softwareentwickler unweigerlich in hirnlose Rädchen in einer Unternehmensmaschine, die immer mehr Code produziert, und ignorieren dabei das wahre Potenzial dieser Wissensarbeiter. Finden Sie dann eine eingängige Überschrift wie „Warum ich [Agile, Scrum, …] [hasse, verachte…],“ und die Zuspruch der Entwicklergemeinde ist Ihnen sicher.

In einem kürzlich erschienenen Artikel über das Wesen von Scrum beschreibt der Autor seine Erfahrungen mit „Scrum“ im Detail. Werfen wir einen Blick auf einige der Aussagen des Autors:

• Definition of Done: “I entirely agree that every task should have a definition of done. But the definition should be task related […] Figuring out ‘Done’ is also difficult because the client may not have a good idea of what done looks like.” Die „Definition of Done“ in Scrum dient nicht nur der Qualitätskontrolle. Die Definition of Done ist der Qualitätsstandard, der für alle Produktinkremente gilt. Sie wird von allen, die Inkremente inspizieren, gut verstanden und bildet so die Grundlage, dass Scrums empirischer Prozess funktioniert. Sie umfasst alles, was notwendig ist, um die Produktinkremente an unsere Kunden auszuliefern, einschließlich, aber nicht beschränkt auf die Einhaltung technischer Standards, Governance-Regeln und rechtlicher Anforderungen. In Anbetracht dieser Eigenschaften erwartet niemand, dass die Kunden ein vollständiges Verständnis davon haben, was „Done“ bedeutet. Aus diesem Grund bezahlen wir auch das Entwicklungsteam dafür, dass es die Verantwortung übernimmt, ein „Done“ Produktinkrement zu entwickeln.
• Time-Boxing und Releases: “When things are done, they are done. And you should be able to ship with the done feature at any time. Waiting for the end of a sprint and a sprint review means waiting to ship a done project.” Die Aussage ist schlichtweg falsch. Die Entscheidung, ob ein Produktinkrement ausgeliefert wird, obliegt dem Product Owner. Ein Inkrement kann am Ende des Sprints geliefert werden, oder seine Lieferung erfolgt zu einem späteren Zeitpunkt. Oder das Entwicklungsteam liefert während des Sprints kontinuierlich Inkremente aus. Zu keinem Zeitpunkt hängt die Lieferung eines Produktinkrements vom Sprint Review ab, da es sich bei diesem Ereignis nicht um eine Stage-Gate®-ähnliche Genehmigungsinstanz handelt.
• Scrum Master: “What the Scrum Master really is is the project manager stripped of the ability to manage the project. […] But there are times when something needs to be done and a project manager can make the changes and get it done.” Scrum stützt sich auf selbstorganisierende und funktionsübergreifende Teams, die darüber entscheiden, wie wertvolle Produktinkremente erstellt werden können. Die Aufgabe des Scrum-Masters ist es daher, das Scrum-Team bei der Beseitigung von Hindernissen — Probleme, die die Teammitglieder nicht selbst lösen können — zu unterstützen und damit diesen dezentralen Führungsansatz zu fördern. Darüber hinaus sind diese Hindernisse meist innerhalb der Organisation angesiedelt. Hier geschieht Veränderung nicht einfach dadurch, dass man „die Dinge zum Laufen bringt“, sondern durch die Zusammenarbeit mit anderen Beteiligten und ihren Plänen, Agenden, Zielen usw. Diese Notwendigkeit ist auch der Grund dafür, dass ein Scrum Master eine Vollzeitbeschäftigung ist. Scrum-Master werden nicht dafür bezahlt, ein paar Scrum-Events zu moderieren, Stickies zu bestellen und Besprechungsräume zu buchen. Ihre primäre Rolle ist die eines Change Agents innerhalb der Organisation.
• Scrum-Events: “While I like the basic concepts, I don’t like the huge time sync associated with these events. I don’t like meetings and I like non-productive meeting even less.” Wenn Sie nicht wissen, wohin Sie gehen wollen, wird Sie jeder Weg dorthin führen. Da wir an neuen Produkten in komplexen Umgebungen arbeiten, ist es sinnvoll, regelmäßig etwas Zeit einzuplanen, um herauszufinden, ob wir in die richtige Richtung laufen. Alle Scrum-Events haben zudem Zeit-Boxen, um das Risiko zu verringern, dass wir die Zeit aller Beteiligten vergeuden, ohne einen Mehrwert für unsere Kunden zu schaffen. Niemand erwartet, dass Ihre Scrum-Ereignisse vom ersten Sprint an effektiv verlaufen. Es wird einige Zeit dauern, sie richtig zu gestalten. Glücklicherweise haben wir auch eine formelle Veranstaltung, um das Streben des Scrum Teams nach kontinuierlicher Verbesserung zu unterstützen, die Retrospektive. Dies bedeutet ebenfalls, dass wir nicht darauf warten müssen, dass die Sprint-Retrospektive beginnt, um die Dinge zum Besseren zu verändern. Mein Tipp: einfach machen.
• Das Scrum Team: “I believe in individual effort and that individuals should get credit for their efforts. […] I also reject the concept that every team member should have an equal vote on everything.” Spoileralarm: Scrum ist nicht für jedermann; Helden und Rockstars — ob selbst ernannt oder nicht — werden wahrscheinlich enttäuscht sein. Das Wesen von Scrum betont die Bedeutung „echter“ Teams, da das Team die Verantwortung für die Schaffung eines wertvollen Produktinkrements mit der Regelmäßigkeit eines Schweizer Uhrwerks übernehmen muss. Eine Vielfalt von Erfahrungen, Hintergründen und Meinungen wird die erforderliche Selbstorganisation unterstützen und in dieser Hinsicht überlegene Ergebnisse liefern. Denken Sie schließlich an das Sprichwort: Wenn Sie Feuerwehrleute belohnen, schaffen Sie eine Kultur der Brandstifter. Raten Sie mal, woher das toxische Miteinander in manchen Entwicklungsabteilungen kommt?
• Scrum ist kein Team-Player: “In the Scaled Agile Framework (SAFe), you get to the time boxed scrum teams by having an ‘Architectural Runway’ filled with ‘enablers.’ Scrum ist Scrum; SAFe® ist SAFe®. Bitte verwechseln Sie die beiden nicht, denn Scrum hat nichts mit SAFe® zu tun. Für eine erfolgreiche Zusammenarbeit mehrerer Scrum-Teams bieten sowohl NEXUS als auch LeSS die entsprechenden Framework-Erweiterungen zum Scrum-Guide an. Natürlich ist es möglich, neue Produkte zu entwickeln, an denen mehr als ein Scrum-Team arbeitet, es sei denn, Sie entfernen kritische Komponenten der Zusammenarbeit und Selbstorganisation. Wie Ron Jeffries es so wortgewandt formuliert: “We Tried Baseball and It Didn’t Work.”
• User Stories: “I’m not even going there. Here is a smattering of why user stories aren’t the be-all and end-all.” Wenn nichts mehr hilft, einfach mal das Handbuch lesen. Bitte weisen Sie mich darauf hin, wo im Scrum-Guide User Stories erwähnt werden. Wenn Sie diese gerne anwenden möchten, und es funktioniert, gut für Sie. Es gibt jedoch auch andere Möglichkeiten, mit Product Backlog Items zu organisieren, zum Beispiel Job Stories. Setzen Sie alles ein, was zu einem umsetzbaren, wertvollen Product Backlog führt, um Werte für die Kunden zu schaffen.
• Working Software: “Scrum is based around dropping working software every two weeks. […] But the real problem I have with the working software model is that it gives short-shrift to planning and documentation. […] o you have two weeks to do planning then you can forget about that drudgery. And after that two weeks, don’t plan or document, just code, code, code.” Der Autor argumentiert, dass die Konzentration von Scrum auf funktionierende Software zu schlechten Design-Entscheidungen, minderwertiger Code-Qualität und mangelnder Dokumentation führt. Meiner Erfahrung nach geschieht dies nur in Umgebungen mit schlechten technischen Standards und würde wahrscheinlich so oder so passieren, unabhängig vom verwendeten Entwicklungsframework oder dem Wesen von Scrum. Der Erfolg von Scrum hängt von einer starken Softwareentwicklungskultur und von Teams ab, die nach handwerklichem Können streben, was der Grund dafür ist, dass z. B. Scrum und Extreme Programming so gut zusammenarbeiten. Wenn TDD, Refactoring und emergent Architecture auf einen kontinuierlichen Verfeinerungsprozess des Product Backlog treffen, wird keines der zuvor erwähnten Probleme auftreten.

Cannot see the form?
Please click here

Das Wesen von Scrum: Es ist ein Werkzeug — das Fazit

Bei der agilen Software-Entwicklung geht es nicht darum, den ganzen Tag lang (Code-)Rätsel zu lösen. Als Teil der Entwicklung neuer Produkte in komplexen Umgebungen geht es zunächst einmal darum, herauszufinden, welche Probleme aus Kundensicht lösungswürdig sind. Sobald dies feststeht, und der empirische Ansatz von Scrum in dieser Hinsicht als hilfreich erwiesen, bemühen wir uns, diese „Rätsel“ mit so wenig Code wie möglich zu lösen. Wie es im Manifest der agilen Softwareentwicklung klar zum Ausdruck kommt: “Simplicity—the art of maximizing the amount of work not done—is essential.”

Um das Wesen von Scrum besser zu verstehen, gestatten Sie mir eine Anleihe bei Churchills Zitat zur Demokratie: ‘Many forms of Government software development have been tried, and will be tried in this world of sin and woe. No one pretends that democracy Scrum is perfect or all-wise. Indeed it has been said that democracy Scrum is the worst form of Government software development except for all those other forms that have been tried from time to time.’

Welche Erfahrungen haben Sie mit dem Wesen von Scrum gemacht? Bitte teilen Sie uns diese in den Kommentaren mit.

✋ Nicht versäumen: Lernen Sie mehr über das Wesen von Scrum im 7.900-köpfigen „Hands-on Agile“ Slack Team

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Weitere Artikel

Folgende Artikel könnten weitere Einblicke in das Wesen von Scrum ermöglichen:

Agile Failure Patterns In Organizations

Why Engineers Despise Agile

Scrum Master Fehlverhalten — 20 Hilferufe von Scrum Mastern.

Download the Scrum Anti-Patterns Guide: 160-plus ways to improve your way of Scrum.

📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.

Tags: Entwicklungsteam, Scrum Anti-Muster, Scrum Anti-Patterns, Scrum First Principles