Von 0 auf 100: Starthilfe für neue Initiativen

Wie Goethe schon sagte: “Aller Anfang ist schwer”, so ist es auch in der Software Entwicklung. In klassischen Vorgehensmodellen wie dem Wasserfall-Modell oder dem V-Modell findet man in zahlreichen Projektmanagement Büchern und Zertifizierungen Antworten auf die Frage, wie beginne ich am Besten ein Softwareentwicklungsprojekt. In der agilen Softwareentwicklung gibt es hierzu weniger vordefinierte Modelle oder Prozesse denen gefolgt werden kann.
Matthias Kreuzriegler
Co-Founder
veröffentlicht am 15.10.20197 Minuten Lesedauer

Die Inhalte des Agile Manifesto oder des Scrum Guides geben wenig Information darüber Preis, wie ein Softwareentwicklungsprojekt gestartet werden sollte. Dies ist dadurch zu erklären, dass der Scrum Guide zwar ein Framework für die agile Produktentwicklung beschreibt, aber es keine vordefinierte Taktik oder Vorgehen hierfür gibt. Im Scrum Guide steht wörtlich: “Specific tactics for using the Scrum framework vary and are described elsewhere“. Auch das Agile Manifesto stellt lediglich einen Leitfaden dar und sollte in der agilen Softwareentwicklung stets als Entscheidungsgrundlage herangezogen werden.

Wenn man sich nun mit den klassischen Projektmanagementansätzen beschäftigt, kommt man schnell auf den Begriff “Vor-Projekt-Phase”. Diese besteht aus folgenden Teilen:

  • Situations- und Kontextanalyse
  • Projektzielsetzung
  • Projektorganisation
  • Aufwands- und Kostenschätzung
  • Projektauftrag

Um mit einem Softwareentwicklungsprojekt starten zu können, sind im Vorfeld eine Vielzahl an Entscheidungen notwendig, welche größtenteils während der Vorprojektphase getroffen werden. Dies ist auch bei agilen Softwareentwicklungsprojekten nicht anders. Ohne Situations- und Kontextanalyse könnte sich erst zu einem viel späteren Zeitpunkt eine mangelnde Unterstützung seitens der Unternehmensleitung herausstellen oder ein Konkurrenzprodukt in die fachlichen Entscheidungen nicht einfließen. Die Projektzielsetzung hilft während der Entwicklung stets anhand messbarer Ergebnisse auch den Nutzen und die Wirkung analysieren zu können. In der Projektorganisation können unter anderem die Stakeholder identifiziert werden und weitere organisatorische Vorbereitungen getroffen werden. Die Aufwands- und Kostenschätzung hilft bei der groben Abschätzung des notwendigen finanziellen Rahmens, sowie der groben Zeitdauer und der benötigten Entwicklungsressourcen. In einem Projektauftrag können die zuvor getroffenen Entscheidungen verschriftlicht und zeremoniell zwischen Projektauftraggeber und Projektauftragnehmer übergeben werden. Bei sehr kleinen Projekten und Intitiativen kann die Vorprojektphase eventuell auch innerhalb weniger Stunden oder in einem einzigen Meeting durchgeführt werden. In jedem Fall durchlebt jedes Projekt diese Phase, egal ob bewusst oder unbewusst.

Brücke mit Nebel
Den Weg zu neuen Projekten lichten.

Wenn bereits in der Vorprojektphase die Grundsätze des Agile Manifesto verstanden und berücksichtigt werden, so kann bereits in dieser Phase ein Grundstein für die erfolgreiche agile Projektdurchführung gelegt werden. Dennoch besteht die Gefahr durch dogmatisches einhalten von Definitionen und Ideen des klassischen Projektmanagements, bereits in dieser frühen Phase Entscheidungen zu treffen oder Erwartungen zu schüren, die zu einem späteren Zeitpunkt Probleme bereiten können. Daher ist die Vorprojektphase auch mit viel Bedacht und entsprechender Voraussicht anzulegen.

Ist die Vorprojektphase erfolgreich abgeschlossen, so beginnt meist nach kurzer Zeit die eigentliche Projektphase. Diese stellt die nächste Herausforderung dar. In klassischen Ansätzen würden nun die Businessanalysten und Requirements Engineers ihre Arbeit beginnen um in der Phase der Anforderungsanalyse den Grundstein für die Entwicklung zu legen. In agilen Projekten gibt es diese Phase aber per Definition nicht. Dort kann man zu diesem Zeitpunkt zwei verschiedenen Situationen vorfinden:

  1. Alle Personen die für die Umsetzung des Softwareprojekts geplant sind, stehen zur Verfügung (eher selten)
  2. Die Einstiegszeitpunkte der Teammitglieder variieren und das Projekt startet mit einer reduzierten Anzahl an Personen (meist der Fall) Bei der meist eher unwahrscheinlichen Variante, dass alle Teammitglieder zum Startzeitpunkt des Projekts bereits zur Verfügung stehen und sich ausschließlich der neuen Aufgabe widmen können, bietet sich der sogenannte Sprint-Zero (auch Sprint-Null oder Sprint 0 genannt) an. Die Meinungen zum Sprint-Zero gehen in der Agile Community sehr stark auseinander. Der Hauptkritikpunkt hierbei ist der oft fehlende Business-Value im Sprint-Zero. Einige Organisationen sehen den Sprint-Zero als Verlängerung der Vorprojektphase oder gar als Ersatz hierfür. Sie planen im Sprint-Zero die organisatorischen Tätigkeiten sowie erste Architektur- oder Requirementsengineering Workshops, ohne als Sprint-Deliverable Business-Value zu generieren. Dies steht im krassen Widerspruch zu der Idee von Sprints, welche stets einen echten “Value” als Outcome zu verzeichnen haben. Dies macht auch Ansätze wie “Hardening-Sprints” oder “Release-Sprints” zu Anti-Pattern. Als Anti-Pattern wird bei fehlen von echten Sprint-Zielen die Business-Value generieren oft auch der Sprint-Zero bezeichnet. Nichtsdestotrotz hat sich dieser Begriff etabliert und findet vielfach Zuspruch.

Das Fehlen des klaren Deliverable mit Business-Value aus dem Sprint-Zero kann durch die Definition eines solchen gelöst werden, was ihn für viele zum ersten regulären Sprint macht. In jedem Fall empfiehlt sich in den ersten Sprints dem Team ausreichend Zeit für Teambuilding und das Aufsetzen von “General Agreements” zu geben. Darunter fallen die Definition of Done, Definition of Ready und weiteren internen “Spielregeln” für das Team. Vor allem in Distributed-Teams oder aber auch Teams die aus Personen bestehen die zum ersten Mal zusammenarbeiten, ist das soziale Wohlbefinden und das berücksichtigen von Team-Dynamiken ein wichtiger Erfolgsfaktor.

Bei der zweiten Variante, bei der die Einstiegszeitpunkte der Teammitglieder variieren, ist meist eine gemeinsame Phase zu Beginn des Projekts nicht möglich. Somit bietet sich hier auch kein Sprint-Zero an, was sehr schön veranschaulicht, dass dieser meist auch nicht zwingend notwendig ist. Nehmen wir an ein Projekt startet mit zwei Personen. Beide sind T-shaped Professionals und decken gemeinsam alle für diese Phase des Projekts notwendigen Disziplinen der Softwareentwicklung ab. Diese beiden Teammitglieder können beginnend mit dem ersten Tag des ersten Sprints an Artifakten arbeiten, die echten Value generieren und dies in sehr hoher Qualität. Sie werden durch die direkte und intensive Zusammenarbeit sehr schnell mehrere Phasen (vgl. Phasenmodell nach Tuckman) des Teambuildings durchlaufen. Wenn nach und nach weitere Teammitglieder dazustoßen, werden zwar die Phasen wiederholt durchlaufen, dauern aber je nach Reife des Teams nur noch kurz an. Wie die Teamdynamik bereits vom ersten Tag an entsteht und sich laufend verändert und weiterentwickelt, so ist dies in einem agilen Umfeld häufig auch bei der Softwarearchitektur der Fall. Der Fakt, dass sich die Umstände ständig ändern werden, wird in agilen Softwareentwicklungsprojekten akzeptiert und aktiv gesteuert.

Zusammenfassend sind folgende Aspekte beim erfolgreichen Start einer neuen Initiative oder Projekt im agilen Softwareentwicklungsumfeld zu erwähnen:

  • Jedes Projekt benötigt eine Vorprojektphase, in der die Rahmenbedingungen geklärt werden und der Grundstein für das eigentliche Projekt gelegt wird.
  • Sprint-Zero ist nur sinnvoll wenn alle Teammitglieder bereits im Projekt arbeiten und der Fokus des Sprints auf liefern von Business-Value liegt (ansonsten Anti-Pattern).
  • Mit hochqualifizierten Teammitgliedern kann bereits bei geringem Headcount Business-Value in hoher Qualität geliefert werden.