Guidelines / Spannungsfeld Sprint Überplanung lösen

Spannungsfeld Sprint-Überplanung lösen

Ursachen, warum Sprints überplant werden
Warum sind Sprint-Überplanungen so gefährlich?
Warum ist eine möglichst verlässliche Sprint-Planung bedeutsam?
Wie löst man das Spannungsfeld der Sprint-Überplanung?

Ursachen, warum Sprints überplant werden

 

Ein gut vorbereitetes Sprint Planning greift auf ein gut vorbereitetes Backlog zu, in welchem der Vorrat an Themen, den Objectives und User Stories, vorbereitet liegt und nun im Planning eingeplant wird.

Hier liegt schon die erste Ursache für eine Überplanung. Denn häufig sind die Backlog Items nicht besonders detailliert beschrieben oder enthalten beispielsweise keine Akzeptanzkriterien, um klar zu definieren, was zu „Wir sind fertig“ (Done) gehört.. Dies sind typische Ursachen dafür, dass diese Objectives eingeplant werden, aber im Laufe des Sprints Dinge zu tun sind, die man für das Thema vorher nicht durchdacht und damit bedacht hat. Es dauert somit einfach länger, das Thema zu erledigen.

Aber auch wenn all die Voraussetzungen eines gut beschriebenen Tickets erfüllt sind, schleicht sich hier schon die nächste Ursache für eine Überplanung ein. Man hat sich nicht die Zeit genommen, den für die Erledigung notwendigen Zeitbedarf möglichst realitätsnah zu schätzen.

Aus der Softwareentwicklung gibt es hier eine Vielzahl von Methoden, wie Planning Poker, T-Shirt-Größen, Storypoint-Estimation nach Fibunaci und, und, und …

Alles richtige Methoden, aber häufig doch jeweils etwas zeitaufwendig und gerade zum Anfang meist etwas zu viel. Wichtig ist zunächst einmal, überhaupt einen Wert für den angenommenen benötigten Aufwand zu fixieren, um in eine Feedbackschleife für Vorher und Nachher zu kommen. „Hat das gepasst, was ich mir vor dem Start der Arbeiten gedacht habe?“

Mit dieser Angabe kann man nun in die Sprint-Planung gehen und sieht neben den inhaltlichen Fragestellungen auch schon mal die Dimension des Aufwands.

Fehlt nur noch die Gegenseite: die Kapazität. 

Eine weitere Ursache, warum ein Sprint häufig zu voll geplant wird: Man hat sich keine Klarheit darüber verschafft, wie viel Kapazität wirklich für die Arbeiten zur Verfügung steht.

Zunächst werden fast immer die notwendigen Basiszeiten, wie Meetings, Zeiten buchen, Mails beantworten etc., ignoriert. Dies kann aber schon schnell 20–30 % der Gesamtkapazität ausmachen. Dann typische Fehler, wie das nicht Beachten von freien Tagen oder Feiertagen bei der Grundkapazität, passieren und geht so weit dass auch mal eine ganze Urlaubswoche „vergessen” wird.

Als letzte Ursache für eine Überplanung kommt nun noch das häufig fehlende Verständnis von oben, den Program oder Business Ownern, über die Folgen einer Sprint-Überplanung hinzu. Man versucht also über Forderungen und Termindruck zum einen, möglichst viele Objectives in einen Sprint zu packen (Leistungssteigerung), und geht bewusst das Risiko ein, dass nicht alles geschafft wird. Zum anderen ist gerade diese Ebene einer der Hauptverursacher von Moving Targets, die während eines Sprints natürlich die vorherige Planung sprengen, da diese Objectives on top in den Sprint „geplatzt“ kommen.

Diese vier Bereiche stellen aus unserer Erfahrung die Hauptursachen dar, warum es zu einer Überplanung von Sprints kommt.

Warum ist eine ständige Sprint-Überplanung so gefährlich?

 

Was aber passiert, wenn es regelmäßig zu Überplanungen kommt?

Aus unserer Sicht der wichtigste Punkt steckt in einer psychologischen Lernkurve für die Teams, die auf Basis einer ständigen Überplanung absolut in die falsche Richtung geht.

Durch ständige Überplanung werden die Teams quasi darauf programmiert, dass die eingeplanten Themen sowieso nicht alle geschafft werden, da man ja aus „Erfahrung“ weiß, dass viel mehr eingeplant ist, als das, was geschafft werden kann. Die Teams erlernen sprichwörtlich, dass es normal ist, die Ziele nicht zu erreichen.

Dies führt in Folge dazu, dass der guten und genauen Planung aber immer weniger Bedeutung beigemessen wird.

Die nächste Folge ist, dass die Aussagekraft, was in einem Sprint verlässlich erledigt wird, mehr und mehr schwindet .

Die Folgen sind aber gravierend.  

Zunächst in Richtung Program Owner und Business Owner: Auch diese  können lernen, dass die Themen, die in einem Sprint geplant wurden, nicht so fertiggestellt werden, wie zum Sprint Start gedacht. (Auch wenn sie teilweise wie oben beschrieben durch Moving Targets selbst Verursacher dafür sind.)

Die erste Folge ist fast immer, dass man der “Planung” nicht mehr traut und immer stärker wieder ins Micro Management wechselt (zusätzliches Weekly oder Daily, extra Reporting Termine, …) und damit zurück in den Command and Control-Modus.

Genau das, was eigentlich in einer agilen Arbeitsumgebung ja gerade zurückgefahren werden sollte, wird wieder aktiv. Denn die Wirkung vom Nutzen der Agilität entfaltet sich erst, wenn  sich die Organisation immer stärker in Richtung dezentrale Entscheidungsfindung (Decantralize Decision Making) entwickelt. Also dass Entscheidungen da eigenständig getroffen werden, wo die Fachexpertise auch sitzt. Meistens in den Teams.

Die zweite Folge ist, dass durch die Unzuverlässigkeit der Sprints, gerade bei mehreren Teams, bei denen untereinander Abhängigkeiten bestehen, auch andere Sprints ins Rutschen kommen.

Beispiel: Team A liefer sein Objective für Team C nicht wie geplant. Dadurch kann Team C nicht wie vorgesehen mit seiner Arbeit starten und muss umplanen. Da von Team C noch weitere Teams (D, E, F) abhängen, führt dies zu einer Kette von Umplanungen.

Man muss kein Mathematiker sein, um die Folgen zu erahnen. Immer mehr Folgeobjectives sind betroffen. Passiert dies quasi durch die Sprint-Überplanung mehr oder weniger regelmäßig, sind immer mehr Beteiligte damit beschäftigt, auf die ständigen Veränderungen zu reagieren.

Genau dem liegt eines der Kern-Mißverständnisse von Agilität zugrunde, Agilität mit „ständiger Beweglichkeit“ zu übersetzen.

Und so zerlegt sich das agile Arbeiten aufgrund von nicht richtig verstandenen Grundprinzipien von ganz alleine, und nach ein paar Monaten fragt niemand mehr nach den Ursachen, sondern sieht nur die Folgen: Ständig werden Ziele nicht erreicht und Objectives nicht geliefert. Ständig muss umgeplant werden. Zeit und Budget geraten außer Kontrolle.

Und in Folge wird der Nutzen von Agilität grundsätzlich infrage gestellt.

Warum ist eine möglichst verlässliche Sprint-Planung bedeutsam?

 

Kern von Agilität ist das Prinzip Timeboxing und damit ein Takt, in dem sich alle Beteiligten verlässlich „agil“ bewegen. In FAST ist dieser Takt (die Sprints) erweitert um weiter auf den Takt abgestimmte Timeboxen, wie beispielsweise die Seasons, wodurch wir in FAST von einem Rhythmus sprechen.

Dieser Rhythmus zunächst ist alles andere als beweglich, sondern man könnte ihn sogar als starr bezeichnen. Eine Sprint-Länge oder die Dauer einer Season wird festgelegt und ist dann über einen möglichst längeren Zeitraum definiert und für alle verbindlich.

Warum ist dies bedeutsam?  

Oberstes erstes Ziel ist es zunächst, in das agile System Verlässlichkeit zu implementieren. Bedeutet, dass alle Beteiligten lernen, dass das, was sie miteinander vereinbaren, auch eingehalten wird.

Das fängt bei der Verlässlichkeit für die entsprechenden Planning-Termine, sei es Sprint oder Season Planning an, die für alle Beteiligten absolut verbindliche Fix-Termine sein sollten.

Im nächsten Part geht es darum, dass ich mich als Business Owner darauf verlassen kann, dass das, was in einem Sprint geplant wurde, auch geliefert wird. Da der Zeithorizont eines Sprints nicht länger als 2–4 Wochen ist, ist diese Verlässlichkeit eigentlich gut zu erreichen.

Dies hat zur Folge, dass ich als Business Owner ebenso verlässlich in mein Umfeld und nach oben in meine Businesslinie kommunizieren kann, was im nächsten Sprint (die nächste Season) erledigt sein wird.

Gleiches gilt entsprechend auf gleicher Ebene für parallel arbeitende Teams, die von zu liefernden Objectives gegenseitig abhängig sind.

Hier wird schon deutlich: Schaffe ich es, die Timebox „Sprint“ verlässlich zu machen, kommt Ruhe ins System.

In Folge entsteht „Trust“ (Vertrauen) in die agile Methodik, da das, was versprochen wurde, regelmäßig auch geliefert wird. Alle Beteiligten können sich auf die nächste Timebox (hier der Sprint) verlassen und darauf aufbauend ihre eigenen Aktivitäten abstimmen.

Jetzt kommt Agilität ins Spiel! 

Am Sprint-Übergang kann dann „beweglich“ auf die zwischenzeitlich sich veränderten Rahmenbedingungen reagiert werden. Hier können z.B. dann auch Moving Targets eingebracht werden. Da alle Teams sich gerade sowieso in der Neuplanung des nächsten Sprints befinden, kann unmittelbar auf diese Veränderung auch dort ohne großen Mehraufwand (insbesondere Extrameetings) reagiert werden.

Dies wird von Beginn an nicht sofort funktionieren und muss „erlernt bzw. geübt“ werden. Dafür sind die gleichen Größen der Timeboxen entscheidend, da bei diesen festen Zeitgrößen die Teams schneller lernen, was in eine Timebox denn so an Objectives passt. Hierzu sind die Lernzyklen am Ende eines Sprints mit Inspect & Adapt die Ankerpunkte.

Ist die Verlässlichkeit nach ein wenig Übung gegeben, fangen die Teams an, mutiger zu werden, und nähern sich immer mehr ihren 100 % (Was ist wirklich zu schaffen?) eigenständig an. Der eigentliche Mehrwert ist aber nicht die Leistungssteigerung, sondern die Beweglichkeit, sich im agilen System weitestgehend auf die Übergänge der Timeboxen (Sprint Planning, Season Planning) zu fokussieren, weil dadurch die Kapazität zur Arbeit am Thema geschaffen und nicht durch standiges, agiles Umplanen aufgefressen wird.

Wie löst man das Spannungsfeld der Sprint-Überplanung

 

Zunächst muss das Ziel klar sein. Nämlich einen geplanten Sprint zu planen, der möglichst verlässlich das liefert, was in der Sprint-Planung für den Sprint eingeplant wurde.

Klarheit über die Inhalte schaffen 

Dies bedeutet, es muss im Planning möglichst klar sein, was zu tun ist. Bedeutet, die zu verplanenden Aufgaben, Themen, User Stories etc. sollten so gut wie möglich beschrieben und in Tickets dokumentiert sein.

Auf diese Weise werden 2 Dinge erreicht. Zum einen Klarheit, was im Thema wirklich zu tun ist. Zum anderen, welche Themen zu tun sind.

Am besten findet dieses „Klären“ schon im Vorfeld eines Sprint Planning statt, dies ist auch eine Aufgabe des Product Owners, und die Teammitglieder gehen mit klar beschriebenen Themen ins Planning. Eigentlich Scrum Basics.

In Folge gilt es nun aber, die für den Sprint verfügbare Kapazität mit dem erwarteten Aufwand für die Tickets überein zu bringen. Hierzu muss auf beiden Seiten geschätzt werden.

Klarheit über den anstehenden Aufwand schaffen 

Es gilt also, sich im Planning Zeit dafür zu nehmen, zu überlegen, wie viel Zeit für die Erledigung des jeweiligen Themas benötigt wird. Hier können die bekannten Schätzmethoden angewandt werden oder man schätzt einfach mal in Stunden drauflos.

Klarheit über die verfügbare Zeit schaffen 

Gleiches gilt im Anschluss für die zur Verfügung stehende Zeit für den Sprint und die Themen . Also nicht die gesamte Arbeitszeit, sondern abzüglich Urlaub, Routinetätigkeiten, Team-Meetings etc. Und zwar jeweils der einzelnen Teammitglieder, die an den Themen arbeiten werden.

Aufwand und Kapazität übereinanderlegen 

Beide Zahlen, also die Summe der Zeiten für die Themen und die zur Verfügung stehende Kapazität, sollten in etwa gleich groß sein.

Hier kommt es nicht auf exakte Genauigkeit an, da beide Zahlen ja sowiesogeschätzt sind. Aber wenn die Zeit-Summe der Themen doppelt so groß wie die zur Verfügung stehende Kapazität, stimmt etwas nicht. Der Sprint ist offensichtlich überplant. Es muss etwas aus dem Sprint geschoben bzw. weitere Maßnahmen ergriffen werden, z.B. größere Themen noch einmal kleiner zu schneiden und/oder Teile in den folgenden Sprint zu schieben.

Jede Schätzung ist genauer als keine Schätzung 

In jedem Fall wird man sich zu Beginn verschätzen. Und Kritiker können einwenden: „Das stimmt doch eh alles nachher nicht.“ Und zu Beginn ist dies auch richtig. Aber durch das permanente Schätzen, egal mit welcher Methode, und das auf Basis der gleich großen Timebox des Sprints, lernt man, was gepasst hat, aber vor allem auch, wo hat es nicht gepasst hat. Nach dieser Erfahrung werden die Schätzungen durch jede Fehlschätzung beim nächsten Mal besser. Der hier ablaufende Lernzyklus führt dazu, dass man sich immer mehr der Realität annähert.

Das ist iteratives Lernen in einem agilen Umfeld!
Dem Kern von Agilität.

Auf diese Weise erreicht man Stück für Stück eine immer höhere Verlässlichkeit für die Dinge, die man sich für einen Sprint vornimmt, ob diese auch machbar sind und dann in Folge auch geliefert werden.

 

Einwirkungen von außen verhindern 

Aber es gibt noch weitere Effekte, die zu einer Sprint-Überplanung führen. Auch diese gilt es, anzugehen, da sie ansonsten das Ziel der Verlässlichkeit konterkarieren.

Die erste Ursache ist in der Regel die Business-Ebene, die fordert, Dinge und Themen so schnell wie möglich umzusetzen, und daher Druck ins System gibt, von::„“Da muss noch noch mehr im Sprint gehen?“ bis „Könnt Ihr nicht das Thema noch mit aufnehmen?“ etc.

Im vorauseilenden Gehorsam lassen sich unerfahrene agile Teams allzu gerne auf dieses Spiel ein, und schon ist der Grundstein dafür gelegt, dass Verlässlichkeit nicht entstehen kann.

Also heißt es hier, der Business-Ebene zu erläutern, dass, das was die Teams planen, wirklich das ist, was zu schaffen ist, und hier die Business-Ebene nicht zu übersteuern hat.

Die zweite Ursache liegt ebenfalls auf Business-Ebene, und das sind die sogenannten Moving Targets, die allzu gerne innerhalb eines Sprints einfach mal dazu ins Team gegeben werden. Auch hier gilt, Moving Targets so weit wie möglich zu vermeiden. Denn durch die Aufnahme eines solchen Moving Target in einen laufenden Sprint, wird Kapazität verbraucht, die anschließend für die eigentlich geplanten Themen nicht mehr zur Verfügung steht. Das sollte im Grunde klar sein. ist es aber vor allem den Business Ownern häufig nicht. Hierzu der Artikel Umgang mit Moving Targets.

Verlässlichkeit erreicht – und dann? 

Ist das erste Ziel, die Sprints verlässlich zu machen, weitestgehend erreicht – was durchaus ein Weile oder auch mal mehr als nur ein paar Sprint-Zyklen dauern kann –, ist die Basis geschaffen, dass  oben in der Business-Ebene Vertrauen entsteht und sich immer weiter verfestigt: „Die liefern, was sie (im Planning) versprechen!“.

Dies gilt es, nun auf die nächsthöhere Ebene – das Season Planning – zu übertragen. Denn die Mechanismen hier sind die gleichen. Nur dass der Zeitraum nicht ein Sprint von wenigen Wochen ist, sondern ein längerer Zeitraum von 3–4 Monaten.

Hierzu werden im Season Planning weitere Elemente aktiviert, wie z.B., dass der letzte Sprint einer Season nicht beplant wird, was dem Ziel der Verlässlichkeit dient. Hierzu der Artikel Season Planning.

Auf der Sprint-Ebene gilt es nun, ohne jedoch das Hauptziel “Verlässlichkeit” wieder aus den Augen zu verlieren, sich zu verbessern. Also daran zu arbeiten, den Output des Teams zu verbessern. Hierzu dient das agile Element der Retrospektive (kurz Retro), welche am Ende eines jeden Sprints durchgeführt werden sollte.

Hier geht es um das Wie. „Wie können wir das Schätzen des Aufwands, der für die Erledigung von Themen angenommen wird, verbessern?“ Zum Beispiel unter der Fragestellung:„Was können wir tun, um unsere freie Kapazität für die Themen zu erhöhen? Also, die sonstigen Zeiten zu optimieren?” „Wie können wir uns besser im Team organisieren, um unsere Effektivität zu steigern?“

Hier existiert eine Vielzahl von Themen, an denen nun die Teams von Sprint zu Sprint an Ihrer Optimierung arbeiten und sich so immer weiter optimieren können ..

Und hier fängt Agilität wirklich an zu leben.
Aber ohne zu rennen und vor allem ohne ständiges „agiles“ Umplanen, ohne Rhythmus.