Die Kunst der Illusion: Anforderungsstreuung

Die Serie "Kunst der Illusion" zeigt Praktiken und Methoden des Projekt- und Produktmanagements und unterstellt Strategien zur Täuschung von Stakeholdern. Heute zeige ich, wie mit verteilten Aufgaben-Container Stakeholder-abhängige Zusagen gemacht werden...

Vorwort: Alles nur Illusion!

Die Idee der Artikelserie „Kunst der Illusion“ ist es, teils bekannte und verbreitete Methoden aus dem Projektalltag der Softwareentwicklung unter die Lupe zu nehmen. Dabei wird unterstellt, dass sich hinten den – nach besten Wissen und Gewissen – praktizierten Methoden trügerische Absichten verbergen, um Stakeholder und andere Projektmitarbeiter bewusst zu täuschen. Auf einen ironischen Unterton wird dabei explizit verzichtet. Durch die überzogene und positive Auslegung der vorgestellten Praktiken soll der Unsinn jener hervorgehoben werden und zum Reflektieren anregen.

Die Serie widmet sich in erster Linie an Product-Owner, ist aber durchaus für jeden Agile Engineer unterhaltsam.

Teile und herrsche

teileundherrscheDie Anforderungsstreuung ist ein effektives Mittel, wenn der bevorstehende Release-Termin unrealistisch wird und nicht mehr zu halten ist. Ist diese Erkenntnis gegeben, ermöglicht die Anforderungsstreuung dem Projektleiter, Produktmanager oder Product-Owner das Projekt über einen längeren Zeitraum durch vermeintlich ruhige Gewässer zu manövrieren. Durch das „unter den Teppich kehren“ kann das Projekt ohne unangenehmen Entscheidungsdruck oder Bevormundung jeglicher Art erst einmal weitergeführt werden. Es läuft…

Wenn der Termin nicht haltbar ist

Ist ein Release-Termin nicht mehr zu halten, bleiben dem Projekt-Verantwortlichen in der Regel zwei Möglichkeiten:

  • den Scope so anpassen, dass dieser wieder „in den Termin passt“, oder
  • den Liefertermin verschieben

Scope kürzen

Den Scope zu kürzen, um den Termin zu halten, entspricht der agilen Vorgehensweise, bedingt allerdings eine vernünftige Priorisierung der Anforderungen – schließlich soll bei den unwichtigen Sachen gekürzt werden.

Liefertermin verschieben

Priorisierung fällt in vielen Projekten schwer, zumal die Meinung vorherrscht, der Scope könne nicht modifiziert werden. Daher wird versucht, den Termin zu verschieben, um den vertraglich festgelegten Anforderungskatalog durchzubringen.

Die Wahrheit ist unbequem

unbequemJe früher die Erkenntnis zur Verschiebung des Release-Termins, desto unangenehmer empfinden dies einige Projekt-Verantwortliche. Diese Erkenntnis kann schnell als persönliches Versagen empfunden werden, seien denn bereits in der Planung Fehler gemacht worden. Dem Anschein nach: Fehler des Projekt-Verantwortlichen.

Daher ist es nicht verwunderlich, dass die Offenbarung dieser Erkenntnis zunächst zurückgehalten wird. Eine Folge von transparenter Kommunikation könnte sein, dass sich Vorgesetzte einschalten und in kommender Zeit genauer auf das Projekt sehen, oder dem Projekt-Verantwortlichen komplett die Verantwortung und damit Führung entzogen wird.

Wie erfinderisch die Phantasie und Angst an dieser Stelle auch sein mag – es ist alles Spekulation.

Die Entscheidung zur Illusion

Die Entscheidung liegt daher nahe, weiter mit voller Kraft auf den Release-Termin zuzusteuern. Vielleicht geschieht – so etwas wie – ein Wunder!

Mir erweckt sich der Eindruck, als könne mit (angeblichen) „Überraschungen kurz vor dem Release“ besser umgegangen werden, als mit frühzeitig, vorausschauend erkannten Engpässen. Die Verantwortung (respektive „Schuld“) scheint sich dadurch zu verlagern. Vielleicht ist zum Beispiel das Team zu langsam, oder der Sommer überrollte das Projekt mit einem urlaubsbedingten Kapazitätsengpass. Geschickt eingefädelt kann der Projekt-Verantwortliche zusätzlich als Interim-Krisen-Manager punkten, indem durch teils hart einschneidende Maßnahmen das Ruder doch noch herumgerissen wird.

Ein selbstbelohnendes System! Damit es funktioniert muss über einen längeren Zeitraum eine Illusion aufgebaut werden. Die Anforderungsstreuung ist dafür geeignet!

Wer Streut wird ernten

Zunächst müssen alle Stories, Anforderungen, Aufgaben, Aktionen, Todo’s, etc. in verschiedenen Containern dokumentiert und festgehalten werden. Typischerweise haben sich mehrere Excel-Arbeitsblätter, Briefablagen, E-Mail Postfächer und ein mit Klebezettel geführtes Kanban-Board im eigenen Büro etabliert. Besonders hilfreich sind Power-Point-Präsentationen: dort erwartet niemand scope-relevante Steuerungsinformationen.

Status-Meetings

Um alle Stakeholder ins Boot zu holen, müssen sie zu Status-Meetings eingeladen werden. Diese sollten unregelmäßig und mit wechselnden Teilnehmerkreis stattfinden. Ein Status-Meeting je Stakeholder, damit ist das Meeting zielgruppenorientiert.

Das Ziel eines solchen Meetings muss klar kommuniziert werden: „Fahrplan erstellen der zeigt, was bis zum Release-Termin noch zu tun ist“.

Während dieses Meetings kann nun – je nach Zielgruppe – etwas aus dem einen und etwas aus dem anderen Container zum Fahrplan gemischt werden. Container, die für die Zielgruppe (den Stakeholder) nicht relevant sind, müssen dabei gar nicht beachtet werden. Zum Beispiel interessiert sich ein Kunde wenig für technische Schulden.

Wo ist die Kunst? Wo ist die Illusion?

illusionDurch die Streuung aller Dinge, die bis zum Release-Termin zu tun sind, kann der Scope nun beliebig komponiert werden. Jeder Stakeholder erfährt so sein sprichwörtlich eigenes Wunschkonzert – und hört das, was er hören will: „Meine Interessen/Anforderungen sind bis zum Release-Termin realisierbar“.

Durch das explizit gesetzte Ziel der Status-Meetings, den Fahrplan für das Release zu erstellen, ist klar, dass am Ende des Meetings genau ein solcher Fahrplan stehen muss/wird. Es ist eine selbsterfüllende Prophezeiung.

Durch die zielgruppenorientierte Scope-Komposition kann über einen langen Zeitraum kommuniziert werden, dass der Termin zu halten sei. Dabei entsteht ein verzerrtes, aber zielgruppengerechtes Bild auf den Scope, auf den Release-Termin und somit auf den Projekterfolg.

Erst gegen Ende offenbaren die Container ihre verborgenen Schätze, die dann wie Bugwellen eines ungebremsten Schiffes beim Einlaufen in den Hafen ihre unterschätzten Kräfte demonstrieren.

Wie schütze ich mich vor der Täuschung?

Wie bereits einleitend erläutert möchte ich keinem eine so böswillige Strategie unterstellen. Realistischer und damit nicht unkritischer ist die selbst vorgespielte Illusion, in der manche Projekt-Verantwortliche leben. Durch die Streuung der Anforderungen (bewusst oder unbewusst) erfährt der Projekt-Verantwortliche zu jeder Situation sein eigenes Status-Meeting – mit sich und „für sich“ alleine.

Bei dieser Art der Selbsttäuschung liegt keine böswillige Absicht zugrunde. Meist liegt die Ursache darin, dass schlicht die Fülle an verschiedenartigen Anforderungen nicht mehr zu verwalten ist.

Folgende Indikatoren können Projektleiter, Produktmanager und Product-Owner heranziehen, um sich selbst vor der eigenen Illusion zu schützen:

  • viele „Container“ in denen Anforderungen gelistet werden, manchmal auch mehrere Backlogs
  • Dokumente, die Forecasts „zementieren“ (z.B. Roadmap-Powerpoint)
  • Excel-Ausleitungen/-Zusammenführungen von Anforderungen (für eine ganz bestimmte Sicht/Zielgruppe)
  • Notwendigkeit für Status-Meetings mit wechselnden Stakeholdern
  • Ergebnisse der Status-Meetings werden nicht protokolliert und nicht veröffentlicht
  • Frage von Stakeholder: „Wie lang braucht ihr noch“?
  • schnelle Antwort: „noch 3 Sprints“
  • nur der obere Teil des Backlogs ist priorisiert

Vorschläge zur Verbesserung

Alle für das Produkt relevanten Anforderungen in einem Product-Backlog zusammenfassen. Sind mehrere (Teil-) Produkte involviert, sind auch diese in eigenen Backlogs festzuhalten. Ein Backlog ist per Definition gepflegt und ranked, Aufwände sind (teils grob) geschätzt – und das zu jeder Zeit. Das Backlog ist somit automatisch „der Fahrplan“ und „die Roadmap“.

Die Stakeholder an Sprint-Reviews teilnehmen lassen. Am Ende des Reviews das Backlog auflegen. Einen Ausblick auf das kommende Release geben – was ist noch alles „in Scope“. Stakeholder Feedback zur Kurskorrektur aufnehmen. Stakeholder und sich selbst mit der Frage konfrontieren, auf was verzichtet werden kann, um den Termin zu halten.

Regeltermin für Status-Meeting aus dem Kalender entfernen, weil obsolet.

Noch mehr Illusion

In der nächsten Ausgabe von „Kunst der Illusion“ möchte ich eine ganz besondere Art der Anforderungsstreuung vorstellen: Die Täuschung durch Bindestrich-Backlogs. Ich nenne sie die „versucht agile Variante der Anforderungsstreuung“.

Quellenangaben
ER_09/shutterstock.com
ponsulak/shutterstock.com
Amy Johansson/shutterstock.com
MorganStudio/shutterstock.com