Die Beliebtheit agiler Methoden in Softwareprojekten steigt stetig an – und doch sind die wenigsten Organisationen in der Lage, einen “puristischen” Ansatz zu verfolgen. Das liegt daran, dass in vielen Branchen und Projekten gewisse Mindeststandards der klassischen Projektwelt eingehalten werden müssen. Es gibt praktisch immer einen Projektstart und ein Projektende, einen fixen Budgetrahmen und gewisse Protokoll-Pflichten.

Um eine Brücke zwischen der agilen und der klassischen Welt zu schlagen, haben wir im Lauf der Zeit diverse Methoden angewendet und wollen heute eine davon vorstellen: das Pre-Planning.

Welchen Rahmen sollte das Pre-Planning haben?

Wie es der Name schon suggeriert, sollte das Meeting vor dem jeweils nächsten Sprint Planning durchgeführt werden. Zur Verdeutlichung: wenn man zweiwöchige Sprints durchführt, die jeweils von Mittwoch bis Mittwoch gehen, ergibt sich folgender Ablauf (das regelmäßige Backlog Refinement wird an dieser Stelle bewusst ausgeklammert):


In der klassischen Welt des Projektmanagements wären “Jour fixe” oder “Statusmeeting” geläufige Bezeichnungen. Um nun die Brücke zwischen den beiden Welten zu schlagen, sind aus unserer Sicht folgende Dinge zu berücksichtigen:

  • Teilnehmer: das Pre-Planning soll sämtliche Aspekte des Projekts, also organisatorische wie inhaltliche, bedienen können. Je nach Setup des Projekts sollten folgende Rollen vertreten sein:
    • Product Owner (= Auftraggeber)
    • Proxy Product Owner (= verlängerter Arm des Product Owners auf Seite des Auftragnehmers)
    • Projektleiter (= Auftragnehmer; diese Rolle ist je nach Setup möglicherweise auch nicht besetzt und könnte z.B. durch den Proxy Product Owner übernommen werden)
    • Scrum Master
    • Requirements Engineers
    • Punktuell bzw. abhängig von den aktuellen Themen können auch Entwickler, Tester oder andere Rollen eingeladen werden
  • Dauer: das Pre-Planning hat, im Gegensatz zu den standardmäßigen Scrum-Meetings, keine theoretische, zeitliche Vorgabe. Je nach Projektgröße und damit einhergehender Themenmenge sollten ein bis zwei Stunden angesetzt werden. Da das Pre-Planning als Entscheidungsgremium für das Projekt gesehen werden kann, sollte man es auf keinen Fall künstlich kurz halten.
  • Dokumentation: zwar besagt das Agile Manifest, dass funktionierende Software wichtiger ist als umfassende Dokumentation (und dem stimmen wir zu), das Pre-Planning ist jedoch für ein hybrides Vorgehen gedacht, in welchem Protokoll-Pflichten existieren. Entsprechend legen wir in einem solchen Setting großen Wert auf ein Protokoll, welches alle besprochenen Punkte und Entscheidungen beinhaltet.
  • Transparenz: wir legen höchsten Wert auf Transparenz. Das bedeutet, dass das Protokoll während des Termins direkt erstellt/mitgeschrieben wird und für alle Beteiligten einsehbar ist. Bei einem Vor-Ort-Termin wird es also via Beamer/Monitor präsentiert, in einem Remote-Meeting via Screenshare. Zusätzlich sollen alle relevanten Stakeholder, auch außerhalb des Teilnehmerkreises, jederzeit Zugriff darauf haben. Das Vehikel dafür (z.B. Dokumentation in Confluence oder Einrichtung eines gemeinsamen Ablagesystems) sollte vorab definiert werden.

Wie läuft ein Pre-Planning ganz konkret ab?

Es gibt keine Limitationen hinsichtlich Themen, die in ein Pre-Planning aufgenommen werden dürfen. Alles, was mit dem Projekt zu tun hat und dem Fortschritt dienlich ist bzw. diesen behindert, sollte komplett transparent im Pre-Planning besprochen werden.

Für uns hat sich in der Praxis folgender Aufbau bewährt:

  1. Organisatorische Themen: um den Themen des Projektmanagers und Scrum Masters Sorge zu tragen, werden folgende Agendapunkte jedes Mal besprochen:
    1. Allgemeiner Projektstatus
    2. Projektbudget
    3. Personelles
    4. Review des RAID-Logs (je nach Projektgröße und definiertem Ablauf können z.B. auch nur die Risiken betrachtet werden)
    5. Sonstige organisatorische Themen
  2. Inhaltliche Themen: diese Punkte kommen in der Regel vom Product Owner, Proxy Product Owner oder dem Requirements Engineer und können eine Vielzahl von Themen abdecken:
    1. Review des Product Backlogs (Priorisierung, wie viele Tickets erfüllen die Definition of Ready, etc.)
    2. Festlegung des Sprintziels für den anstehenden Sprint
    3. Inhaltlicher Projektstatus
    4. Klärung von Fragen, welche sich im letzten Sprint (z.B. im Rahmen von Backlog Refinements) ergeben haben
    5. Klärung von Fragen, welche sich bei der Erstellung von User Stories ergeben haben
    6. Inhaltliche Diskussionen und Entscheidungen (z.B. kann der Outcome eines Spikes mit dem Product Owner besprochen werden, um die nächsten Schritte festzulegen)
    7. Aufzeigen von Abhängigkeiten, Risiken und Issues, welche sich im Rahmen des letzten Sprints ergeben haben

Fazit

Das Pre-Planning stellt eine Methode dar, die sich für uns bewährt hat, wenn es darum geht, eine Brücke zwischen klassischer und agiler Softwareentwicklung zu schlagen, indem es organisatorische und inhaltliche Aspekte des Projekts berücksichtigt. Durch die Einbindung relevanter Rollen, entsprechende Dokumentation und maximale Transparenz bietet das Pre-Planning eine solide Grundlage für ein hybrides Vorgehen.

Weitere Posts