Agile Software-entwicklung

Erst dann wird das Big Picture erarbeitet. Gemeinsam mit dem Kunden. Module werden erst im weiteren Projektverlauf auf Sichtweite spezifiziert. Wir liefern „fast, often und early“. Wir arbeiten prototypisch, RE.A.L und „safe to fail“.Waste? Den identifizieren wir und reduzieren ihn maximal. Wir realisieren das Optimum. Erst mal ohne Schnick-Schnack. 70%. Fertig werden. 

Dann wissen wir, wieviel Zeit und Geld wir für Sonderlocken haben. Und wo das Feintuning am meisten Nutzen generiert. Den Stand halten wir fest und kommunizieren ihn. Danach startet der Ponyhof mit: Feintuning, Optimierung und Dressur.Wie schaut ein typisches, agiles Softwareprojekt bei sitegeist aus? Was sind die wirklich entscheidenden Faktoren im agilen Projektmanagement?

Dies sind die klassischen Phasen im Teamentwicklungsmodell nach Tuckman. Interessanterweise lässt sich dieses Model auch auf den typischen Verlauf von agilen Softwareprojekten, und den Herausforderungen die sich daraus für das Projektmanagement ergeben, übertragen.

1. FORMING

Auch am Anfang eines agilen Softwareprojektes steht die Zusammenstellung des Projektteams. Sowohl agenturintern als beim Kunden werden Skills und Ressourcen überprüft, Verantwortliche bestimmt und mit Aufgabenbereichen versehen. 

Es erfolgt die gemeinsame Erarbeitung einer Projektvision mit dem Kunden, häufig in Form von einem oder mehreren Workshops.

Im Zuge dessen gilt es, den True North gemeinsam zu erarbeiten, quasi eine gemeinsame Projektvision und  Verständigung auf das oft noch in weiter Ferne gelegene Ziel. Hier steht eher noch das Was und Warum im Vordergrund als das Wie. Im Rahmen der „Raw Estimation“ aus dem RE.A.L. – Prinzip erfolgt eine gemeinsame Benennung von Modulen, nicht aber deren Spezifikation. Sind Timing & Kosten fix, muss die Größe Module (Scope) variabel sein.

2. STORMING

Das Projekt läuft an, jeder der Verantwortlichen widmet sich seinen - aus dem Workshop abgeleiteten -  Arbeitsaufträgen. In dieser frühen Phase kann eine Herausforderung darin bestehen, womöglich noch unterschiedlichen Auffassungen in der Herangehensweise und unterschiedliche Arbeitsprozesse aufeinander abzustimmen.

Eine Besonderheit in agilen Softwareprojekten stellt beispielsweise hier die Tatsache dar, dass es keine detaillierten Spezifikationen und keine detaillierten Kalkulationen gibt. „No waste!“ lautet hier die Devise, der auch alle Projektbeteiligten meist bedingungslos zustimmen. Aber was macht die Agentur denn jetzt genau? Wie stelle ich sicher, dass die Agentur nach meinen Vorstellungen agiert? Wurde in den Workshops wirklich alles Notwendige besprochen? Hier besteht die Herausforderung auch mal „Unsicherheiten“ auszuhalten. Hier ist nun Agilität gefragt („agile“ aus dem RE.A.L. – Prinzip).

Hier zahlt es sich aus, wenn alle Beteiligten sich zu Beginn die Mühe gemacht haben, eine gemeinsame Vision und somit ein „Big Picture“ entwickelt zu haben. Darauf basierend können nun User Stories formuliert werden.

Für viele Beteiligten gefühlt zu spät erfolgt dann die konkrete, detaillierte Planung der Tasks auf Sichtweite, das sogenannte – „Rolling Wave Planning“. Im Umkehrschluss bedeutet dies aber auch, dass Features und Module, die erst in 6 Monaten realisiert werden, nicht zum jetzigen Zeitpunkt umfassend auf Basis von zahlreichen, unsicheren Annahmen spezifiziert werden. In der Vergangenheit suggerierten die früh abgelieferten, umfassenden Spezifikationen vielleicht Sicherheit und gaben Projektverantwortlichen in den Unternehmen den internen Stakeholdern einen frühen, umfassenden Nachweis über die Projektinhalte und dessen Fortschritt. Ist in den Unternehmen eine entsprechende, tradierte Informationskultur gegeben, steht der Projektverantwortliche vor der Aufgabe, auf allen Ebenen im Unternehmen grundlegendes Umdenken anzustoßen und Verständnis für die 12 Prinzipien aus dem agilen Manifest zu schaffen. Wenn dies gelingt, können gemeinsam die Vorteile der agilen Softwareentwicklung ausgespielt werden.

DIALOG AUF AUGENHÖHE

Hier ist es von entscheidender Bedeutung, dass Agentur und Projektverantwortliche in dem Unternehmen in einem engen und offenen Dialog auf Augenhöhe stehen. Stets und ständig Prozesse zu hinterfragen und immer wieder zu optimieren ist Teil des agilen „Gesamtpakets“ und darf nicht als Zeichen für ein frühes Scheitern verstanden werden.

4. PERFORMING

In dieser Phase zahlt sich nun die Grundlagenarbeit aus.

Jedes der aktuell vier sitegeist Teams mit einer Größe von etwa 10 – 15 Mitarbeitern arbeiten autark und crossfunktional. Das Kanban Prinzip bildet den Handlungsrahmen und stellt den Flow in den Fokus. Zu den Aufgaben des agiles Projektmanagers zählt daher nicht ausschließlich betriebswirtschaftlich messbare Größen im Blick zu behalten, sondern auch sicherzustellen, dass die Softwareentwickler möglichst konstant im Flow fokussiert und effizient arbeiten können.

Dem Anspruch, das Projekt möglichst „lean“ umzusetzen, wird nicht nur am Anfang des Projektes Rechnung getragen, in dem man „Waste“ in Form von KVAs und Lastenhefte vermeidet.

Vielmehr geht es um ein stets hinterfragen und ausloten des „So viel wie nötig, so wenig wie möglich“.  Hier sind alle Projektbeteiligten aufgerufen, das Projekt durch Ihre Fähigkeiten aktiv Mitzugestalten.
Dazu zählt beispielsweise auch die Einhaltung einer effektiven Meeting-Kultur:

• Klares Ziel
• Fokus aller Beteiligten
• variable Teilnehmer
• Time-Box
• Dokumentation Ergebnis und next Step

In dieser Phase des Projektes erfolgt nun auch die Spezifikation und Realisation der einzelnen Module auf Sichtweite. Auch hier wird  lean („lean“ aus dem RE.A.L. – Prinzip) agiert, in dem der Fokus auf die Ausarbeitung des  „Modul- MVP" gesetzt wird.

Die Kunst des agilen Projektmanagements besteht darin, eben nicht immer alle Sonderlocken sofort und bedingungslos umsetzen zu lassen. Ganz im Gegenteil: Man darf auch früher, in einer zunächst simplen Ausprägung, fertig sein.

Die Überwachung des Projektfortschrittes und die Kostenkontrolle durch den Projektmanager erfolgt auch im agilen Projektmanagement über alle Phasen hinweg. Aber wie funktioniert das ohne Pflichten- oder Lastenheft?
Durch die enge Verzahnung von Ticketsystem, Zeiterfassung und Predictionsheet (basierend auf den zu Beginn definierten Modulpaketen) werden die für den Erfolg des Projektes entscheidenden Kennzahlen stets effizient überwacht und transparent visualisiert.

Der Performing Prozess erfolgt in mehreren Iterationen, bis zum finalen Projektabschluss – meist in Form des Onlinestarts einer Website oder Kampagne.

Werden die höchst effizienten Details des RE.A.L.-Konzeptes in einem agilen Softwareprojekt von allen Projektbeteiligten zur Anwendung gebracht, wird das Ergebnis schneller, günstiger und besser.