Klassisches-undagiles Projektmanagementsind beides Methoden, die das gleiche Problem zu lösen versuchen und dabei auf ganz unterschiedliche Narrative setzen.

„Hurra, ich habe gleich mal das hippe Wort „Narrativ“ untergebracht.“

Das rührt daher, dass beide in ganz unterschiedlichen Umgebungen „gewachsen“ sind, also genau dann zum Einsatz kommen, wenn bestimmte Voraussetzungen erfüllt sind. Ich will hier gar nicht sagen, dass klassisches Projektmanagement (oft vertreten durch das Wasserfall-Modell)alt ist und agiles Projektmanagement (meist Scrum)neuund modern ist. Klassisches Projektmanagementals Methodik hat nicht ausgedient, weil es was Neues gibt, sondern weil die Umgebung, in der siesehr erfolgreich sein kann,heute nicht mehr oft vorhanden ist.

In diesem Artikel geht es auch nicht darum, klassisches Projektmanagement bzw. das Wasserfall-Modellschlecht zu machen und agiles Projektmanagement bzw. Scrum in den Himmel zu heben, sondern klarzumachen, dass beide Konzepte fundamental anders sind und damit nicht gut kombiniert werden können.

Leider ist dies aber eine in der Praxis sehr häufig auftretende Strategie, die nur sehr selten erfolgreich ist. Es geht mir hier darum zu begründen, warum sie nicht kompatibel sind, und welche Gefahren lauern, wenndennoch versucht Elemente aus dem klassischen Projektmanagement in eine agile Umgebung zu bringen.

Auch auf die Gefahr hin, dass Bilder immer etwas riskant sind, möchte ich anhand des Bildes „Kreisverkehr mit Ampelschaltung“ erläutern, warum das Mischen beider Konzepte ziemlich sicher einen Verlierer hervorbringt: Sie.

Ampelschaltungen haben eine sehr große normative Wirkung, Kreisverkehre setzen mehr auf eine Selbstregulierung des Verkehrs durch eine gewisse Selbstorganisation der beteiligten Verkehrsteilnehmer. Selbstorganisation bedeutet mitnichten die Abwesenheit von Regeln. Auch ein Kreisverkehr folgt klaren, eindeutigen und nicht verhandelbaren Regeln. Aber der normative Charakter des Gesamtkonzeptes ist nicht so ausgeprägt, wie der einer Ampelschaltung. Es lässt dem Verkehrsteilnehmer gleichermaßen mehr Freiheit und mehr Verantwortung. Er darf fahren, wenn der Kreisverkehr frei ist. Was „frei“ bedeutet, liegt in seinem Ermessen, d.h. solange er keinen anderen Verkehrsteilnehmer behindert oder gefährdet, darf er fahren. Wieviel Platz das genau bedeutet, ist nicht präzise festgelegt. Anders bei der Ampelschaltung.

Sie sagt dem Fahrer nicht nur, wann er nicht fahren darf, sondern auch wann er fahren darf. Und dies ist Situationsunabhängig, bzw. die Ampelschaltung führt die Situation selbst herbei.

Sie greift damit stärker in den Verkehr ein und entfaltet damit eine höhere normative Wirkung, in dem sie alle Interpretationsspielräume weitgehend eliminiert. Daraus folgt, dass auch dann nicht gefahren werden darf, wenn die Kreuzung frei, aber das Signal noch rot ist. Das ist Micro Management.

Man kann es auch anders ausdrücken. Eine Ampelschaltung ist eine proaktive Regelung, während ein Kreisverkehr reaktiv regelt. Proaktiv bedeutet, dass eine Ampelschaltung auch dann noch den Verkehr regelt, wenn es gar keinen Bedarf gibt, jedem Verkehrsteilnehmer wird explizit gesagt,

„jetzt darfst Du fahren, jetzt nicht“.

Jeder, der wie ich einst an einem winterlichen Sonntagmorgenum 4:30 Uhran einer verlassenen Kreuzung stand und gefühlte 5 Minuten (wahrscheinlich waren es real nur 45 Sekunden) auf Grün wartete, versteht was gemeint ist. Die Regeln des Kreisverkehrs greifen hingegen nur dann ein, wenn ein Bedarf durch mehrere sich im Kreisverkehr befindliche-und neu einfahrende Fahrzeuge entsteht. Ansonsten gilt hier immer freie Fahrt.

Wenn nun beides gemischt werden würde, dann gewinnt immer das normativere System, also die Ampelschaltung schlägt das Kreisverkehrsprinzip. Die normative Wirkung der Ampelschaltung überlagert vollständig die Selbstorganisation des Kreisverkehres. Ober schlägt Unter, könnte man sagen.

Das Prinzip der Selbstorganisation wird sich nicht mehr entfalten können und alle damit verbundenen Vorteile kommen nicht mehr zum Tragen. Es mag Situationen geben, da haben Ampelschaltungen Vorteile gegenüber Kreisverkehren und umgekehrt aber eine Mischung verträgt sich in den allermeisten Fällen nicht. Ich habe das an einem Kreisverkehr mit Ampelschaltung -der Einzige, der mir bekannt ist – beobachtet.

Selbst im Berufsverkehr, wo der Verkehr wesentlich in eine Richtung läuft, hält die Ampelschaltung den Verkehr eher auf, natürlich zugunsten von Verkehrsteilnehmern, die aus einer anderen Richtung kommen und sonst sehr lange warten müssten, um in den Kreisverkehr hineinzufahren. Eine Art Minderheitenschutz wird so gewährleistet. Aber man nimmt dabei in Kauf, dass der Gesamtverkehrsfluss gebremst wird. Kaum vorstellbar, dass dieses Verfahren alternativlos ist.

Eine kleine Umleitung der bedrohten Minderheit aus der ungünstigen Richtung wäre vermutlich der bessere Ausweg, als täglich den Berufsverkehr lahmzulegen, sogar eine vorgeschaltete Ampel, wie sie inzwischen oft vor Tunneln eingesetzt wird, wäre vermutlich wirksamer.

Um aus dem Bild zurück zu unserem Problem zu kommen; es wäre also denkbar bestimmte Aufgaben aus dem agilen Projekt auszulagern und in ein klassisches Projekt zu platzieren. Für agile Projekte ist die Zusammenarbeit mit anderen Projekten in externen Organisationen, wo sie keinen Einfluss auf deren Methodik haben, durchaus der Normalzustand und damit kein Problem. Ein Problem wird es, wenn das betreffende agile Projekt selbst durch klassische Methoden manipuliert wird. Es sind dann oft drei Dinge, die zuerst aus dem klassischen Projektmanagementdem agilen Projekt hinzugefügt werden.

Zusätzliche Statusmeetings

Statusmeetings sind ein typisches Werkzeug klassischem Projektmanagements und setzen voraus, dass alles bereits perfekt geplant ist (und damit planbar war). Im Gegensatz dazu verwendet agiles Projektmanagement das Instrument von Planungsmeetings. Viele sind verwundert, wenn sie hören, dass wir in der agilen Welt permanent planen.

Planung wird eher als ein Charakteristikum im klassischen Projektmanagement verortet, aber das ist ein Irrtum. In der Tat enthält jedes agile Meeting eine Planungskomponente, das gilt nicht nur für die offensichtlichen PI (SAFe)-oder Sprint-Plannings, sondern auch für weniger offensichtlichen Meetings wie Daily-Standups (wir planen den heutigen Tag), Sprint Reviews(Inspekt & Adapt Session) und Retrospektiven (wie können wir die Arbeit des Teams künftig verbessern), usw..

Statusmeetings hingegen, also in der Regel das Berichten an eine in der Hierarchie höher gestellt Instanz über das, was bisher geschah, sind nichtsehr förderlich für die Selbstorganisation von Teams und oft eine Folge der Rück-Delegation von Verantwortung, bzw. ebnen sie dieser den Weg.

Zusätzliche Rollen

Zusätzliche Rollen, sollen die Teams entlasten, die Kommunikation bündeln und klare Verantwortlichkeiten regeln. Leider bewirken sie in agilen Teams genau das Gegenteil. Sie führen die Verantwortung von den Teams fort, hemmen die Selbstorganisation von Teams und schaffen Bottle-Necks.

Das Einführen von Release-Managern, Test-Managern, Lead-Architekten, Technology-Evangelisten oder Support-und Ops-Managern zerstören oft das zarte Pflänzchen einer DevOps-Kultur, noch bevor die Organisation verstanden hat, was damit im besten Sinne bezweckt wird. All diese Rollen erhalten Verantwortung, die vorher beiden Teams gelegen haben, mit jeder neuen Rolle potenziert sich die Zahl von Abhängigkeiten zwischen FeatureTeams und der Rolle und den Rollen untereinander.

Sollte eine Rolle nicht da sein, oder nicht schnell genug reagieren, entsteht sofort ein Entscheidungsstau. Überdies verlieren die Teams schnell die Motivation, Entscheidungen selbst zu treffen oder irgendeine Art von Verantwortung zu übernehmen. Da aber die Teams und nur die Teams die Quelle der Wertschöpfung sind, kann man sich leicht vorstellen, was jetzt passiert. Bei jedem Problem hebt das Team die Hände und verweist auf irgendeine Rolle als Verantwortliche. Wollen Sie es wirklich dazu kommen lassen?

Zusätzliche KPI bzw. klassische Projekt KPI

In der Tat gibt es im agilen Projektmanagement gar nicht so viele Dinge, die nach einer Zahl aussehen und damit für KPI taugen. Klassischen Projektmanagern war das schon immer ein Dorn im Auge, weil KPI Transparenz herstellen und Steuerung ermöglichen. Ohne KPI keine Steuerung. KPI erfordern aber eine stabile Grundlage und natürlich Benchmarks gegen die sie gemessen werden können. Projektfortschritt im Vergleich zum geplanten Budget und der geplanten Zeit, dazu das allseits beliebte Gantt-Chart. Solche KPI sind leicht zu erheben und präzise zu messen.

Aber wie sieht es mit agilen KPI wie Velocity, Sprint Accuracy, Product Burnup, Customer Satisfaction, Business Value etc. aus?

Sie sind schwieriger zu erheben, müssen mehr interpretiert werden und sind in der Regel komplexer. Zusätzliche KPI aus dem klassischen Projektbaukasten erfordern oft das Schaffen eines stabilen-und eben nicht mehr agilen Umfeldes. Es wird dann zunehmend doch wieder die Illusion gepflegt, man würde den Scope vollständig kennen und durcheine Expertenschätzung den dafür benötigten Aufwand bestimmen können. Die Enttäuschung lässt in der Regel nie lange auf sich warten, der Schaden für die agile Kultur allerdings nur schwer beheben.

In Kombination ergeben sie das, was von den Akteuren des Gesamtprojektes als Micro Management wahrgenommen wird. Und diese kompromittieren (um nicht noch drastischere Begriffe zu verwenden) über kurz oder lang – meist geht es leider sehr schnell – den agilen Charakter eines Projektes. Warum?

Weil sie eine viel höhere normative Wirkung entfalten, und damit das Allerheiligste agilem Projektmanagements überlagern: die Selbstorganisationskräfte agiler Teams und das Bewusstsein für Accountablility und Ownership der Akteure.

Sollten diese Maßnahmen jedoch noch nicht geholfen haben, und sie werden nicht helfen, dann folgen in der Regel ein paar weitere Maßnahmen, die oft den letzten Rest agiler Methodik und agilem Mindset abräumen.

Task-Forces, manchmal auch Plattform-Teams, Querschnittteams oder Technologie-Teams genannt

Task-Forces sind oft der hilflose Versuch, Probleme zu lösen, die agile Teams, die durch die oben beschriebenen Maßnahmen bereits geschwächt sind, nicht mehr zu lösen in der Lage sind. Meist verschlimmern sie die Lage noch, da jetzt zu allem Unglück auch noch die besten Leute aus den Feature-Teams abgezogen werden und in ein Task-Force Team zusammengesteckt werden. Es muss nicht erwähnt werden, dass solche Teams in der Regel keine agilen Teamssind, manchmal haben sie noch ein Kanban-Board, oft nicht einmal das.

Damit wird die Handlungsfähigkeit der agilen Feature-Teams noch weiter eingeschränkt. Dadurch, dass die Teams damit auch noch zu Teams zweiter Klasse degradiert werden, steigt auch nicht gerade die Motivation. Plattform-, Querschnitts-, oder Technologie-Teams schaffen zunächst mal Abhängigkeiten zu den Feature-Teams, ähnlich wie die oben beschriebenen zusätzlichen Rollen.

Wenn diese „horizontalen“ Teams dann auch noch „agil“ sind, also eine eigene Agenda entwickeln, wird die Sache sogar eher noch schlimmer. Die Teams finden sich in einem Geflecht von wechselseitigen Abhängigkeiten, die zu einer weiteren Reduktion der Velocity nun aller Teams führt. Dabei sollte nicht vergessen werden, dass nur die Feature-Teams tatsächlich Business-Value, also Wertschöpfung generieren.

Hinzufügen weiterer Ressourcen zu Teams (beide oft auch in Kombination)

In Hamburg sagen wir ja, man sollte schlechtem Geld nicht gutes hinterherwerfen. Aber genau das passiert jetzt. Der letzte Versuch, das Projekt zu retten, besteht oft darin, in einer solchen Situation noch weitere Ressourcen aufzutreiben und in die Teams zu geben. Eben diese Teams, deren Velocity durch zu viele Player, Verantwortlichkeits-Wirrwarr und wechselseitige Abhängigkeiten geschwächt ist. Die Teams werden jetzt zu allem Unglück auch noch aufgeblasen, müssen neue Leute onboarden und müssen sich vollgestopft jetzt auch noch mit sich selbst beschäftigen. Man braucht nicht viel Fantasie, um sich das jetzt stattfindende Geldverbrennen bildlich vorzustellen.

Und schließlich das schrittweise auflösen agiler Strukturen

Das Timeboxing wird oft früh geopfert unter dem Hinweis, man konzentriert sich jetzt auf die Deadline und führt besserein Kanban-Verfahren ein (das hat wenigstens noch einen agilen Anstrich). Damit gehen alle agilen Planungsgrundlagenverloren. Man begibt sich jetzt vollständig in den Blindflug. Das Prinzip Hoffnung fängt jetzt an zu regieren. Organisationenkönnen gar nicht so schnell frisches Geld besorgen, wie ihnen die Kosten um die Ohren fliegen.Natürlich ist das Bild etwas überzeichnet. Aber ist es wirklichganz weit weg von der Realität? Ich habe zumindest einige Organisationen gesehen, die sich genau hier befinden, sich die Situation aber eher noch schönreden, die Standardausrede:

„Die Kosten sind dergestiegenen Komplexität irgendwie angemessen. Immerhin sind wir ein agiles Projekt“.

Ja, zu allem Übel wird nach all dem der Schuldige auch noch in der gewählten agilen Methodik verortet, klingt fast wie Hohn, ist aber leider oft Realität.

Aber im Grunde ist es doch eine Demonstration, wie in agilen Projekten mit wenigen falschen Entscheidung sehr schnell sehr, sehr viel Geld verbrannt werden kann. Wenn Sie nicht in diese Falle tappen möchten, gewöhnen Sie sich früh an, Probleme in agilen Projekten mit agiler Methodik zu bekämpfen. Denn an irgendeiner Stelle ist das agile Setup noch nicht perfekt eingesetzt, oder kann sich nicht richtig entfalten. Nach diesen Stellen müssen wir suchenund sie konsequenter bearbeiten. Oft braucht es nur mehr Vertrauen in die agile Methodik, neben viel Erfahrung und Wissen natürlich.