Agile Success Stories: Quartals- statt Jahresplanung

Bild: Unsplash / Chase Chappell - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Arbeitswelt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier hat auf den ersten Blick kein besonders agiles Ergebnis gehabt, schliesslich handelte es sich bei ihm um die Einführung von Quartalsplanungen. Eine Quartalsplanung - wie soll das mit den kurzen Lieferzyklen zusammenpassen, die Erkennungsmerkmal der agilen Arbeitsweisen sind? Um das zu erklären muss ich etwas ausholen, denn wie immer steckt auch hinter dieser Geschichte eine Entstehungsgeschichte, die man kennen sollte.

In der Vergangenheit hatte das Unternehmen mit dem ich zu dieser Zeit zusammengearbeitet habe einen eher klassischen Planungsansatz. Am Anfang stand die so genannte "Mifri" (die mittelfristige Finanzplanung), die jeweils für die nächsten drei Jahre die vorgesehenen Budgets festlegte, und das z.T. auf erstaunlich detailliertem Niveau. Den Budgets wurden dann für jeweils das nächste Jahr Ressourcen (also Mitarbeiter) zugeordnet. Für die ganzen zwölf Monate, ebenfalls in hohem Detailgrad.

Ob es jemals den Fall gegeben hatte, dass ein solcher Plan aufgegangen war, konnte keiner sagen. In den letzten zehn Jahren war das aber nicht der Fall gewesen, ständig liefen Plan und Realität auseinander. Zu Beginn eines Jahres wurde das versucht mit Mehrarbeit zu kompensieren, in der Mitte des Jahres gab es bürokratische Plananpassungen, ab Herbst floss ein Grossteil der Arbeit dann in Rechtfertigungen dafür, dass die Planziele nicht erreicht worden waren. So lief es jedes Jahr.

Irgendwann war der durch dieses Vorgehen erzeugte Schmerz zu gross geworden, und das Vorgehen wurde angepasst. Die mittelfristige Finanzplanung gab es zwar noch, sie wurde aber wesentlich weniger kleinteilig durchgeführt. Statt für einzelne Features waren die Budgets jetzt für Systeme oder Services vorgesehen, wodurch der Handlungsspielraum deutlich grösser wurde. In gleicher Art wurden auch die Jahresplanungen abstrahiert und vereinfacht.

Die eigentliche Planung fand ab diesem Zeitpunkt auf Quartalsbasis statt, also immer für drei Monate im Voraus. Und um zu verhindern, dass Überläufer-Themen des letzten Quartals de facto zu einer Verlängerung der Planungszyklen führten, wurden alle Aktivitäten und Prioritäten vor Planungsbeginn auf Null zurückgesetzt, so dass Restaufwände ggf. nicht mehr umgesetzt wurden. Mit der Zeit erwies sich das als wirkungsvolles Mittel gegen die bis dahin weit verbreiteten überoptimistischen Pläne.

Der so entstehende Kontrast zwischen dem alten und dem neuen Vorgehen war drastisch: vorher hatten die Pläne ab Frühling kaum noch Realitätsbezug, stattdessen flossen bemerkenswerte Aufwände in Eskalationen, bürokratische Umplanungen und Rechtfertigungen. Nach der Umstellung führten die kürzeren Planungszeiträume dazu, dass Plan und Realität ständig nah beieinanderlagen, wodurch die gerade genannten Aufwände unnötig (oder zumindest stark reduziert) wurden.

Als zusätzlichen Effekt konnte man eine deutliche Zunahme der Produktivität beobachten. Die gesamte bisher notwendige Eskalations, Umplanungs und Rechtfertigungszeit konnte jetzt für die eigentliche Arbeit verwendet werden, was zu deutlich schnelleren Umsetzungen führte. Und wenn Annahmen oder Planungen sich als unrealistisch erwiesen, belastete das nicht mehr das ganze Jahr, sondern nur die Zeit bis zur nächsten Quartalsplanung, bei der alle Pläne zurückgesetzt wurden.

Eine tatsächliche Erfolgsgeschichte also. Aber auch eine agile Erfolgsgeschichte? Wie oben gesagt, sind dafür drei Monate nicht zu lang? Statt einer eigenen Antwort darauf möchte ich die Primärquelle zitieren, das Manifest für agile Softwareentwicklung, bzw. dessen zweite Seite, die Principles behind the Agile Manifesto. Zu denen gehört nämlich auch eines, dass sich mit den anzustrebenden Umsetzungszeiträumen befasst, und das liest sich so:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Die Hervorhebung ist von mir, den Rest kann man für sich sprechen lassen.