Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

Ihr seid ja gar nicht agil!

Scrum Master kennen das. Irgendwer hat immer die Deutungshoheit gepachtet und weiß ganz genau, dass man nicht agil ist und warum. Ein kleiner rant*.

Okay, zugegeben, „rant“ ist vielleicht ein etwas starkes Wort. Sagen wir lieber ich hinterfrage zum Wochenende mal die Basis auf der diese Einschätzungen und letztendlich Urteile über die Agilität stehen.

„Ich hab das Buch gelesen und da steht drin, man muss XY machen. Das macht ihr aber nicht.“

Nun … was soll ich darauf sagen?

strictly-following-the-rules-doesnt-make-you-agile

Mal ehrlich: Zu einem funktionierenden Prozess gelangt man doch nicht indem man eine Checkliste stumpf abarbeitet. Das dann auch noch bei agilen Arbeitsweisen zu probieren … ich hoffe die Ironie ist jedem klar. Nur nochmal zur Sicherheit: Was waren die Grundsätze des agilen Manifests? Die Autoren schätzen

Individuen und Interaktionen mehr als Prozesse und Werkzeuge, Funktionierende Software mehr als umfassende Dokumentation, Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung [und] Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Individuen und ihre Interaktionen, also das Team und wie die einzelnen Teammitglieder miteinander interagieren, sind wichtiger als das Befolgen fix definierter Regeln. Auf das Team eingehen und schauen was die einzelnen Kollegen brauchen um zusammen erfolgreich zu sein ist im Zweifel wichtiger als irgendeine Maßnahme umzusetzen, nur weil sie scheinbar zum agilen Inventar gehört. Die Maßnahmen sind als best practices und Tipps zu sehen – da ist viel Praxis hinein geflossen, bitte unbedingt prüfen ob einer dieser Punkte sinnvoll angewendet werden kann. Sie sind es oft genug. Aber war es auch schon. (Achtung: das ist mehr als es klingt!)

Dieser Fokus agiler Methoden auf die qualitative Seite der Zusammenarbeit (im Abgrenzung zur formalen Seite, Stichwort: Checkliste) ist der Grund weswegen sich bspw. das agile Manifest so zurückhält mit konkreten Handlungsempfehlungen. Es geht immer um den Einzelfall, das Team mit dem man als Scrum Master zusammen arbeiten. Agile Methoden sind keine Schablone die man einfach überall drüber legt und gut. (Wer so an die Sache heran geht, der hat schon verloren.) Agile Methoden und die Werte die sie hoch halten sind vielmehr Reaktionen auf dieses Hantieren mit Schablonen und in-Form-pressen von Teams.

Schauen wir uns den obigen Satz nochmal an:

Ich hab das Buch gelesen und da steht drin, man muss XY machen. Das macht ihr aber nicht.

Das ist demnach kein Argument um einem Team Agilität zu bescheinigen oder abzusprechen. My two cents: falls jemand ums Eck kommt und sich seiner agilen Arbeitsweise rühmt, weil er / sie alles umgesetzt hat, was im Buch steht – Vorsicht!

„Euer Product Owner entscheidet gar nicht alles selbst, sondern delegiert Entscheidungen an andere Fachbereiche weiter!“

So what?! Funktionale Differenzierung ist ein wesentliches Merkmal moderner Organisation. Damit gehen – hier klopft jetzt Luhmann an die Tür – auch Schwierigkeiten einher. Keine Frage. Das Problem liegt jedoch nicht in der Tatsache begründet, dass der Product Owner andere Fachbereiche heranzieht und dadurch deren Expertise nutzt. Das Problem ist, dass damit zu oft eine übergreifende Perspektive – die auf das gesamte Produkt – verloren geht. Solange der Product Owner diese Perspektive hoch hält und die ausschnitthaften Einzelperspektiven der jeweiligen Bereiche gegeneinander abwägt und zum  Wohl des Produkts untereinander ausgleicht ist alles in Ordnung. Und solange diese Entscheidungen zeitnah ausfallen ist alles ok.

Die Schwierigkeit liegt eben darin die übergreifende Perspektive, nämlich die des Produkts, hoch zu halten. Beschränkt sich der Product Owner ausschließlich darauf Fragen und Antworten weiter zu leiten, kann es nicht klappen. Das hat aber weniger damit zu tun, dass andere Fachbereiche / Stakeholder gehört werden, sondern vielmehr damit, dass der Product Owner faktisch keiner ist.

Der Satz

Euer Product Owner entscheidet gar nicht alles selbst, sondern delegiert Entscheidungen an andere Fachbereiche weiter!

bezieht sich also weniger auf den Umstand, dass der Product Owner Entscheidungen und Expertise einholt. Sondern auf eine Situation in der ein Product Owner keine Entscheidungen trifft / herbeiführt und somit seine Rolle nicht wahrnimmt. Solange das aber der Fall ist – so what?! Big deal! Hauptsache es funktioniert (s.o.), d.h. es gibt schnelle und klare Entscheidungen und brauchbares Feedback.

Übrigens: es gibt auch Konstellationen in denen es einen Product Owner gibt, der keine Runden über andere Fachbereiche dreht, der aber trotzdem keine belastbaren Entscheidungen trifft. Der Umstand ob ein Product Owner mit / ohne Konsultation anderer Bereiche Entscheidungen trifft, ist unerheblich für die Agilität der Organisation. Wichtig ist, dass Entscheidungen getroffen werden.

Es gibt genug Hindernisse für’s agile Arbeiten, diese zu erkennen und zu beheben ist Aufgabe des gesamten Scrum Teams – im Lead ist hier der Scrum Master, der jedoch auch die anderen als Erkenntnisquellen braucht.

Von unnötigen und nicht zielführenden Diskussionen, wie sie manchmal über die oben genannten Sätze angestoßen werden, sollte man sich – um seiner selbst und der Arbeit Willen – fern halten. Die bringen nichts.

Links:

____
*rant – Schimpftirade, Wutrede

Verwandte Artikel

Schönen Samstag!