Der Artikel von Stefan Roock thematisiert den Wandel von Scrum von einer einst begeisternden Methode zu einer oft als langweilig empfundenen Praxis in der Softwareentwicklung. Er plädiert dafür, die Ursprünge der Agilität wiederzubeleben, indem Teams direkten Kontakt zu Endkunden suchen, anstatt sich auf starre, vordefinierte Strukturen zu beschränken. Durch den Rückgriff auf den 'agilen Kernzyklus' und die Wiederbelebung von Kreativität und Dialog zwischen Kunden und Entwicklungsteam soll mehr Begeisterung und Nutzen für alle Beteiligten geschaffen werden.

1. Langweiliges vs. cooles Scrum
Stefan Roock
stefan.roock@it-agile.de
@StefanRoock
Früher war es cool, mit Scrum zu arbeiten. Heute fühlt es sich häufig langweilig und Energie-arm an. Ich habe mich gefragt, wie es dazu kommen konnte und möchte euch mitnehmen auf
eine Zeitreise, um dieses Phänomen zu ergründen.

2. Das geilste Team der Welt
Es begab sich Ende der 1990er Jahre, dass die ersten Entwicklungsteams in Deutschland mit Scrum und eXtreme Programming arbeiteten. Fragte man zu jener Zeit die Teammitglieder
nach ihrer Arbeit, sagten sie meist, sie hätten den geilsten Job der Welt. Fragte man die Kunden der Teams, so sagten sie, sie hätten das geilste Team der Welt.

3. Immerhin istes nicht mehrso schlimmwie früher.
Seitdem sind 20 Jahre vergangen und haben ihre Spuren hinterlassen. Die Antwort auf die Frage nach dem Effekt agiler Entwicklung fällt in den meisten Unternehmen heute deutlich
bescheidener aus. „Immerhin ist es nicht mehr so schlimm wie früher“ ist die häufigste Einschätzung. Dazu kommt häufig eine gewisse Resignation: „In der Realität geht es halt nicht
anders.“

4. Back
to
the roots
Wenn ich sowas höre, steigt mein Puls jedesmal ins Unermessliche. Wie kann man glauben, dass dieser fade Aufguss der ursprünglichen agilen Ideen das Bestmögliche sein soll. Wir
können soviel mehr erreichen. Wir müssen nur aufhören, die ganzen Einschränkungen, die wir uns selbst auferlegt haben, als unveränderliche Naturgesetze anzusehen. Wir müssen uns
und anderen wieder mehr zutrauen.

5. Ziel: der agile
Kernzyklus
Echte agile Teams begeistern ihre Endkunden. Dazu stehen sie im direkten Kontakt mit den Endkunden. Sie setzen nicht einfach deren Anforderungen um, sondern verstehen die
Probleme ihrer Endkunden und gestalten dazu passende Lösungen, die sie direkt an die Endkunden ausliefern.
Ich nenne das den agilen Kernzyklus.

6. Scrum als Hilfsmittel
Scrum kann dabei helfen, den agilen Kernzyklus umzusetzen. Dort, wo sich Begeisterung nicht einstellen will, hat die Scrum-Mechanik häufig die Idee des agilen Kernzyklusses in den
Hintergrund gedrängt. Da fordern Scrum Master von ihren Teams ein rituelles mit Blut unterschriebenes Commitment auf den Sprint, ohne gemeinsam darüber zu reflektieren, ob dadurch
die Endkundenbegeisterung steigt.

7. Dieser methodische Dogmatismus zeugt davon, dass die disruptiven Ideen von Agilität und auch von Scrum nicht verstanden wurden. Man versucht, die ungezügelte Energie, die Agilität
freisetzt, zu kontrollieren, zu zähmen. Anscheinend gibt es sogar Unternehmen, die sich explizit darauf spezialisiert haben, wie diese Xing-Anfrage an einen Kollegen zeigt.

8. Das erinnert mich dann doch alles sehr an die SODVo, die Selbstorganisationsdurchführungsverordnung, die am 1. April 2014 veröffentlicht wurde. Sie ersetzte mit sofortiger Wirkung die
ungezähmte Auslegung von Agilität durch klare Regeln und schuf die Grundlage für Accounability.

9. *aus einer CSPO-Schulung
In einem fernen Land erwacht aus einem Koma, unter einer Meta-Planwand ein umzertifizierter Product Owner. Sowas sollte in diesem Land auf jeden Fall verhindert werden und so
schufen die Unternehmen klare Stellenbeschreibungen für Scrum Master und Product Owner. Denn ohne sowas läge schnell das ganze Land in Scherben.

10. Mitarbeiter
Vorstand
Abgrenzung
So werden die Zuständigkeiten von Product Owner, Scrum Master und Entwicklungsteam mit viel Mühe und großer Genauigkeit festgelegt. Sonst macht nachher noch jeder, was er will.
Natürlich hat der Vorstand auf seiner Toilette bessere Handtücher als der gemeine Untertan. Eine klare Abgrenzung ist von allergrößter Wichtigkeit, damit auch ja nichts die geregelten
Bahnen verlässt.

11. Stories A-K
Stories L-Z
Epics A-K
Epics L-Z
ReleaseTrains A-F
So wird genau geregelt, dass der Product Owner für das Schreiben der User Stories zuständig ist. Mit viel Akribie erstellt er die User Stories und achtet peinlich genau auf die Einhaltung
des Satzschemas, der optimalen Formulierung der Akzeptanzkriterien und der Definition of Ready.

12. Die klaren Regelungen führen selten zu begeisterten Kunden. Es entstehen mitunter sehr seltsame Produkte, wie diese neuartigen Urinale, die sich immer häufiger auf Herren-Toiletten
finden.
Ich kann übrigens nur dringend von der Benutzung abraten. Das gibt eine Riesen-Sauerei.

13. Wir müssen uns von dem Glaubenssatz verabschieden, dass das Entwicklungsteam nur aus Kommunikationsbehinderten besteht, die man auf keinen Fall mit Endkunden sprechen lassen
kann. Es ist keineswegs die Aufgabe von Product Owner und Scrum Master das Entwicklungsteam von der bösen Außenwelt abzuschotten und die Teammitglieder zu bemuttern.

14. Spezifikation
Kontext
Details,
Fakten
Bemutternde Product Owner erstellen Spezifikationen für das Entwicklungsteam. Spezifikationen sollen vollständig, widerspruchsfrei und korrekt sein. Sie sollen das zu entwickelnde
Produkt möglichst genau beschreiben. Folgerichtig fokussieren Spezifikationen auf Details und Fakten.

15. Spezifikation
User Story
Kontext,
Emotionen
Details,
Fakten
User Stories hingegen sind Geschichten, die erzählt werden und diese Geschichten sollten im Dialog zwischen Kunden und dem Team entstehen. Auf diese Weise werden sehr viel mehr
Informationen transportiert als es mit Spezifikationen möglich ist. Der Product Owner spielt dann nicht mehr stille Post zwischen Kunden und Team, sondern konzentriert sich auf seine
Kernaufgabe: er optimiert den Produktnutzen durch Priorisierung der Produkteigenschaften.

16. das
Team
musiziert
konzipiert
So entsteht der Freiraum, den das Team braucht, um kreative Lösungen für die Probleme der Endkunden zu erschaffen. Ein agiles Team ist kein Orchester, das einer festgelegten
Choreographie folgt. Ein agiles Team gleicht vielmehr einer improvisierenden Jazz-Band.

17. ein Produkt,
ein Product Owner
Wenn also die Teams die User Stories im Dialog mit den Kunden erschaffen und der Product Owner sich auf die Priorisierung konzentriert, vereinfacht sich skalierte Entwicklung mit
mehreren Teams. Dann kann ein Product Owner das ganze Produkt verantworten und als Product Owner für mehrere Teams fungieren. Nicht ohne Grund heißt die Rolle Product Owner
und nicht Team Owner.

18. Lasst uns also die Fenster unserer eigenen Denkbeschränkungen putzen - nur so aus Neugier, was wir dann sehen. Wenn wir neugierig bleiben, werden wir Probleme nicht mehr als
Bedrohungen wahrnehmen, sondern als Lehrer. Und mit diesem Lehrmeister können wir herausfinden, wie wir Agilität in unserem Kontext zu voller Entfaltung bringen können.

19. "Wir müssen das
Unmögliche
versuchen, um das
Mögliche zu
erreichen.“ H. Hesse
VonGretWidmann(†1931),Gemeinfrei,
https://commons.wikimedia.org/w/index.php?curid=208230
Hermann Hesse schrieb einst, wir müssten das Unmögliche versuchen, um das Mögliche zu erreichen. Teams, die direkt Probleme ihrer Endkunden lösen und so die Endkunden
begeistern, mögen unmöglich erscheinen. Und trotzdem müssen wir es probieren. Ton Steine Scherben sangen: „Wir haben nichts zu verlieren, außer unserer Angst.“

20. Wo it-agile anpackt, wächst eine
Organisation, die nachweislich
Endkunden und Mitarbeiter begeistert.
it-agile