Agiles Projektmanagement ist modern und über die Software-Entwicklung hinaus in vielen weiteren Kontexten hilfreich. Aber Scrum und Kanban haben auch Grenzen – ein Fakt, der, wie mir scheint, von vielen (oft selbsternannten) "Agile Consultants" gerne vergessen wird. So ist es beispielsweise kaum sinnvoll, Event-Planung agil umzusetzen: Wenn ich fixe Termine, zeitliche Abhängigkeiten und feste Verantwortlichkeiten habe, bietet mir agiles Projektmanagement nicht nur keine Vorteile, sondern es arbeitet sogar gegen mich. Sie schlagen ja auch keinen Nagel mit einem Schraubenzieher in die Wand, oder?

Die Vorteile der agilen Welt

Auf der anderen Seite bietet mir agiles Projektmanagement unglaubliche Vorteile, wenn ich mit Unsicherheit arbeite, wenn Anforderungen sich iterativ ändern können, wenn Abhängigkeiten primär nur inhaltlich existieren oder wenn es in vielen Fällen egal ist, wer aus einem Team eine Story umsetzt.

Was für uns in der Software-Branche seit Jahren der Status quo ist, wird in vielen anderen Branchen gerade erst richtig entdeckt. Das bedeutet, dass die Anzahl der agilen Projekte in klassischen Projektorganisationen in den nächsten Jahren weiter ansteigen wird – da sind sich alle Experten einig.

Und jetzt kommt noch SAFe dazu, eine durchaus geniale Methodik, um agile Projekte zu skalieren und um die kontinuierliche Entwicklung von Produkten und Services besser umsetzen zu können. Wobei man auch hier sagen muss, dass viele nur deshalb SAFe machen oder machen wollen, weil es gerade "in" ist. SAFe ist ein tolles Konzept, wenn mein Team eine bestimmte Größe hat und ich kontinuierliche Entwicklung habe, aber vollkommen ungeeignet für kleine Teams oder wenn ein fertiges Produkt irgendwann übergeben wird (Abnahme/Auslieferung) bzw. ein echtes Projektende notwendig und sinnvoll ist.

In anderen Worten: Wenn ich Pech habe, dann habe ich jetzt agile Projekte, klassische Projekte und Programme und vielleicht auch noch ein, zwei SAFe-Solutions in einem Portfolio. Wie gehe ich damit um? Sind agile und klassische Ansätze hier miteinander vereinbar? Oder widersprechen sie sich? Was ist, wenn die Theorie nicht der Praxis entspricht und auch in agilen Projekten eine Ressource in mehreren Projekten gleichzeitig mitarbeitet? Wie plane ich meine Ressourcen – bzw. plane ich sie überhaupt?

Das hybride Projektportfolio

Die Lösung ist ein hybrides Portfolio: Ich definiere ein Projektportfolio inklusive aussagekräftiger Kennzahlen so, dass es sowohl für agile als auch für klassische Ansätze funktioniert. Das klingt im ersten Ansatz kompliziert, ist es aber nicht – wenn man die richtigen Konzepte anwendet und die Dinge nicht überkompliziert.

Die zwei Hauptherausforderungen dabei sind, (A) hybride Kennzahlen zu definieren, die sich gut auf Basis agiler und klassischer Basiswerter aufsummieren lassen, und (B) die Reporting-Strukturen in beiden Projektarten so zu gestalten, dass eine sinnvolle Aggregation überhaupt erfolgen kann.

Wir haben uns gemeinsam mit unseren Consulting-Partnern in den letzten zwei Jahren ganz massiv mit dem Thema hybride Kennzahlen beschäftigt. Das Ergebnis war so überraschend einfach, dass wir es noch doppelt und dreifach überprüft hatten: Im Prinzip können wir ganz klassisch von den PMI-Kennzahlen ausgehen – alle bis auf den Scheduled Performance Indicator (SPI) funktionieren auch für agile Projekte. Warum? Der wesentlichste Unterschied zwischen einem agilen (v.a. Scrum) und einem klassischen Projekt ist die Terminplanung: Sprintplanung versus Gantt-Planung (vernetzter Balkenplan), und das kommt eigentlich nur beim SPI wirklich zum Tragen. (Gut, beim CPI muss man auch aufpassen, aber das geht schon sehr ins Detail und sprengt den Umfang dieses Artikels.)

So weit, so gut. Aber was mache ich jetzt mit dem SPI? Auch relativ einfach: Wir können die Velocity bei agilen Projekten als Ersatz für den SPI hernehmen und (vorausgesetzt, wir passen dabei auf, dass wir nirgendwo im Detail Äpfel mit Birnen gleichsetzen) in eine kombinierte SPI/Velocity-Kennzahl aufsummieren.

Richtige Aggregation für Kosten, Risiken und Stakeholder

Eine Frage, die im Zuge eines hybriden Portfolios ebenfalls sehr schnell auftaucht, lautet: Wie gehe ich mit Kosten, Risiken und Stakeholdern um? Auch hier ist die Antwort eigentlich eine einfache: Wenn ich das Reporting für meine agilen Projekte richtig aufgesetzt habe, dann kann das genauso wie bei klassischen Projekten funktionieren. Aber wenn das gleich ist wie bei klassischen Projekten – kann ich dann beispielsweise trotzdem "Lean Budgeting" u.ä. machen? Ja, absolut! Hier befinden wir uns auf einer ganz anderen Ebene, wir verbauen uns gar nichts, hier geht es um die Basics.

Aber was ist die richtige Struktur? Aus unserer Sicht und auch aus Sicht der Mehrheit unserer Consulting-Partner (ein paar sind noch unschlüssig) ist es nicht sinnvoll, hier über Sprints zu aggregieren. Stattdessen sollten wir ausschließlich über die Epics-Struktur gehen. Warum? Sprints sind im Gegensatz zu Projektphasen in klassischen Projekten nur zeitliche Rahmenstrukturen, ein Koordinationswerkzeug, sie haben keinen inhaltlichen Gruppierungscharakter. Epics hingegen definieren eine inhaltliche Struktur und bei allen Kundenprojekten, die wir bisher gesehen haben, entspricht der Epics-Plan dem inhaltlichen Plan, über den ich Kosten etc. reporten möchte.

Hybride Ressourcenplanung: As Good as it Gets

Wo Sprints hingegen logischerweise zum Einsatz kommen, ist die hybride Ressourcenplanung. Die Sprintplanung entspricht ja im Prinzip der Terminplanung bei klassischen Projekten. Mit dem einfachen "Trick", dass man an Stories auch virtuelle, dynamische Start- und Enddaten vergibt (idealerweise automatisch auf Basis der Start- und Enddaten des zugewiesenen Sprints), kann man eine Ressourcenplanung über agile und klassische Projekte hinweg gestalten.

Dabei müssen wir beachten, dass die Sprintgrenzen idealerweise bei allen Projekten gleich sein sollten (zumindest bei allen Projekten, die sich Ressourcen teilen). Ansonsten ist es schwierig, Ressourcenkonflikte aufzulösen – selbst wenn man sie erkennen kann. In der Praxis hat es sich in diesem Zusammenhang bewährt, auch klassische Pläne (soweit möglich) weitgehend an den unternehmensweiten Sprintgrenzen auszurichten. (Das geht aber natürlich nicht immer.)

Hier dürfen wir freilich nicht vergessen, dass wir im agilen Bereich nur eine ungefähre Ressourcenplanung bekommen, denn es werden nicht alle Stories explizit einer Ressource zugewiesen sein. Das ist aber vollkommen in Ordnung – mehr wollen wir ja auch nicht, sonst engen wir die agile Planung unnötig ein. Wir möchten ja nur sehen, wer in etwa an was arbeitet, wo Kapazitäten sind und wo permanent Überlastung herrscht. Übrigens planen unsere Kunden mittlerweile auch in klassischen Projekten oft nur auf Team-Ebene und weisen lediglich Schlüsselressourcen explizit zu, denn: Warum mehr planen als in der realen Welt auch wirklich sinnvoll planbar ist?

Jira, Plugins, Excel, oder mehr?

Okay, klingt interessant, doch wie setze ich so etwas um? Im Prinzip kann ich alles mit Jira, diversen Plugins und einigen Excel-Makros realisieren. Aber damit muss mir auch bewusst sein, dass ich auf diese Weise ein hybrides Projekt- und Portfoliomanagement-System (PPM) selbst zusammenbaue (mit allen Vor- und Nachteilen).

Eine Alternative besteht darin, sich PPM-Systeme anzuschauen, die, wenn ich Jira einsetze, über eine bidirektionale Jira-Schnittstelle verfügen und hybride Konzepte anbieten. Ein solches System ist beispielsweise ONEPOINT Projects, das auf dem gleichen Technologie-Stack wie Jira aufbaut (Tomcat, Java, Datenbank) und sowohl in der Cloud als auch On Premise verfügbar ist.

Aber das Wichtigste ist aus meiner Sicht, dass man sich nicht in eine Ecke drängen lässt. Die Zukunft ist weder rein klassisch noch rein agil, sie ist beides. So wie auch im Alltag heißt es ganz einfach, das richtige Werkzeug für den jeweiligen Anwendungsfall auszuwählen und nicht blind das zu tun, was der Nachbar auch macht.

---

Dies ist ein Gastartikel von Gerald Aquila, dem Gründer und CEO von ONEPOINT.