Hybrid Project Management – Lösung oder Irrweg?

Seit dem Einsetzen der Industrialisierung zu Beginn des 20. Jahrhunderts haben sich die Rahmenbedingungen der Arbeit – nicht nur, aber speziell im Knowledge Working – laufend verändert. Sowohl technologisch, als auch (markt-)ökonomisch, als auch sozial. Die sich stetig verändernden Herausforderungen erfordern laufende und proaktive Adaption der Kollaboration und der Unternehmenskultur. Unterschiedliche Denkmodelle, Frameworks und Standards versuchen Lösungen zu bieten. Welches Modell ist nun „gut“, welches ist „schlecht“? Die für mich klare Antwort lautet: Die Frage ist falsch.

In komplexen Industrien mit sehr dynamischen Umgebungen, schnellen Veränderungen und schwer bis gar nicht vorhersehbaren Entwicklungen (ob VUCA, BANI oder RUPT, you name it) liegt die besondere Herausforderung darin, stabile Strukturen und zuverlässige Planbarkeit mit den höchst volatilen Rahmenbedingungen zu vereinbaren.

Sofern man sich nicht in einem StartUp oder kleinem Team ohne nennenswerten organisationalen Kontext bewegt, sondern in einem bereits gewachsenen Umfeld mit tief verwurzelten Verzahnungen in allerlei Richtungen (Kunden, Fachbereiche, Operations, externe Partner, etc.) , steht die Frage nach der bestmöglichen Projektabwicklung stets ganz weit oben auf der Agenda. In dem daraus resultierenden Spannungsfeld stehen einander zwei – scheinbar – diametral unterschiedliche Fraktionen gegenüber:

Auf der einen Seite befinden sich die Verfechter konventioneller, fest strukturierter und bestens dokumentierter Unternehmens- und Projektführung. Die Grundlage ihrer Arbeit bildet im Kern ein penibel ausgearbeiteter Plan mit klarer Timeline, klarem Budget und klarem Lieferumfang. Der Kunde beauftragt einen vereinbarten Scope (Output) und bekommt diesen zu einem definierten Zeitpunkt zu einem fixen Preis geliefert.

Auf der anderen Seite befinden sich die „Agilisten“, die ihrerseits auf Modelle setzen, die der Zusammenarbeit ein Werte- und Prinzipiensystem zugrunde legen. Sie propagieren, dass mittel- und langfristige Pläne in komplexen Umgebungen in den seltensten Fällen vollumfänglich haltbar sind, da die laufend veränderten Rahmenbedingungen permanente Adaptionen und Weiterentwicklung der Prozesse erfordern. Sie stellen den Faktor Mensch, die Zusammenarbeit und den wertstiftenden Outcome stärker in den Fokus, langfristig unumstößliche Pläne und starre Gantt-Charts eher in der Hintergrund.

Betrachtet man diese beiden „Fronten“ aus äquidistanter Perspektive, könnten die vermeintlichen Unterschiede kaum größer sein. Wie soll es also möglich sein, die beiden Herangehensweisen unter einen Hut zu bringen?

Mein persönliches Postulat: Es ist außerordentlich simpel, die fälschlich als solche angenommenen Gegensätze miteinander zu verzahnen und „the best of both worlds“ in einem fruchtbringendem Miteinander zu nutzen und zur Geltung zu bringen.

Im Folgenden möchte ich auf die am weitesten verbreiteten Missverständnisse, dargebracht in knappen Zitaten, die ich im Laufe meines Arbeitslebens viel zu oft hören musste, eingehen.

„Agile ist eine Methode, ein Vorgehensmodell.“

Klares NEIN. Agile ist – ebenso wie LEAN Thinking, Kanban und viele weitere Konzepte – kein Prozess, keine Methodik, kein Arbeitsmodell. Agile ist eine Denkweise, ein Prinzipiensystem und eine Kultur, die sich an einem zugrundeliegenden Wertemodell orientiert. Welche Methode die geeignetste ist, um diese Werte leben und ihre Benefits „ernten“ zu können, ist abhängig vom Kontext.

In vielen Unternehmen oder Projekten – speziell im Software Development – ist Scrum aus unterschiedlichen Gründen das vermutlich passendste Framework, in manchen Bereichen wird vielleicht auch ein Waterfallderivat ganz gut funktionieren, anderswo ein flussbasiertes Kanban-System mit Pull- und WiP-Prinzipien. Und: Die Frage der Skalierung wird sich unweigerlich hinzugesellen.

Es gibt – so ungern ich Erwartungen enttäusche – kein „out-of-the-box“-Modell (weder in der Basis, noch in der Skalierung), das ohne Anpassungen für alle Unternehmen gleichermaßen optimal passt.

„Konventionelles Projektmanagement ist zu träge für zeitgemäße Softwareentwicklung und erlaubt keine Anpassung des Plans.“

Ein weiteres klares NEIN. Alle international bedeutsamen Standards (IPMA, PRINCE2, etc.) beinhalten Prozesse, die bei veränderten Rahmenbedingungen neuerliche Planung vorsehen und somit explizit ein zeitnahes „respond-to-change“-Prinzip lehren. Auch kontinuierliche Verbesserung und stetige Anpassung der Arbeitsweise ist in den meisten gängigen Standards enthalten (KVP, PDCA, etc.).

Die agil getriebenen Frameworks werden möglicherweise dank Kaizen-Fokus die Nase ein Stück weiter vorne haben bei der Weiterentwicklung, aber im Konzernumfeld stößt man hier schnell an seine Grenzen und findet sich bald auf einer „gemeinsamen“ Pace wieder.

Weiteres Indiz: Zahlreiche Rollenbeschreibungen, Aufgabenstellungen und erforderliche Tätigkeiten sind sowohl in agil orientierten Frameworks, als auch in Projektmanagementstandards lediglich in der Nomenklatur unterschiedlich, jedoch nicht in den relevanten Charakteristika, es ist somit augenscheinlich, dass die gemeinsamen Ziele – auch hinsichtlich Flexibilität in der Planung durchaus nah beieinander liegen.

„Mit iterativer Entwicklung kann ich jederzeit schrittweise Wert liefern.“

Im größeren Unternehmens- oder Konzernumfeld – leider – NEIN. Je dynamischer das Umfeld und je umfangreicher Dependencies, Systemlandschaften oder Architekturen anwachsen, desto aufwändiger wird das Ausliefern von Inkrementen in die Produktion. Die Lieferung von konkretem Wert am Ende jeder Iteration ist in solch komplexen Umgebungen bestenfalls an Nebenschauplätzen möglich.

Schnelle Hotfixes oder kleinere Adaptionen können bei optimal errichteter Delivery Pipeline durchaus direkt in Produktivumgebungen deployed werden, aber umfangreichere Releases erfordern fundierte Qualitätssicherung, sprich alle möglichen Spielarten von Integration-, Regression- und User Acceptance Tests. Darüber hinaus oft Koordination und Abstimmung zwischen unterschiedlichen Unternehmenseinheiten, Kommunikation an die Enduser, Schulungen und vieles mehr. In einem Sprint geht sich das alles natürlich nicht aus.

Ich möchte damit keinesfalls aussagen, dass große Halbjahresreleases oder auch quartalsregelmäßige Lieferungen die einzig denkbaren Lösungen darstellen und dass man kürzere Intervalle kategorisch ausschließen muss, aber in der gelebten Praxis kommt man zumeist nicht darum herum.

Aus Teamsicht sollte ein kontinuierliches Liefern (e.g. in eine pre-production stage) natürlich sehr wohl angestrebt werden, aber der Produktivgang, ergo die konkrete Auslieferung des Kundenwertes kann – oft: muss – sich der Realität anpassen. „Continuous delivery, release on demand“.

„Wasserfall und Agile schließen einander aus.“

Das nächste NEIN. „Waterfall“ (nach Winston W. Royce) ist zwar in seinen Grundfesten nicht auf kurze Iterationen aufgebaut und basiert auf linear ablaufenden Projektphasen, es bleibt aber vor allem eins: Ein Verfahrensmodell. Es ist kein Mindset, postuliert keine Prinzipien und impliziert vor allen Dingen keine Wertehaltung. Der Wasserfall und seine Variationen, allen voran das V-Modell („Waterfall with testing“) sind also – per se – keine zwingenden Antagonisten zu agiler Denkweise.

Zugegeben: Ich persönlich bin – speziell für längerfristig angelegte Projekte mit Durchlaufzeit über zwei, drei Quartale hinaus – kein sonderlich großer Fan des Wasserfalls, aber das bedeutet nicht zwangsläufig, dass eine gut etablierte agile Kultur keine in linearen Phasen ablaufenden Projekte erfolgreich zum Abschluss bringen kann. Auch hier gilt, dass die Umgebungsvariablen darüber entscheiden, welches Modell das geeignetste ist.

„In Agile gibt es keine zuverlässige Planung und keine verbindlichen Zusagen.“

Wie vermutlich erwartet: Schon wieder ein deutliches NEIN. Dieser Eindruck entsteht möglicherweise dann, wenn man ein agiles Development Team frägt, ob es in einem Zeitraum von mehr als einem Jahr einen fix definierten Funktionsumfang zu einem einzementierten Budget liefern kann und man als Antwort ein entschiedenes Schulterzucken erhält.

Das Team wird jedoch nicht mit „keine Ahnung“ antworten, weil es sich nicht mit der langfristigen Planung beschäftigen will oder eine verbindliche Zusage verweigern möchte, sondern weil es – völlig korrekt – über einen solchen Zeitrahmen nicht zuverlässig prognostizieren kann(!). Es ist empirisch außerordentlich stabil untermauert, dass komplexe Softwareentwicklung in einem mittleren bis größeren Zeitraum nur mit großer Unschärfe vorhersagbar ist.

Die Gründe für diese Unschärfe sind mannigfaltig: Herstellerseitig abgekündigte Softwarekomponenten, neue legistische Vorgaben, Anpassungen bei Umsystemen und deren Schnittstellen, Know How-Volatilität in den Teams aufgrund Personalfluktuation, Veränderungen der Anforderungen seitens der Kunden und viele mehr.

„Agile Teams“, die diese Bezeichnung tatsächlich verdienen, werden sich stets vollumfänglich dazu committen, das ihnen Bestmögliche dazu beizutragen, ihren Kunden zum vereinbarten Termin den größtmöglichen Funktionsumfang in höchstmöglicher Qualität zum bestmöglichen Preis zu liefern. Und das alles mit umfassender Transparenz über Status, Fortschritt und Ausblick.

Ein fixer Scope mit fixem Termin zu fixen Kosten ist jedoch in komplexen Umgebungen schlichtweg unmöglich. Das Commitment zur Erfüllung des maximal erzielbaren Customer Values an sich bleibt davon unberührt – und ist prinzipiell auch in den gängigen „konventionellen“ Projektmanagement-Standards einer der Grundpfeiler.

Grundbedingung ist natürlich, dass man sich auf Outcome und nicht auf Output fokussiert.

„Projektmanager arbeiten mit Zahlen, Agilisten mit Menschen.“

Selbstverständlich auch hier ein definitives NEIN. Einerseits deshalb, weil Menschen mit ausgeprägtem agilen Mindset meist auch ein nahezu hingebungsvolles Verhältnis zu KPIs, messbaren Outcomes und konkreten – auch quantitativen – Zielen (Stichwort: OKR) haben. Andererseits deshalb, weil Projektmanagementexpert*innen ebenso den Faktor Mensch und die sozialen Interaktionen nicht nur in ihre Planungen einbeziehen, sondern diese auch nach Kräften fördern.

Selbstverständlich muss bei Erstellung einer Baseline für den Projektplan ein Wert für „Kosten“ und die verursachenden „Ressourcen“ (sprich: beteiligte Personen) kalkuliert werden, aber dies ist auch in der Erhebung der meisten KPIs aus der „agilen Ecke“ relevant. Die Velocity eines Teams errechnet sich anhand der Kapazitäten der Mitarbeiter*innen, Fertigstellungsprognosen basieren auf Teamgrößen und deren Kollaboration.

Ein Projektleiter, der die zwischenmenschlichen Interaktionen in seinem Projektteam außer Acht lässt, wird sehr schnell sowohl den Ein-, als euch den Überblick verlieren. Ein Agile Coach, der keine Zahlen erhebt, auswertet, interpretiert und entsprechend Aktionen setzt, kann keinerlei Weiterentwicklung in Sachen Zusammenarbeit, Kultur und Methodik erreichen.

Die Aufbauorganisation hinter den Teams benötigt sowohl das Commitment der handelnden Personen, als auch die KPIs, Zahlen und Bewertungen – und das völlig unabhängig vom jeweiligen Wertsystem oder Vorgehensmodell.

„Agilisten sehen nicht das große Ganze, verstecken sich hinter in der Methodik.“

An dieser Stelle auch keine Überraschung: NEIN. Der Fokus einiger Rollen in agilen Teams liegt naturgemäß in der Arbeit mit Teams und den miteinander arbeitenden Menschen in diesen Teams. Die Denkweise und die Prinzipien gehen aber selbstverständlich weit darüber hinaus.

Agile Werte und Prinzipien sind grundsätzlich organisationsweit gedacht und entfalten auch nur ihre volle Wirkung, wenn sie über alle Teams, Bereiche, Hierarchien, Strukturen bis hin zur Einbindung der Kund*innen (Endanwendende) hinweg verfolgt oder sogar gelebt werden. Valueorientierung, Kundenzentrierung, Transparenz, Qualitätsbewusstein und alle anderen gemeinsamen Werte bis hin zur kontinuierlichen und unablässigen Weiterentwicklung sind entweder Organisational Values – oder sie sind gar keine.

Fazit

Sobald im Kontext von Verfahrensmodellen und Mindsets von „zwei Welten“ gesprochen wird, beginnt man bereits, sich selbst proaktiv Steine in den Weg zu legen, die erschreckend schnell zu Impediments und schlussendlich zu immer schwieriger zu überwindenden Barrieren heranwachsen, wenn man nicht beherzt genug einwirkt.

Die in Details unterschiedlichen Herangehensweisen beziehen sich oft, wenn nicht meist nur auf die jeweiligen Wirkradien der einzelnen Rollen. Mit geschickt gestalteten und stabil etablierten Anknüpfungspunkten ist diese Herausforderung in aller Regel schnell vom Tisch.

Die gemeinsamen Ziele und Visionen, an denen sich die Organisation orientiert, sind das, was alle handelnden Personen eint.

Sobald wir uns darüber im Klaren sind, gibt es keine „zwei Welten“, sondern „ein Team“.

 

(Bild: James Dignan, cc by-sa 3.0)