Das Team tat genau das, worum es gebeten worden war.

Was uns gesagt wurde

Eine Entwicklungsorganisation kämpfte mit ihrer Produktivität.

Die Arbeit dauerte länger als erwartet. Features erreichten die Review-Phase, wurden aber nicht abgenommen. Releases verzögerten sich.

Aus Sicht des Produkts schien die Erklärung naheliegend: Das Entwicklungsteam lieferte nicht durchgängig das, worum gebeten worden war.

Wenn diese Erklärung zutraf, war die naheliegende Stelle zur Untersuchung die Entwicklungsproduktivität.

Was wir beobachtet haben

Das Team arbeitete iterativ.

Vor der Umsetzung wurde eine Story besprochen und das erwartete Verhalten definiert. Das Entwicklungsteam setzte dieses Verhalten dann während des Sprints um.

Die Entwickler ignorierten diese Anforderungen nicht.

Sie setzten sie um.

Das Problem trat erst später auf.

Während der Review wurde manchmal Verhalten notwendig, das nicht Teil der vereinbarten Abnahmekriterien gewesen war, damit die Arbeit abgenommen wurde.

Eine Story konnte beispielsweise einen bestimmten Ablauf für einen bestimmten Vorgang definieren.

Zum Zeitpunkt der Review konnte eine zusätzliche Bedingung eingeführt werden: Unter bestimmten Umständen solle ein Teil dieses Ablaufs automatisch übersprungen werden.

In einem anderen Fall legte das vereinbarte Verhalten fest, wie das System einen Nutzer informieren sollte, wenn ein Vorgang fehlschlug.

Zum Zeitpunkt der Review konnte die Erwartung entstehen, dass sich das System selbst vom Fehler erholen sollte, ohne dass der Nutzer eingreifen musste.

In einem weiteren Fall erfüllte eine Vorschau-Funktion zunächst die vereinbarten Kriterien – bis während der Review zusätzlich eine Bearbeitungsfunktion notwendig wurde.

Jede einzelne Anforderung für sich konnte vernünftig sein.

Das war nicht das Problem.

Das Muster

Die neuen Erwartungen wurden nicht als Änderungen der Spezifikation behandelt.

Sie wurden als Beleg dafür gewertet, dass das Entwicklungsteam die ursprüngliche Spezifikation nicht korrekt umgesetzt hatte.

Diese Unterscheidung veränderte alles.

Aus Sicht des Product Owners war das angeforderte Feature nicht fertiggestellt.

Aus Sicht des Entwicklungsteams waren die vereinbarten Abnahmekriterien umgesetzt worden – und neue Anforderungen tauchten erst nach der Umsetzung auf.

Die Organisation bezeichnete die daraus resultierende Verzögerung als schlechte Entwicklungsproduktivität.

Doch der beobachtbare Ablauf der Arbeit war ein anderer:

1. Abnahmekriterien wurden vereinbart.
2. Das Entwicklungsteam setzte sie um.
3. Während der Review tauchten neue Erwartungen auf.
4. Die neuen Erwartungen wurden nicht als Änderungen eingestuft.
5. Die ursprüngliche Umsetzung galt daher als unvollständig.
6. Die zusätzliche Arbeit verlängerte die Lieferzeit.
7. Die Verzögerung wurde der Entwicklungsproduktivität zugeschrieben.

Unsere Hypothese

Das Entwicklungsteam litt nicht in erster Linie unter einem Produktivitätsproblem.

Das System, mit dem bestimmt wurde, ob die Arbeit vollständig war, war instabil.

Das Team konnte die zu Beginn der Umsetzung geltenden Abnahmekriterien erfüllen und die Review trotzdem nicht bestehen, weil sich die tatsächlich geltenden Kriterien bis zur Bewertung der Arbeit verändert hatten.

Das erzeugt ein Produktivitätsproblem, das sich besonders schwer lösen lässt.

Eine höhere Programmiergeschwindigkeit löst es nicht.

Bessere Werkzeuge lösen es nicht.

Entwickler zu bitten, genauer zu schätzen, löst es nicht.

Selbst ein deutlich schnelleres Team würde nur früher an einem sich verschiebenden Ziel ankommen.

Warum das Problem schwer zu erkennen war

Niemand musste unehrlich sein, damit dieses System entstand.

Der Product Owner konnte tatsächlich glauben, dass das zusätzliche Verhalten offensichtlich Teil dessen war, was ursprünglich angefragt worden war.

Die Entwickler konnten tatsächlich glauben, genau das umgesetzt zu haben, was vereinbart worden war.

Beide Aussagen konnten das jeweilige Verständnis der Beteiligten korrekt wiedergeben.

Keine der beiden Aussagen beschrieb für sich genommen, was mit der Arbeit tatsächlich geschah.

Wir mussten also nicht entscheiden, wessen Interpretation richtig war.

Wir verglichen die vor der Umsetzung geltenden Abnahmekriterien mit den während der Review angelegten Erwartungen.

Der Unterschied war beobachtbar.

Was die Belege zeigten

Das gemeldete Problem war eine geringe Entwicklungsproduktivität.

Das beobachtete Problem war, dass sich die Bedingungen für die Abnahme fertiger Arbeit ändern konnten, nachdem die Arbeit bereits umgesetzt worden war.

Dadurch konnte Arbeit, die der vereinbarten Spezifikation entsprach, trotzdem als unvollständig eingestuft werden.

Das Team wurde an Anforderungen gemessen, die zu Beginn der Arbeit nicht zwangsläufig existiert hatten.

Das bedeutete, dass sich das scheinbare Produktivitätsproblem nicht allein durch die Optimierung der Entwickler lösen ließ.

Die Entwickler verfehlten nicht die Abnahmekriterien. Die Abnahmekriterien verschoben sich, nachdem die Arbeit erledigt war.

Die Sichtweise von Pulsar

Hätten wir die ursprüngliche Diagnose akzeptiert, hätten wir damit begonnen zu fragen, wie sich das Entwicklungsteam beschleunigen ließe.

Stattdessen verfolgten wir die Arbeit von der Vereinbarung über die Umsetzung bis zur Review.

Der Unterschied zwischen dem, was die Organisation als Problem bezeichnete, und dem, was uns die Arbeit selbst zeigte, war das aufschlussreiche Signal.

Das benannte Problem war die Entwicklungsproduktivität. Das beobachtbare Problem lag woanders.