Der schmale Grat zwischen gut gemeint und gut gemacht.

Dieser Artikel befasst sich - anlässlich eines nun schon mehrere Wochen andauernden Streits - mit der Frage, ob der gute Wille wirklich immer zählt.

„Wir schätzen Individuen und Interaktionen mehr als Prozesse und Werkzeuge.“ Ich stimme diesem Satz aus dem Agilen Manifest uneingeschränkt zu. Tatsächlich bin ich sogar schon vor meiner ersten Scrum-Schulung von ganz allein auf den Gedanken gekommen, dass es sich hier um eine essentielle Voraussetzung für den respektvollen Umgang und die erfolgreiche Zusammenarbeit mit anderen Menschen handeln könnte.

Das trifft im Übrigen auf viele Regeln und Empfehlungen aus der agilen Softwareentwicklung zu. Es erschien mir auch schon immer recht logisch, dass ein Arbeitsergebnis besser wird, wenn man denjenigen, der einem den Auftrag gegeben hat, ab und zu fragt, ob das, was man tut, auch das ist, was er sich vorgestellt hat.

Selbst, dass der ständige Austausch von Informationen zur Wissensverteilung und Transparenz eines Vorhabens beiträgt, traf mich nicht unbedingt aus heiterem Himmel.

Auch das Erfolgsrezept der Anpassung an veränderte Umstände ist so alt wie die Welt und ich hoffe Darwins Erben kassieren für die Neuauflage dieser Erkenntnis ordentlich Tantiemen von Ken Schwaber und Jeff Sutherland.

Es scheint aber Menschen zu geben, für die es erforderlich war, all diese Grundsätze aufzuschreiben und hübsch bunt als neues Vorgehen zu verpacken. Soll mir also recht sein. Was ich hingegen nicht akzeptiere, ist die uferlose Übertreibung, mit der manche Kollegen Individuen wertgeschätzt, betüddelt und lieb gehabt haben wollen.

Bitte verstehen Sie das nicht falsch: Ich mag Kekse und Kaffee bei Besprechungen, Süßigkeiten in allen Büros, eine positive Arbeitsatmosphäre, zufrieden lächelnde Menschen, und ich werde gern für gute Arbeit gelobt. Aber ich will keinen Applaus für Scheiße. Und ich weigere mich auch, dafür zu applaudieren.

In einem nun schon mehrere Wochen andauernden Streit in unserem Projekt fordert ein Kollege ständig, die erbrachte Arbeit der Umsetzungsteams müsste mehr in den Vordergrund gerückt werden. Die Wertschätzung der Individuen und ihrer Leistung komme im Tagesgeschäft viel zu kurz. Außerdem könne es doch nicht sein, dass im Sprint Review Fehler aufgedeckt werden, die die Abnahme einer User Story verhindern. Und überhaupt sollte es im Review Getränke und Essen geben, wir müssten regelmäßig Pausen machen und verhindern, dass Anspannung bei den Teams entsteht. Insbesondere sein Team leide darunter sehr.

Ich weiß nicht so recht, was der Mann von mir will. (Mal ganz abgesehen davon, dass dieses Team auch sehr unter der Klimaerwärmung und dem Auseinanderdriften der Kontinente leidet.) Ich will auch nicht, dass die Teams im Review Glasscherben kauen, auf Nagelbrettern sitzen und Angst haben, geköpft zu werden, falls eine User Story nicht perfekt ist. Aber deshalb muss ich sie nicht auf Rosenblätter betten, ihnen Luft zufächeln und so tun, als wäre alles, was sie tun, brillant.

Ich finde es schade, wenn bei der Präsentation eines Ergebnisses im Sprint-Review genau die Seite gezeigt wird, auf der dick und fett steht: „Offener Punkt! Bitte bis zum Review noch klären“. Aber so ist das nun mal. Nicht akzeptiert! Aufstehen, Krönchen richten, im nächsten Sprint zu Ende machen.

Keiner hier arbeitet aus purem Spaß an der Freude, sondern weil er dafür bezahlt wird. Und mal ganz ehrlich: Wir sind doch nicht im Kindergarten. „Das ist ein gaaaanz tolles Bild, Michelle! Das hast du fein gemacht. Noch schöner wäre es halt gewesen, wenn du es nicht mit Edding auf Mamas Mahagonitisch gemalt hättest.“

Tatsächlich zeigt die Erfahrung, dass die Aufweichung der Erfüllung von Kriterien aus der Definition of Done dazu führt, dass nicht nur die Qualität des Produktes, sondern auch der Qualitätsanspruch unserer Teams sinkt. Die Abnahme nicht fertiger Stories fördert den Pfusch bei ihrer Bearbeitung und führt zu Frust bei parallel arbeitenden Teams, die alles dafür tun, eine User Story in bestmöglicher Qualität und fertig abzuliefern. Deshalb steht es für mich nicht zur Debatte, dass wir mal vier Augen zu drücken, wenn eine User Story nicht zu 100% fertig ist. Auch nicht, wenn die geleisteten 98% großartig sind.

Das gilt im Übrigen nicht nur für unsere Umsetzungsteams. Soll ein Backlog-Item „ready“ gesetzt werden, hat es gewissen Ansprüchen zu genügen. Tut es das nicht, wird es an den Ersteller zurückgegeben und kann im nächsten Backlog-Refinement erneut vorgestellt werden. Das Einfordern dieser Qualität ist ein geschütztes Recht unserer Umsetzungsteams. Dass sie davon oft keinen Gebrauch machen, bedeutet nicht, dass wir um des lieben Friedens willen Mittelmäßigkeit zum Standard erheben.

Zu mir hat mal jemand gesagt: „Wir haben alle Rechte und Pflichten. Man kann sich nicht eins davon aussuchen und hoffen, dass der Rest von alleine gut wird.“ Und ich fürchte, genau da liegt das eigentliche Problem.

Meine Aufgabe ist es nicht, Teammitgliedern das unberechtigte aber wohlige Gefühl zu geben, alles wäre gut. Meine Aufgabe ist es, sie dazu zu bringen, den höchsten Maßstab, der im Projekt angesetzt wird, zu ihrem eigenen zu machen, seine Einhaltung mit allen Rechten von anderen einzufordern und mit der Erfüllung all ihrer Pflichten dafür einstehen zu wollen.

So geht Wertschöpfung, so geht Team und so geht Qualität.

Sollte im Agilen Manifest irgendwann mal stehen „Wir schätzen gut gemeinte Tätigkeiten mehr als hohe Qualität“, werde ich mich gerne bei meinem Kollegen entschuldigen.