Versprochen ist versprochen

von | 24.01.2020 | Projektfalle der Woche

„Versprochen ist versprochen, und wird nicht gebrochen.“ Diesen Satz kennen Sie bestimmt, wenn Sie Kinder haben. Dazu wird die Hand gereicht und im Takt beim Sprechen geschüttelt, sozusagen als magische Versiegelung des Versprechens.

Jede Zusage, jeder Liefertermin ist ein Versprechen

Manchmal frage ich mich, ob wir nicht im täglichen Miteinander im Team auch mehr Bewusstsein für solche magischen Bindungen brauchen. Jede Zusage, jede übernommene Aufgabe, jeder Liefertermin ist ja nichts anderes als ein Versprechen. Ob wohl so viele Termine gerissen würden, wenn sich die Zusagenden immer mit dem Satz aus der Kindheit „versprochen ist versprochen, und wird nicht gebrochen“ einlassen müssten?

Beispiel Aufwandsschätzung

Ein Beispiel aus einem Kundenprojekt: Der Provider gibt Schätzungen für übergebene Anforderungen ab. Die Implementierung dauert 2 Tage auf der Entwicklungsumgebung. Es wird ein Design-Dokument erstellt, es gibt ein Meeting, um Fragen zur Anforderung zu klären, es werden Rückfragen beantwortet. Die User Story wird eingeplant und soll im aktuellen Sprint entwickelt werden. Die Daily Scrums laufen gut, alles ist im grünen Bereich. Zwei Tage vor Sprint-Ende gibt es Rückfragen zur Anforderung. Die abgestimmte Lösung wirft Fragen auf, zusätzliche Komplexität kommt hinzu. Kann ja mal vorkommen. Die Fragen werden beantwortet, der Kunde wundert sich nur über das Timing der Fragen und erkundigt sich, ob denn dann die User Story noch umgesetzt werden kann.

Schafft Ihr die Umsetzung noch?

Ja, auf jeden Fall! Sie erinnern sich – versprochen ist versprochen, und wird nicht gebrochen. Wir tragen das alle in uns, dass wir uns auf die Zusagen unserer Mitmenschen verlassen. Vor allem wenn wir nachfragen, signalisieren wir ja schon, dass wir verstanden haben: Es könnte eng werden. Das Versprechen könnte vielleicht nicht eingehalten werden. Und wenn wir dann wieder eine Zusage bekommen, dann wollen wir uns auch verlassen können. Denn sonst nimmt unser Vertrauen in die andere Person einen empfindlichen Schaden.

Der Kunde wundert sich irgendwann nicht mehr

Am Tag vor Sprint-Ende bittet der Provider darum, die User Story aufzuteilen. Den ersten Teil könne man in diesem Sprint liefern, die Vervollständigung dann im nächsten Sprint. Am Vortag hätte man festgestellt, dass die Umsetzung noch weitere, aufwändige Änderungen in einem anderen Modul nach sich zieht. Dazu müsse man sich auch nochmal mit dem Kunden beraten, denn hier muss ins Grunddesign einer Schnittstelle zum weiterführenden System eingegriffen werden. Das muss erstmal übergreifend abgestimmt werden. Voraussichtlich wird diese Änderung größer als die ursprüngliche Gesamtschätzung.

Der Kunde wundert sich jetzt erheblich, denn schliesslich gab es aus seiner Sicht hinreichend Vorbereitung für das Design dieser Anforderung. Oder wofür waren die ganzen Abstimmungsmeetings und die Abnahme des Design-Dokumentes und die Rückfragen da? Mit der Abgabe der Schätzung und der Bestätigung „Ja, wir schaffen das“ ein paar Tage vor Sprint-Ende hat der Provider Verbindlichkeit geschaffen. Eine Verbindlichkeit, die er jetzt nicht einhalten kann.

Wenn dieses Szenario häufiger vorkommt, wundert sich der Kunde bald nicht mehr. Er ist frustriert und fragt sich, auf welche Aussagen des Providers er sich überhaupt noch verlassen kann. Das Vertrauen unserer Kunden ist wertvoll. Wir sollten sorgsam damit umgehen.