Unser Projekt-Prozess

Fangen wir mit der Fragen aller Fragen an: Warum braucht es in agilen Zeiten überhaupt einen solchen Prozess und was beinhaltet er? Fangen wir beim „Warum“ an.

Abhängigkeiten!

Agilität verspricht reduzierten Planungsoverhead, ganz nach dem Motto: Man plane nichts, was sich nicht planen lässt.

Soweit so gut, was ist aber mit den Abhängigkeiten, die es in heutigen Softwareprojekten gibt? Haben wir nicht in Wirklichkeit ein lange Kette an Abhängigkeiten in Form von aufeinander aufbauenden Arbeiten? Kann die Entwicklung ohne hohen Klärungsaufwand starten, ohne dass alle Anforderungen erfasst und aufgearbeitet wurden? Und braucht es nicht vorher ein UX-Konzept? Und hat QA vorher die Testdaten bereitgestellt? Ach, und dann fehlt ja noch die Entscheidung zum Datenmodell XYZ! Sind denn die Lizenzen für ABC schon vom Einkauf freigegeben? Und…wie behält man das alles im Blick Hm!

Es braucht also auch in agilen Zeiten einen Plan.

Auch wenn ein solcher natürlich nicht hart in Beton gemeißelt sein darf, wie damals zu Wasserfallzeiten. Aber es braucht zumindest eine konzipierte Kette an Aufgaben und eine stets aktuelle Übersicht über deren Status. Nur so lassen sich Sprints mit Blick auf ein PI oder Release planen. Und nur so lassen sich die Implikationen von neuen, agilen Erkenntnissen und Entscheidungen ablesen, reagieren und Richtung Stakeholder kommunizieren.

Budget- und Termintransparenz

Nach Abbildung aller Abhängigkeiten in einem Plan lässt sich ablesen, was im Idealfall überhaupt machbar wäre. Nicht, dass der Plan genau so eintreten wird, aber zumindest wird ein Best-Case transparent – und ganz im Ernst: Dieser Best-Case passt im ersten Wurf selten zu den terminlichen Vorstellung einiger Beteiligten. Aber mit dem Plan ist eine Dialog-Grundlage geschaffen.

Verbindlichkeit von Zuarbeiten

Ein standardisierter Plan erfüllt neben der transparenten Behandlung von Abhängigkeiten einen weiteren Zweck: Zu verhindern, dass unzureichende Zuarbeiten ungesteuert in die Entwicklungsteams rauschen und die Defizite dort aufgefangen werden müssen. Inklusive Stress, sinkender Qualität…Sie kennen das Spiel. Durch einen Plan fallen unaufgelöste Abhängigkeiten sofort auf, der Product Owner kann entsprechend umplanen und somit in gewisser Weise auch einen Erziehungsprozess stützen, der die Verbindlichkeit von Zuarbeiten fördert.

Vom „Plan“ zum „Prozess“

Bisher war die Rede von einem „Plan“. Im Titel dieses Beitrags heißt es aber „Prozess“. Ja! Weil ein Plan viele komplexe Einflussfaktoren abbildet, vor allem immer wieder ähnliche Einflussfaktoren. Unser Prozess rund um die Planung eines Projektes sammelt alle Erfahrungen und persistiert sie für andere Teams und die nächsten Projekte.

Wir reden also über unseren Prozess, der mit maximal vielen Erfahrungswerten einen guten Plan ermöglicht

Außerdem können sich die Teams an den Prozess gewöhnen, es formt sich ein Vokabular und jeder weiß schnell, worüber geredet wird. So denn: Willkommen zu unserem Projektprozess.

Unser Prozess folgt folgenden Grundregeln:

• Keine unaufgelösten Abhängigkeiten in einen Sprint
• Klare DoD („Definition-of-Dones“) an allen aufeinander aufbauenden Arbeiten
• DoD werden immer von der konsumierenden Partei aufgesetzt, zumindest aber abgenommen
• Die meisten Arbeitspakete sind typisiert und per DoD konkretisiert (z.B. „REQ“ für Requirements Engineering, „ARCH-PREP“ für Architektur-Vorbereitungen usw.)
• Jedes Epic durchläuft mindestens eine Sequenz an typisierten Arbeitspakete, geplant in einer Roadmap mit Einbeziehung der Team-Kapazitäten

Hier eine Übersicht auf höchster Ebene:

Das „Epic-Setup“ im Vorprojekt

Im Vorprojekt wird der Input von fachlichen Vertretern – in der Regel ausgewählte Produktmanager – gesammelt und vom Product Owner in Produkt-Features übersetzt. Bei diesem Vorgang werden spezifische, einzelne Anforderungen eines Use Cases in ein Baustein des Produkts überführt. Dabei spielt Ähnlichkeit zu anderen Anforderungen eine Rolle, Wiederverwendbarkeit an anderer Stelle des Produkts aber auch Anpassbarkeit und Wichtigkeit des Features.

Wichtige Betrachtung von Anforderungen: Denkbare Ausbaustufen! Was wäre als Must-Have ein schlichtester Ansatz? Was wären Nice-to-have und was die goldene Krone?

Der fachliche Input wird anschließend von PO, UX, Architektur und QA als „Umsetzungsstrategie“ verarbeitet. Es entsteht ein oder mehrere Lösungsvorschläge, der üblicherweise iteriert werden und schlussendlich realistische Ideen an Lösungen für alle priorisierten Epics entstanden sind.

Operativ bilden sich die Epics, Prioritäten und Ausbaustufen in einer standardisierten Liste ab. Die hellblaue Spalte im Screen unten beinhaltet den gemeinsam erarbeiteten „Business Value“. Das ist der Wert, den ein Feature aus Sicht des Marktes hat. Kombiniert mit Faktoren, die hauptsächlich von nicht-funktionalen Anforderungen bestimmt werden, errechnet sich eine erste Idee zum Aufwand des Vorhabens je Kompetenz. Es lässt sich komfortabel ein Set an Must-Haves und Ausbaustufen zusammen setzen, so dass es passendes Set an Funktionalität im Rahmen eines Budgets für die nächste Phase greifen lässt.

Roadmapping im Vorprojekt

Vor den Release- oder PI-Zyklen setzen wir mit Hilfe einer Roadmap einen groben Fahrplan auf, der alle Abhängigkeiten in Reihe setzt und die Kapazitäten der kommenden Phasen berücksichtigt.

Standardisierte Aufgabenpakete in einer Regelsequenz befreien vom „Immer wieder das Rad neu erfinden“ und verschaffen den Teams Gewöhnung und Orientierung.

Wir setzen dabei auf standardisierte Aufgabentypen, die in Regelreihenfolge aneinander gereiht werden. So startet eine detaillierte Anforderungsbetrachtung durch den PO, dann gehen UX und Architektur in die Konzeption und anschließend die Umsetzungsaufgaben.

Operativ konkret sieht das ganze wie in folgender Grafik aus. Im Tabellenteil rechts unten zeigen sich die Sequenzen der Tasks je Epic. Die Grün-Schwarze Tabelle oben rechts zeigt die Restkapazitäten je Sprint-Spalte.

Bei Sprintplanung werden dann die kommenden Sprints in das operative Aufgabensystem überführt (JIRA, Gitlab o.ä.) und nach dem Sprint neue Erkenntnisse in Form von Planungsanpassungen adaptiert.

Solange alle Daten in unseren operativen System liegen, sind automatisch Schätzungen und Zeiterfassungen angebunden. Damit liegt eine lückenlose Kette von Volumen vor: Angefangen bei groben Schätzungen im Epic-Setup, über die Roadmap bis zu den Schätzungen und tatsächlich erfassten Zeiten. Neue Erkenntnisse können sauber abgebildet werden, Implikationen sind sofort transparent und es kann effizient neu priorisiert und umgeplant werden.

So. Genug aus dem Nähkästchen! Wer mehr wissen möchte, wird ein Projekt mit uns machen müssen!

Unser Martin Hoppe freut sich auf die Kontaktaufnahme!