Moin.

Macht Ihr auch „nicht Scrum by the book“? Wir auch nicht. Ihr auch nicht? Oder macht Ihr „nicht PEP by the book“? Vielleicht macht Ihr auch „nicht V-Modell by the book“ und auch „nicht Waterfall by the book“? Super, dann könnt Ihr Euch entspannen, denn Ihr seid in guter Gesellschaft. Und das wollen wir doch alle, oder? Deshalb wollen wir Best Practices. Es misst zwar niemand, was „best“ ist, aber solange ich Best Practices nutze, ist alles gut. Und „nicht XYZ by the book machen“ ist definitiv eine best practice. Zumindest, wenn ich manchen Teams unserer Kunden glaube.

Manchmal stelle ich dort Fragen, die wohl außerordentlich blöd sein müssen. Ein Beispiel: Ich sitze bei einem neuen Kunden mal wieder in einem Termin, der sich für den Preis „Tod durch Meeting“ beworben hat. Es ist endlos langweilig. Anwesend sind die Softwareentwickler eines Teams und jemand, den sie „Product Owner“ nennen. Gerade ist der letzte Sprint verendet und man betrachtet gemeinsam den Kadaver. Der PO-genannte ruft der Reihe nach die Entwickler auf. Jeder Einzelne spricht aus, was man auf dem Kanban-Board ohnehin schon sehen kann. Welche Tickets fertig sind und welche nicht. Hin und wieder noch ein Add-on der Art „es klemmt noch an der Stelle x“. Das interessiert ohnehin niemanden, weil sich jeder im „Team“ nur für die „eigenen“ Tickets interessiert. Die meisten Kameras sind aus, nur der PO-genannte, der jeweils Sprechende und der Coach, der später eine der blödesten Fragen der Welt stellen wird, haben ihre Kameras an. Jeder Entwickler, der es hinter sich gebracht hat, verschwindet schnell in der Dunkelheit der ausgeschalteten Kamera, bevor der PO-genannte den nächsten Bemitleidenswerten aufruft. Also noch eine Iteration der Langeweile; ist ja schließlich Scrum.

Irgendwann ist es vorbei und ich prüfe, ob ich körperlich unverletzt bin. So weit, so gut. Dann ergreife ich das Wort und beginne ein Gespräch über das, was wir gerade erlebt haben. Im Teamkalender trägt der Termin übrigens den Titel „Sprint-Review“. Ich frage in die Runde, ob das ein typischer Verlauf des Reviews war und wie alle Beteiligten das Meeting finden. Die, die die Kamera einschalten, lächeln, als wollten sie mir sagen: „Du hast wohl nicht alle Latten am Zaun.“ Niemand mag dieses Meeting. Jeder hasst es. Ok, denke ich, das wäre geklärt.

Ich frage vorsichtig, ob sie auch andere Formen von Reviews kennen und zücke irgendwann mal zum Antesten den Scrum Guide. Zitat: „The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation. […] The Scrum Team and stakeholders review what was accomplished […]“ Ich kann gerade noch erwähnen, dass es ja wohl keine Working Session war, was wir gerade erlebt haben, und kann fragen, wieso denn keine Stakeholder anwesend waren.

Noch bevor ich ausgeatmet habe, höre ich den PO-genannten mit einer Mischung aus leichter Verachtung und Stolz zu mir sagen: „Also, wir machen hier nicht Scrum by the book.“ Da ist sie wieder. Meine Lieblingsbeschreibung der Arbeitsweise eines Teams. Sie ist so großartig, dass sie zu jedem Unternehmen zu passen scheint. Es gibt sie in „voll vielen Geschmacksrichtungen“. Mega, sage ich Euch. Es gibt „nicht PEP by the book“, es gibt „nicht V-Modell by the book“, kurz gesagt, es gibt „nicht you name it by the book“. Wir machen unser eigenes Ding, ob’s weh tut oder nicht.

Wenn die nicht-by-the-book-Aussage kommt, genieße ich sie eine Weile. Ich frage nach vielen kleinen Absonderlichkeiten, die mir beim Kunden auffallen, und immer passt eine nicht-by-the-book-Aussage. Und immer besitzt sie diesen belehrenden, überheblichen Ton, der mir sagt: „Du hast doch keine Ahnung vom Kontext hier und kannst überhaupt nicht einschätzen, was richtig und was falsch ist.“

Natürlich endet der Spaß irgendwann. Denn so wie mir manche Leute immer wieder die verächtliche nicht-by-the-book-Antwort aufs Brot streichen, so habe ich immer noch einen Pfeil im Köcher. Er ist ganz unscheinbar. Man merkt nicht, dass er schon lange dort schlummert und nur darauf wartet, endlich abgefeuert zu werden. Doch früher oder später höre ich auf, die nächste nicht-by-the-book-Antwort zu provozieren. Dann stelle ich klar, dass ich es wirklich verstanden habe. Ich schwenke die weiße Fahne. Ich ergebe mich. „Okay, okay. Ihr macht nicht Scrum by the book.“ Und dann kommt der Pfeil, lautlos und unsichtbar: „Was macht Ihr denn?“, frage ich. Leichte Verwirrung macht sich breit.

Kunde: „Ja, wir machen hier nicht Scrum by the book.“

Stefan: „Das habe ich jetzt verstanden. Ich weiß, was Ihr nicht macht. Aber: Was macht Ihr denn?“

Kunde: „Ja. Ja….?“

Stefan: „Ihr hasst dieses Meeting und es hat keinen Sinn. Niemand braucht es. Das sind Eure Worte. Warum führt Ihr es durch?“

Kunde: „Ja, das gehört doch zu Scrum.“

Stefan: „Aber Ihr macht nicht Scrum by the book.“

Stefan: „Was macht Ihr denn?“

Natürlich gibt es keine vernünftige Antwort auf diese Frage. Das weiß ich vorher. Und jeder im Raum weiß es auch. Deshalb reicht es aus, sie so oft zu wiederholen, dass jeder die Reichweite der Frage verstanden hat. Eine darüber hinausgehende Wiederholung sollte man sich sparen. Sie richtet nur Schaden an.

Mein Punkt ist: Ich habe einige Teams in mehreren Unternehmen gesehen, die außerordentlich unzufrieden mit ihrer Arbeitsweise waren. Das kann Scrum oder etwas anderes sein. Ich verwende Scrum nur als Beispiel. Oft, wenn ich darauf hinweise, dass die jeweilige Vorgehensweise (Scrum, Wasserfall, der hauseigene Produktentwicklungsprozess etc.) eine gute Lösung im Angebot hat, verweigern diese Teams jede Hilfe mit der „wir machen hier nicht XYZ by the book„. Versuche ich jedoch, schmerzhafte, sinnlose Praktiken aus dem Arbeitsalltag zu entfernen, hält man mir vor, man müsse an den Praktiken doch wegen ebendieses Regelwerks festhalten, an das sich die Teams nach eigener Aussage nicht halten. So ist es zum Beispiel außerordentlich schwierig, nutzlose Meetings, die alle Teilnehmenden hassen, einfach aus dem Kalender zu streichen.

Mich lassen diese Beobachtungen mit einer Frage zurück, die ich hier gerne mit Euch teilen möchte: Warum wiederholen Menschen bei der Arbeit immer wieder Vorgehensweisen, die sie nicht mögen und die keine guten Ergebnisse erzielen? Und warum machen so viele dabei mit?

Gibt es so etwas auch in Eurer Arbeit? Schreibt es gerne in die Kommentare.

Erst Lesen, dann Hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.

(rme)