Seit ich mit dem Milleniumswechsel in der Software-Branche tätig bin, gibt es neben den fachlichen und technischen Problemen eine viel größere Herausforderung: den Termin. Oder auch Deadline genannt.

Darauf wird alles ausgerichtet, es werden Prioritäten abgestimmt, Entscheidungen beeinflusst, Umsetzungen gekürzt. Während am Anfang noch Ruhe im Team herrscht, wird es zum Ende hin immer hektisch. Es tauchen am Ende des Tunnels immer mehr Probleme auf, die zeitnah gelöst werden müssen. Klar – je mehr gebaut wurde, umso mehr sieht man, was noch nicht funktioniert. Das Team cruncht, hängt sich rein, versucht alle restlichen Anforderungen umzusetzen, tüftelt an den abnahmerelevanten Bugs. Kann der Termin eigehalten werden? Wird nach all der Mühe am Ende der verdiente Sieg stehen?

Wenn dies nicht klappt, kennen klassische Projekt-Verfahren wenig Erbarmen. Gerne kommt jetzt die Schuld-Frage auf. Warum lief es schief und wer hatte daran seinen Anteil? Es beginnt die Phase des Overrun Managements. Zu den zusätzlichen Restaufgaben addiert sich ein erweitertes Statuswesen dazu, welche weitere Ressourcen beansprucht. Ressourcen, die man gerade in der Phase für Wichtigeres bräuchte. Effizient an den Restaufgaben arbeiten zum Beispiel.

Aus diesen Erfahrungen vergangener Projekte ist die Denkweise nachvollziehbar, dass viele Kollegen versuchen, der Herausforderung Deadline auszuweichen oder sie gar zu verleugnen.

Die Deadline ist tot!

Mit agilen Methoden wie Scrum gibt es immer mehr Teams, die darauf hinweisen, sie können ja gar nicht mehr gegen Deadlines arbeiten, weil man nur innerhalb eines Sprint genau planen kann. Weiter in die Zukunft zu schauen wäre nicht machbar, defakto unseriös.

Der Endgegner ist ausgetrickst. Jetzt braucht nur noch geschaut werden, dass das Team selbstverantwortlich nicht zu viel Backlog Items in den den Sprint legt. Alle Sprints sind grün und die Mission erfüllt. Termine sind nur für Projekte gut und wir entwicklen sowieso nur noch an Produkten, die von Iteration zu Iteration an Kundennutzen zunehmen.

Ist dem so? Ich denke nicht. Ich würde sogar sagen:

Es lebe die Deadline!

Dazu möchte ich kurz erklären, dass dazu zwei Arten von Deadlines unterschieden werden müssen.

Es gibt zuerst die externen Deadlines. Dies sind externe, zeitliche Abhängigkeiten, zu denen Artefakte fertig gestellt sein müssen. Dies können gesetzliche Vorgaben oder Fristen sein, Messe-Termine sein, astronomische Konstellationen für die Raketentechniker unter uns (ja, auch solche Projekte gibt es). Der Vetter dieser Deadline ist das feste Budget, dass durch die Bezahlung der Projektmitarbeiter am Ende wieder zeitliches Enddatum ergibt.

Diese Termine sind fix und lassen sich nicht verschieben. Wer diese Realitäten nicht bei der Planung berücksichtigt, handelt grob fahrlässig.

Die zweite Form der Deadline ist die Hilfsdeadline. Richtig angewendet kann ein Projekt-Management (und auch ein Produkt-Management) einen zeitlichen Endpunkt festlegen, um diese positiven Effekte zu erzielen:

1. Die Fokussierung auf einen Endtermin und führt zu einer Rückwärtsplanung. Alles Unwichtige entfällt.
2. Für jede Aufgabe kann nur ein bestimmtes Maß an Zeit veranschlagt werden. Es werden effiziente Lösungen erstellt.
3. Das Team hat eine Benchmark, an der sie den Grad der seiner Geschwindigkeit messen kann.
4. Das Team steht mit sich im Wettkampf. Menschen sind von sich aus fleißig. Sie sind jedoch noch engagierter, wenn es darum geht ein Ziel bzw. Wettkampf zu gewinnen.

Wenn wir Uns Scrum anschauen, sehen wir, dass auch hier diese Hilfsdeadlines existieren: Sie sind das immer wiederkehrende Sprint-Ende. Auch das Sprint-Ende profitiert von den Vorteilen der Hilfsdeadlines. Dies sogar periodisch.

Doch wie geht man mit Deadlines um, die über die Sprint-Länge hinaus gehen? Auch hier ist Scrum als agiles Verfahren mit seinem lernenden und nachsteuernden Ansatz sehr gut, um Deadlines einzuhalten:

1. Über ein gut gefülltes und geschätztes Backlog wird der Aufwand für die Zielerreichung ermittelt
2. Das Wichtigste wird zuerst umgesetzt. Eine User Story Map kann hier helfen, das Minimalset an Stories zu definieren und als erstes anzugehen.
3. Wird die Zeit zum Ende hin knapp, kann der Umfang von Stories so geschnitten werden, dass sie wieder zum Termin passen. Da dies mit den unwichtigeren Stories passiert, ist dies weniger schlimm als bei den Hochpriorisierten vom Backlog-Start.
4. Durch periodisches Refinement des Backlogs wird laufend die Schätzungsgenauigkeit erhöht. Diskrepanzen können hier gleich mit Umfangsanpassungen oder einfacheren Umsetzungsideen ausgeglichen werden.
5. Anhand der gemessenen Velocity wird der reale Aufwand des Backlogs immer neu berechnet. Diskrepanzen können auch hier durch Umfangsanpassungen ausgeglichen werden.

Deadlines weise einsetzen

Wenn es also keine fixen Deadlines gibt, können Sie als Product Owner oder Projektleiter einfach selber Ihre Hilfsdeadlines setzen. Sie können z.B. ein Präsentationstermin vor der Geschäftsleitung oder der ganzen Abteilung ansetzen. Mit solchen Terminen können Sie die gleichen Effekte erzielen. Jedoch würde ich diese “weise” einsetzen und folgende Punkte beachten:

1. Nicht zu viele Deadline setzen. Wer ständig sprintet, hält keinen Dauerlauf durch. Außerdem besteht die Gefahr, dass diese Termine irgendwann nicht mehr ernst genommen werden.
2. Es gibt bei einer verpassten Deadline keine Schuldzuweisungen oder Vorwürfe. Seien Sie daran erinnert, dass Sie schon von den Vorteilen profitiert haben. Hier ist es an Ihnen als Product Owner, die Verantwortung zu übernehmen und sich vor das Team zu stellen
3. Feiern Sie eingehaltene Deadline! Die Deadline war vielleicht künstlich, der Einsatz und die Leistung Ihres Teams nicht. Zeigen Sie dies Ihrem und auch anderen Teams.

Bevor Sie gehen

1. Empfehlen, teilen oder liken Sie gerne diesen Beitrag, wenn etwas Nützliches für Sie dabei gewesen ist. Dies gibt mir neue “Energie”, um noch mehr für Sie zu schreiben.
2. Sie sind anderer Meinung? Jede Meinung ist willkommen und wertvoll. Teilen Sie diese mit uns und fügen Ihre Gedanken als Kommentar hinzu.