Geschafft durch schaffen müssen

Wenn ich auf eine Phrase in Softwareteams allergisch reagiere, dann ist es "Das müssen wir bis zum Termin schaffen!" Die wird immer mit großer Ernsthaftigkeit und oft mit Angst ausgesprochen. Ein Hauch von heiliger Alternativlosigkeit weht durch den Raum.

Ich kann das einfach nicht mehr hören.

Diese Phrase, nein, das Glaubenssystem dahinter, macht so viel kaputt. Und selbst im Scrum Guide steht das "Schaffen müssen" noch drin: "The Development Team works to forecast the functionality that will be developed during the Sprint." Das verräterische Wort ist "forecast". Und in "the Product Backlog items it will deliver in the Sprint" ist es "will deliver".

Es ist zum Weinen.

Warum wird ständig und allerorten so viel Druck aufgebaut? Wem dient das? Ist das nötig? Ja, wirklich? Für wen? Damit etwas geschaffen wird? Quatsch! Damit die bestmögliche Qualität erreicht wird? Quatsch!

Das ist pure "working hard" Mentalität. Zum Kotzen!

"Hard working" ist ü-ber-haupt keine Adelung. Hart Arbeiten ist das Allereinfachste überhaupt. Das kann jeder Depp.

Wir brauchen nicht hart arbeitende Entwickler, Tester, Product Owner, Manager, Geschäftsführer. Wer damit kokettiert, er würde hart arbeiten, bekommt von mir im besten Fall einen bedauernden Blick (hm, vielleicht will er den ja?), eher jedoch ein Gähnen.

Working smart

Wie wäre es denn zur Abwechselung mal mit "working smart"? Also geschmeidig, reibungslos, effizient, flott, energiesparend, nachhaltig, clever usw.

Statt mit dem Kopf immer wieder gegen die Wand zu rennen, lieber mal die Tür nehmen. Könnte Kopfschmerzen vermeiden, oder?

Mit Druck, mit harter Arbeit schafft man nicht besonders viel in der Sache; vor allem nimmt man gern Abkürzungen, um doch nicht so hart arbeiten zu müssen. Das bedeutet, Qualitätsmängel sind gerade bei harter Arbeit unvermeidlich. Harte Arbeit führt also direkt in die Verschwendung. Verschwendung reduziert die meist ohnehin knappen Kapazitäten weiter, so dass noch mehr harte Arbeit alternativlos erscheint. Ein Teufelskreis!

Das verlässlichste Ergebnis harter Arbeit sind... geschaffte Arbeiter.

Was für ein Irrsinn!

Erstes Kennzeichen harter Arbeit ist der Termin. Bis dahin muss geschafft werden. Oft zu viel, wenn man all die anderen Aufgaben auch noch berücksichtigt, die ebenfalls anliegen und geschafft werden müssen.

Reflexion ist smart

Erstes Kennzeichen smarter Arbeit hingegen ist die Reflexion. Smarte Arbeiter halten immer wieder inne und fragen sich, wie sie gearbeitet haben. Haben sie ihrem Ideal energiesparender, flüssiger, hochqualitativer, verlässlicher Arbeit entsprochen? Wenn nein, dann verändern smarte Arbeiter ihre Arbeitsweise.

In Scrum steckt solche Smartness auch drin: in der Retrospektive. Sehr löblich!

Aber was soll das mit der Vorhersage (forecast) im Sprint Planning?

Hier mein Gegenvorschlag: Fokus auf Priorisierung.

Wenn im Sprint Planning alle gemeinsam einfach nur auf das Backlog schauen, um mit ihrem Verständnis von Wert und Aufwand Einträge in eine Reihenfolge zu bringen, dann ist das hilfreich. Damit wird die Arbeit im Sprint fokussiert. Zu jedem Zeitpunkt steht fest, was als nächstes getan werden sollten, wenn Kapazität frei geworden ist.

Wenn die priorisierte Liste von oben nach unten angegangen wird, dann wird im Sprint erstens immer so viel geschafft, wie überhaupt schaffbar ist (Aspekt Aufwand). Zweitens macht der Sprint dann den Produkt Owner so glücklich, wie überhaupt schaffbar ist (Aspekt Wert).

Reflektierendes Sprinten

Der Sprint ist dann vor allem eine Reflexionseinheit:

• Periodisch wird über die Priorisierung nachgedacht: es werden die Bewegungen in der Umwelt in Bezug zu dem gesetzt, was noch realisiert werden soll.
• Periodisch wird über die Arbeitsweise nachgedacht: es werden die Bewegungen im Team während der Umsetzung in Bezug gesetzt zu dem, wie die Idealvorstellung von einer Arbeitsweise aussieht.

Der Fokus ist damit weg vom Termin, vom "schaffen müssen". Der Druck ist raus. Entwickler sind nicht mehr geschafft. Die Qualität hat Raum, sich zu entfalten.

Bei dieser Arbeitsweise ist es sogar egal, wie oft das Backlog umpriorisiert wird. Vorbehaltlich technischer Gründe und Abhängigkeiten zwischen Backlogeinträgen kann die Priorität auch täglich wechseln. Wenn das dazu beiträgt, dass möglichst viel Wert im Zeitraum eines Sprints auf die Straße gebracht wird, warum nicht?

Softwareproduktion fließt wahrlich, wenn ständig der Nutzen der Software steigt: jeden Tag soll es möglich sein, ein wertvolles Release aus dem steten Featurestrom abzuschöpfen.

Produktionskadenzen sind da nicht hilfreich. Oder haben Sie schonmal davon gehört, dass ein Autohersteller ein Band in 4 Wochen Rhythmen laufen lässt? Nein, die Produktion ist kontinuierlich.

Allerdings: Für die Reflexion (!) ist eine Kadenz nützlich. Denn Reflexion ist streng genommen eine Form von Verschwendnung im Sinne einer Lean Production (eine Zunahme von Reflexion ist nicht per se wünschenswert). Daher sollte sie nur dosiert eingesetzt werden – allerdings auf der anderen Seite eben auch überhaupt. Eine Taktung ist dafür hilfreich. Sonst fällt die Reflexion zu schnell unter den Tisch, was langfristig der eigentlichen Produktion schadet.

Nein, ich habe kein Mitgefühl mehr für hart Arbeiter. "Das müssen wir schaffen!" ist für mich eines der am leichtesten erkennbaren Symptome für dysfunktionale Organisationen. Da ist einfach ein starkes Organisationsego am wirken. Das ist ganz weit weg von allem, was ich für erstrebenswert halte für ein gelingendes Leben.

"Working smart": das ist das Ziel! Machen Sie sich auf den Weg!