Agile Projekte sind planbar

Die agile Softwareentwicklung hat sich inzwischen fast überall durchgesetzt. Damit lassen sich die Kundenbedürfnisse optimal erfüllen. In meinem Blog-Beitrag möchte ich euch zeigen, dass agile Projekte entgegen dem Mythos der Planlosigkeit sehr wohl planbar sind und über eine verbesserte Wertschöpfung hinausgehen.

Die Herausforderung – Projektplan durch Geschäftsführung gesetzt

In vielen Unternehmen werden nicht nur strategische, sondern auch weniger wichtige Projekte durch die Geschäftsführung mit klar vorgegebenen Zielen und Terminen initiiert. Diese strikten Vorgaben stellen das Projektmanagement vor enorme Herausforderungen – insbesondere, wenn bisherige Zeitpläne häufig nicht eingehalten wurden. Ich bin auch schon einmal als Product Owner in ein Scrum-Team gekommen, bei dem der Plan für die nächsten zwei Jahre bereits durch den Vorstand vorgegeben war. Ein wesentlicher Aspekt ist daher die Entwicklung und klare Kommunikation eines realistischen Zeitplans, der den Anforderungen der Geschäftsführung ebenso gerecht wird wie den operativen Gegebenheiten.

Der Mythos, dass Agilität keinen Plan hat

Ein weitverbreiteter Mythos ist, dass Agilität planlos sei. Oft wird angenommen, dass im agilen Umfeld lediglich von Sprint zu Sprint geplant wird und es somit keinen langfristigen Plan gibt. Diese Denkweise geht allerdings meiner Meinung nach viel zu kurz. In der Realität startet ein gut geführtes agiles Projekt mit einer vorbereitenden Phase, in der Grobkonzepte erstellt und eine Roadmap auf Ebene der Epics entwickelt wird. Im weiteren Verlauf erfolgt eine fortlaufende Vorplanung für die nächsten zwei bis drei Sprints, die an die Ergebnisse und Erkenntnisse aus dem abgelaufenen Sprint angepasst ist.

Agilität bedeutet nicht, dass man seine Meinung und den Plan jederzeit ändern kann, sondern dass man flexibel auf Veränderungen reagieren kann, ohne die übergeordnete Produktvision, das Produktziel und die Sprintziele aus den Augen zu verlieren.

Auf Basis der Kapazität des Teams und der Schätzung der User Stories können zumindest die nächsten Sprints geplant werden.

Agile mittelfristige Planung

Eine weitere Fehleinschätzung ist, dass sich mit Story Points nicht planen lässt. Zwar vermitteln Personentage oft den Eindruck einer detaillierten Planbarkeit, jedoch hat sich gezeigt, dass Teams damit häufig überfordert sind und die Schätzungen am Ende unrealistischer sind als mit Story Points. Mit Story Points lässt sich nach den ersten Sprints mit dem Team schnell die sogenannte Velocity ermitteln, wobei die Unsicherheiten (Cone of Uncertainty) berücksichtigt werden.

Die kurzfristige Planung wird durch die Sprintplanung abgedeckt, während die mittelfristige Planung die Schätzung und Planung der folgenden zwei bis vier Sprints umfasst. Dabei helfen die ermittelte Velocity und ein Vorrat geschätzter User Stories, die kontinuierlich angepasst und priorisiert werden.

Agile Längerfristige Planung (Roadmap)

Für die längerfristige Planung bietet sich die Magic-Estimation-Methode an. Ich habe damit immer sehr gute Erfahrungen gemacht. Meine Teams konnten damit sowohl schnell als auch effektiv schätzen. Zudem ermöglicht diese Methode, eine Schätzung für die gesamte Projektlaufzeit zu erstellen. Das Ergebnis ist eine priorisierte, hinreichend genau geschätzte Roadmap, die im weiteren Verlauf der Entwicklung anhand neu gewonnener Erkenntnisse regelmäßig überprüft und angepasst wird. Mit dieser Methode waren wir im Endergebnis stets besser in unseren Schätzungen und konnten den Stakeholdern somit eine verlässliche Roadmap liefern.

Der Ablauf der Magic-Estimation-Methode

1. Vorbereitung

• Bereitet eine Liste der zu schätzenden User Stories auf Karten oder in einem entsprechenden Tool (etwa miro oder Jira) vor.
• Gebt den Entwicklerinnen und Entwicklern einen kurzen Überblick über jede User Story. Hier haben alle die Möglichkeit, grundsätzliche Fragen zu stellen, die die Schätzung sehr wesentlich beeinflussen können.

2. Erste Schätzrunde

Jede Entwicklerin beziehungsweise jeder Entwickler erhält eine Kopie der Liste und schätzt die Größe jeder Aufgabe unabhängig voneinander. Ich habe die Liste jedoch meistens gleichmäßig im Team aufgeteilt, was meiner Erfahrung nach zu einem ebenso guten Ergebnis bei weniger Zeitaufwand geführt hat.

• Die Zeit für die Schätzung einer Aufgabe ist begrenzt (Time-Boxing). Je nach Größe und Detaillierungsgrad der Aufgabe habe ich hier mit fünf bis 15 Minuten gearbeitet.
• Die Schätzungen werden entsprechend eingetragen.

3. Anpassungen

• Die Teilnehmenden kommen zusammen und vergleichen ihre Schätzungen.
• Nacheinander kann jeweils eine Person genau eine Schätzung mit einer entsprechenden Begründung verändern. Ich trage die vorherige Schätzung dann immer auf der Karte ein, um die Unsicherheit in der Schätzung zu dokumentieren und in der Roadmap zu berücksichtigen. Eine Diskussion der Veränderung ist an dieser Stelle nicht notwendig, da alle anderen Teilnehmenden hier ebenfalls noch die Gelegenheit haben, Anpassungen vorzunehmen und Argumente dafür vorzubringen.

4. Weitere Schätzrunden

• Wiederholt den Schätzprozess, um zu sehen, ob die Diskussion die Einschätzungen verändert hat.
• Ziel ist es, eine Schätzung zu erreichen, die für eine Roadmap hinreichend genau ist. Das heißt, es muss nicht zwischen zwei unterschiedlichen Schätzungen hin und her gewechselt werden, bis sich alle auf zwei ähnlich große Schätzungen, beispielsweise drei und fünf Story Points, geeinigt haben. Für die Roadmap macht das keinen wesentlichen Unterschied.

5. Finalisierung

• Erstellt eine endgültige Liste mit den geschätzten Größen für jede Aufgabe.
• Diese Liste dient als Grundlage für die Erstellung einer Roadmap.

Die Magic-Estimation-Methode ermöglicht eine schnelle und effektive Schätzung von Aufgaben, indem sie kollektives Wissen und verschiedene Perspektiven berücksichtigt. Dabei fokussiert sich das Team auf die wesentlichen Faktoren für die Schätzung. Das Entscheidende ist, dass sie sich in der Praxis, zumindest in meinen Projekten, immer bewährt hat. So konnte ich in dem genannten Projekt alle Stakeholder, einschließlich des Vorstands, von unserer Roadmap überzeugen. Auch in allen weiteren Projekten konnte ich den Zeitplan immer einhalten und die Stakeholder mit dieser zuverlässigen Planung begeistern.

Fazit

Agilität ist durchaus planbar. Durch die Kombination aus kurzfristiger Sprintplanung, mittelfristiger Planung der nächsten Sprints und einer längerfristigen Roadmap lässt sich ein agiles Projekt effizient und zielgerichtet steuern. Flexibilität und Anpassungsfähigkeit stehen dabei nicht im Widerspruch zur Planbarkeit, sondern ermöglichen eine realistische und dynamische Projektplanung.

Ich hoffe, dieser Blog-Beitrag hilft euch, eure Projekte in Zukunft noch erfolgreicher umzusetzen. Viel Erfolg beim Ausprobieren!