Warum es kein agiles Projektmanagement gibt! Dritter und letzter Teil einer kritischen Auseinandersetzung.

Flexibles Denken als Erfolgsfaktor

Mit dieser dreiteiligen Artikelserie vertrete ich den Standpunkt, dass es kein „agiles Projektmanagement“ gibt. Zwar setze ich mich kritisch mit dem Thema „agiles Projektmanagement“ auseinander, jedoch stehe ich agilen Methoden, insbesondere Scrum, keinesfalls negativ gegenüber. Was übrigens auch für Leanmanagement zutrifft, oder „Water-Scrum-Fall“ (Hybridmodell). Diesbezüglich bin ich gleichzeitig der Meinung, dass kritisches Denken ein wichtiges Instrument zur Optimierung unserer Methoden ist. Das mit gutem Grund. Der schlimmste Feind eines Freelancers ist wohl eine verkrustete Denkstruktur. Persönlich ist mir ein klarer Blick auf die Anforderungen der Auftraggeber besonders wichtig. Methodenverliebtheit und/oder eingefahrene Sichtweisen stufe ich als erfolgskritische Faktoren ein. Unseren Kunden so rasch wie möglich Businessnutzen zu liefern, sollte für jeden von uns oberste Priorität haben. Die Kundenanforderungen sowie die situative Generierung der adäquaten Herangehensweise für das jeweils spezielle Problem des Kunden sind wohl die wichtigsten „Methoden“ überhaupt!

Nur Falsifizierung führt zu neuen Erkenntnissen. (Karl R. Popper)

Daher sind mir Methodengurus und einseitige Beratungen äußerst suspekt. Die eigenen Best Practice Erfahrungen situativ auf das jeweilige Kundenbedürfnis umzumünzen, stellt für mich d e n zentralen Erfolgsfaktor dar. Handelt es sich dabei vielleicht schon um „agiles Projektmanagement“? Oder ist das doch eher Expertenwissen, das durch gesunden Hausverstand geleitet wird? Ich zitiere aus einem Blogartikel vom 22.04.2016 (next level consulting):

Agiles Projektmanagement bringt neue Arbeitsweisen mit sich. Die Teams arbeiten selbständig, sie bestimmen selbst über Vorgehen und Organisation. Sie brauchen keinen klassischen Projektmanager, der die Mannschaft wie ein Kapitän lenkt. Ähnlich können sich auch bei anderen „Mitspielern“ angestammte Aufgaben und Zuständigkeiten verändern; sie finden neue Rollen und Tätigkeiten. Beispiel Projektmanager: Einige vertreten das Projekt nach außen und halten die Verbindung zu Kunden oder Partnern. Andere verstehen sich als Coach, beraten das sich selbst organisierende Team und vermitteln etwa bei Konflikten.

Lockvögel der Missverständnisse

Bei agilen Ansätzen, scheint mir die Idee des variablen Scopes ein bunter Lockvogel der Missverständnisse zu sein. Zwar kann bei Infrastrukturprojekten (Server-Infrastruktur, Server-Interfaces, Datenbanken, EAI, Frontend,- und Backendsysteme), Interfaces zu Applikationen, Portalen, Mainframes, etc. mittels agilen Methoden zweifellos schnell Businessnutzen gestiftet werden. Zumal bedeutet etwa agile SW-Entwicklung nicht gleichzeitig im Kostennirvana der Softwareentwicklungsprojekte angekommen zu sein. Schon gar nicht „agiles Projektmanagement“ zu betreiben. Die Variabilität des Scops heißt sicher nicht, dass der Auftraggeber für weniger Kosten mehr Funktionalitäten, Services, etc. bekommt. Agile Entwicklung liefert im best case raschen Businessnutzen, der umgerechnet auf Faktoren wie Durchlaufzeiten, optimierte Prozesse oder optimiertes Durchsatzvolumen die Businesszahlen positiv beeinflussen kann. Momentan herrscht eine Adaptionswut bei Scrum vor, die zumeist nicht funktioniert. Selbstverständlich kann ich unterschiedliche Methoden in einem Projekt/Programm anwenden, jedoch ist es zwingend notwendig, dass die jeweils angewandthe Methode sauber eingesetzt wird. In einem Projekt von mir waren durch Orders by Mufti die Aufwandsschätzungen zu vernachlässing, da der „variable Scope ja eh alles ausgleiche“. Alle unsere Bemühungen dem entgegenzuwirken fruchteten nicht. Eine Daumen mal Pi Estimation funktioniert im Scrumdevelopement noch weniger als sonst wo, da gerade Scrum sehr strikte Vorgaben der Prozesse, Rollen und Struktur vorgibt (vgl. dazu meinen Artikel 1). Das Gesamtprojekt mit mehreren Streams, davon zwei Scrumfactories, die wesentliche Produktservices zu liefern hatten, retteten wir nur durch effektives Controlling und extrem harter Priorisierung – und intensivem Stakeholdermanagement.

Buzzword des Marketings

Grundsätzlich ist jede der agilen Methoden wie XP, Scrum, Feature Driven Developement oder  Dynamic Systems Developement Method als Software Developement Method entwickelt worden. Demgegenüber stehen das V-Modell und Wasserfallmodell als sogenannte „klassische“ Ansätze. Mein Eindruck ist, dass der Begriff „agiles Projektmanagement“ ein Buzzword für Marketingzwecke ist. Die International Association of Project Managers (IAPM) bietet beispielsweise eine agile Projektmanager-Zertifizierung an. Prüfungsstoff sind Scrum, Kanban und XP. Mit der Zertifizierung bestätigt man in agilen Methoden fit zu sein. Schlechterdings klärt die Zertifizierung die Rolle eines „agilen Projektmanagers“ auch nicht detailiert (vg. w. o. das Blogzitat). In XP steht die Selbstorganistion an wichtigster Stelle. Costumers, programmers und testers bestimmen die Entwicklung. Situativ kann jeder den Lead bei einer Problembehandlung übernehmen, jedoch gibt es keine Leaderrolle per se. Kanban ist der Überzeugung, dass jeder der das Kanbanprinzip versteht ein Kanbanteam leaden kann. Hingegen gibt es in Scrum absolut keine definierte Rolle „Projektmanager“.

Die Realität des Freelancermarktes

In den letzten Wochen analysierte ich auf mehreren Freelancer-Portalen Ausschreibungen zum Thema Agilität. Das Ergebnis dieser Ad Hoc Analyse zeigt, dass derzeit 25% aktueller Bedarf an agilen Experten im deutschsprachigen Raum besteht (n= 100). Diese Mandatsausschreibungen referenzieren zu 60% Scrum-Expertise, 15% Kanban-Expertise und 20% XP-Expertise. Ausschreibung der dezitierten Skillanforderung „agiler Projektmanager“ konnten 3% kategorisiert werden. Der Rest konnte von mir nicht zugeordnet werden, da die Angaben sehr unklar waren. Die 3% Ausschreibungen für „agiles Projektmanagement“ benötigen zumeist Expertise in agilen Methoden, agiles Consulting und agile Expertenrollen. Der PM sollte hierzu Erfahrung mitbringen. Jedoch aber gibt es kein explizites Anforderungsprofil für einen „agilen Projektmanager“. Insgesamt wurden fachspezifische Kenntnisse, wie Scrum Master, Product Owner, agiler Businessanalyst oder agiler Entiwckler sehr deutlich nachgefragt. Dieses Ergebnis sollte an sich ja folgerichtig sein, da es die Rolle agiler Projektmanager nicht gibt. Ein Scrum Projektmanager wäre überhaupt ein sogenannter ScrumBut, d. h. eine Adaption die erfolgsverhindernd auf den Projekterfolg wirkt.

Scrum of Scrums oder Nexus (Scaling Scrum)?

Viele Beratungsunternehmen machen den Kunden jedoch glauben, dass agiles Projektmanagement tatsächlich existiere. Ein intensiverer Blick auf die Homepages zeigt sehr rasch wo der Hase im Pfeffer liegt. Selbstversändlich werden einzelne agile Methoden so dargestellt wie sie zu funktionieren haben. In den Erklärungen war natürlich keine Rede mehr von agilen Projektmanagern. So gibt es selbst in großen Scrum-Projekten natürlich keine Projektmanager. Die agile Entwicklungs-Organisation wird über SoS (Scrum of Scrums) abgebildet und gesteuert.

Scrum of Scrums

SoS
Scrum of Scrums: Source, Mountain Goat Software, 2016

Eine neuere Entwicklungen von Ken Schwaber ist das Nexus Modell. Ken Schwaber bezeichnet es als exoskeletton für die Value Driven Koordination von mehreren Scrumteams (ab ca. 9) die geografisch verteilt sind. Es geht um  Abhängigkeiten und Zusammenspiel zwischen den Scrum Teams. Es soll in jedem Sprint mindestens ein integriertes „Done“ Inkrement ausgeliefert werden. Wenn Softwareentwicklung mit Scrum skaliert wird, sollten diese Abhängigkeiten von Anforderungen, Domänewissen und Code-/Testartefakten die Teamorganisation leiten, um die Produktivität auf hohem Niveau zu halten, oder zu optimieren.

Nexus Framework

 

nexus
Nexus Framework: Source, scrum.org, 2016

Das Nexus Modell basiert auf Scrum und wurde von Ken Schwaber entwickelt. Nexus (n) ist eine Bezeichnung für die „Unit of developement“. Das Framework zielt auf Basis von Scrum als „building block“ darauf ab, große Abteilungen in der Softwareentwicklung und Produkteinführungen skalierend zu unterstützen. Rollen, Zeitverlauf, Artefakte und angewandte Methoden werden angewandt, um drei bis neun Scrum Teams die Arbeit an einem Product Backlog zu ermöglichen (Scaled Scrum).

Klare Worte sind gefragt

Meines Erachtens ist das derzeitige Voranschreiten agiler Methoden in der D/A/CH Region mehr als begrüßenswert. Entwickelt man ein spezielles KPI-Set für den systemimmanenten Scrumkreislauf auf Basis eines Businesscases, ist dies der erste wichtige Schritt, um ein Scrumdevelopement erfolgreich über die Bühne zu bekommen (vgl. dazu Artikel 2). Der zweite, ebenso wichtige Schritt, ist die Einhaltung des auf best practice beruhenden empfohlenen Frame der einzelnen agilen Methoden. Andernfalls verwickelt man sich in die Fallstricke der ScrumButs. Häufig wird so getan, als ob man sich als Freelancer aussuchen könnte, welche Methoden man anwenden kann. Das Gegenteil ist eher die Alltagspraxis. Einzig und allein die Wunschvorstellung sowie die Anforderung unserer Kunden sind alles bestimmend. Die Aufgabe von uns Experten ist es, unsere Expertise adäquat anzupassen. Übrigens gibt es ja kein „reines“ Projektmanagement (mehr). So weit ich sehe muss ein PM heute zumindest ein, zwei On Top IT-Fachskills mitbringen, um Aufträge lukrieren zu können. Aber auch ohne kaufmännisches Verständnis und der Fähigkeit Business Cases zu rechnen, hat man es schwer. So fordert gerade Scrum von der Product Owner Rolle, „the voice of the costumer“ zu sein, was den Business Case impliziert. Gleichzeitig ist Flexibilität und stressfreier Umgang mit Dynamiken in den Projekten gefragt. Bezogen auf ein Scrumdevelopement bedeutet dies, dass die All Over-E2E-Betrachtung der dritte wichtige Schritt für eine erfolgreiche Umsetzung ist. Möchte der Kunde etwa einen Online Sales Channel via Scrum entwickeln, aber einige Komponenten bei einem Vendor bestellen der im V-Modell arbeitet, dann muss ein high level PM die Fähigkeit mitbringen, diese unterschiedlichen Dynamiken zu steuern. Ich kann nämlich nicht erkennen, dass Enterprises auf „Scrum total“ umsteigen. Vielmehr ist Alltagspraxis eher so, dass in den Projekten parallel mit Agilität, Leanmanagement und unterschiedlichen anderer Developementmethoden gearbeitet wird. Unsere zentrale Aufgabe dabei ist es, ScrumButs und unnötige Risks zu vermeiden, sowie die Kosten im Griff zu haben!