Agile Methode: Agil Produktentwicklung und das Magische Dreieck des Projektmanagement

Als ich angefangen habe, mich mit agilem Projektmanagement, insbesondere Scrum zu beschäftigen, wurde z.B. in der Scrumguide (http://www.scrumguides.org/download.html) sehr gut beschrieben, wie Scrum gemacht werden sollte und ich fragte mich, warum das Projektmanagement, das ich seit über 10 Jahre lehre, so kompliziert ist.

Mein ganzes Leben wurde leichter. Alle Schwierigkeiten des Projektmanagements, Risiken, Änderungen, Anforderungen, Verträge, Projektcontrolling, Teammotivation, Ressourcenmanagement, Planung, waren auf einmal nicht mehr da. Ich war begeistert.

Stakeholder und Scrum Team erarbeiten gemeinsam das Product Backlog. Das wird in Sprints in einzelnen Inkrementen erstellt. Im Review kommen alle Stakeholder und Scrum Teams wieder zusammen und diskutieren die Änderungen und nach vielen Sprints ist das Product Backlog abgearbeitet und alle sind glücklich.

Insbesondere hat es mich gefreut, dass dieses Magische Dreieck des Projektmanagement, dieser Dreiklang von Scope, Time und Budget, diese Waage mit drei Waagschalen aus Leistung, Zeit und Kosten endlich aus meiner Welt verschwunden war.

Kurz formuliert besagt das Magische Dreieck, dass in einem Projekt zumeist drei Zielbereiche gleichzeitig erreicht werden müssen: Eine bestimmte Leistung soll mit eine bestimmten Budget, innerhalb einer bestimmten Zeit erstellt werden. Stimmt die Relation zwischen diesen drei Zielen nicht, dann befindet sich das Projekt im Ungleichgewicht. Mindestens eines der Ziele kann nicht erreicht werden. 

Mit Scrum besteht dieses Problem auf einmal nicht mehr. 

Ich habe leider den ersten Satz der Scrum Guide überlesen. „Scrum is a framework for developing and sustaining complex products“ 

Scrum sagt nichts über Projektmanagement. Es beschäftigt sich nicht mit Projektmanagement. Es ist ausschließlich ein Verfahren zur Produktentwicklung. 

Anders formuliert: Es beschreibt einen Leistungserstellungsprozess. 

Projektmanagement interessiert sich im Gegensatz dazu nicht für den Leistungserstellungsprozess. Es beschreibt nur den Projektmanagementprozess. Und der Projektmanagementprozess ist einer der vielen Unterstützungsprozesse, die den Leistungserstellungsprozess koordinieren sollen.

Leider werfen vielen Menschen agile Leistungserstellungsprozesse und Projektmanagement durcheinander. Dann entstehen Wortkombination von „Agilem Projektmanagement nach Scrum“. Diese Wortkombination verbinden Äpfel mit Birnen und der Fellpflege von Katzen. Es sind Wörter, die nichts miteinander zu tun haben. 

Trennen wir uns von der reinen Theorie der agilen Methoden und transferieren wir sie in die Praxis, dann klopft der böse Geist des Magischen Dreiecks bei der Visionsentwicklung für das Produkt wieder an die Hintertür, wenn wir von dem Auftraggeber eine Freigabe für die Produktentwicklung erhalten wollen. Spätestens bei der Entwicklung des Product Backlogs hat uns dieser Dämon dann wieder in seinen Klauen.

Der Auftraggeber stellt so unangenehme Fragen wie:

• Wieviel kostet das Projekt den jetzt genau?
• Wann bekomme ich die Funktionalitäten?
• Welche Leistung bekomme ich den jetzt im Detail?

Fragen, die er zunächst beantworte haben möchte, bevor er einen Auftrag vergibt, bzw. einen Vertrag unterschreibt. 

Agil hat recht. Es ist fast unmöglich genaue Vorhersagen über alle drei Zielvariablen zu machen. Wie sich diese drei Faktoren in der Zukunft entwickeln werden, ist nicht vorhersehbar.

Das löst allerdings unser Problem in der Verhandlung mit dem Auftraggeber nicht. Auch die meisten Auftraggeber sind darauf angewiesen, diese Informationen zu erhalten. 

Die Frage ist jetzt: Gibt es eine „agile Lösung“?

Rubin, K.S. (2014, ISBN 978-3-8266-9047-1, S.351 ff) hat sich dazu einige Gedanken gemacht.

Schauen wir einmal auf den Inhalt einer Timebox, z.B. auf einen Sprint und damit auf die zweitkleinste Einheit der agilen Planung (Tasks sind noch kleinere Einheiten). 

• So eine Timebox ist zeitlich begrenzt. Sie hat immer die gleiche Dauer. 
• In einer solchen Timebox arbeitet ein festgelegtes Entwicklerteam. Da alle Entwickler ihre gesamte Arbeitszeit ausschließlich an der Erstellung der Inkremente für dieses Produkt arbeiten, sind die Arbeitskosten festgelegt.
• Die User Stories, die als Inkremente erstellt werden sollen, werden für jeden Sprint festgelegt und dürfen über den Verlauf der Timebox nicht mehr verändert werden.
• Sollte es einmal dazu kommen, dass doch nicht alle Inkremente erstellt werden können, gehen die damit verbunden User Stories zurück in das Product Backlog.

Damit sind die Variablen des Magischen Dreieckes bestimmt. Die Zeit durch die Dauer der Timebox, die Kosten durch die Personenkosten des Entwicklerteams und die Leistung ist relativ variabel, durch die ausgewählten User Stories, die in seltenen Einzelfällen auch zurück gegeben können.

Berücksichtigen wir zusätzlich, dass die Vorhersagedauer dieser Timebox maximal 4 Wochen lang ist, dann dürfte die Schätzung recht zuverlässig sein. Scrum hat hier ja noch zusätzlich eine Sicherung gegen zu große Wünsche der Stakeholder eingebaut: Die Entscheidung darüber, welche User Stories in dem Sprint aufgenommen werden, liegt exklusiv in den Händen der Leistungsersteller.

Bei den Planungsinstrumenten, in denen größere Einheiten festgelegt werden, ist die Lösung ungleich schwieriger. Bei der Planung des Product Backlogs wird das Problem noch größer. Welche Handlungsmöglichkeiten gibt es:

1. Der erste Fall ist, wie wir gesehen haben, nicht empfehlenswert. Er setzt voraus, dass die Planung über den gesamten Projektverlauf in einem Gleichgewicht steht. Es ist recht unwahrscheinlich, das zu erreichen.

2. Wenn das Budget variabel ist, Leistung und Zeit aber fest stehen, dann bedeutet das meistens, dass wenn „es eng werden sollte“ zusätzliche Mitarbeiter in dem Projekt mitarbeiten können, damit die Arbeit auf mehr Menschen verteilt werden kann und damit der Leistungserstellungsprozess schneller durchgeführt wird. Ob diese Möglichkeit in der Realität vorhanden ist, hängt sehr stark von der Gesamtsituation ab. Brooks F. P. (2008, ISBN 978-3826613555) formuliert so schön: „Selbst neun Frauen können nicht in einem Monat ein Baby auf die Welt bringen“. Er stellt fest, dass ein verspätetes Softwareprojekt durch zusätzliche Arbeitskräfte nur noch später fertig gestellt wird. Bevor sich das Management für die zweite Variante entscheiden sollte, lohnt sich also ein sehr genauer Blick auf den Leistungserstellungsprozess des Produktes und die Teamsituation.

3. Auch die dritte Variante bietet nur unter bestimmten Voraussetzungen eine Lösung. Zumeist ist hier kein positiver Effekt zu erwarten. Wenn ein Team mehr Zeit für einen Leistungserstellungsprozess benötigt, dann arbeiten die Menschen zumeist auch länger an diesem Prozess. Das bedeutet aber, dass die Arbeitsleitung über einen längeren Zeitraum bezahlt werden muss, was wiederum zu einer Kostensteigerung führt. Diese Variante ist also nur dann möglich, wenn das Unternehmen die Arbeitskosten der eigenen Mitarbeiter nicht in die Projektkosten einrechnet. Dieses Vorgehen ist kaufmännische allerdings irgendetwas zwischen zweifelhaft und falsch.

4. Die vierte Variante findet sich in der Praxis recht häufig – auch wenn sie meistens „versteckt“ praktiziert wird. Einfach können wir auch sagen: „Ist das Geld zu Ende, ist das Projekt zu Ende.“ Für ein agiles Vorgehen ist das immer dann akzeptabel, wenn viele der User Stories „nice to have“ sind. Da die wertmäßig größten Funktionen in der agilen Produktentwicklung zuerst erstellt werden, sollten am Ende der Entwicklung nur noch relativ unbedeutende, wenig wertvolle Anforderungen zu finden sein.

5. Die fünfte Variante stellt ebenfalls einen erfolgversprechenden Lösungsweg dar. Sie ist immer dann zu empfehlen, wenn ein Produkt zu einem bestimmten Zeitpunkt zur Verfügung stehen muss. Wenn das Budget variabel ist, können gegebenfalls mehr Menschen in der Produktentwicklung mitarbeiten (allerdings immer unter der bereits unter 2. genannten Prämisse). Der stärkst Effekt geht von der variablen Leistung aus. Auch hier kommt es zu dem unter 4. beschriebenen Effekt.

6. Die sechste Variante ist die, die in der agilen Produktentwicklung am einfachsten zu realisieren ist. Es ist allerdings sehr unwahrscheinlich, dass ein Kunde einen solchen Auftrag vergeben wird. Für interne Produktentwicklungen kann dieses Vorgehen sehr sinnvoll sein. Hier kann von Timebox zu Timebox im Review entschieden werden, ob die Stakeholder mit den erstellten Funktionalitäten zufrieden sind, oder ob weiterhin an dem Produkt gearbeitet werden soll. Auch der agilen Idee entspricht das am besten. Ausgehend von einer Produktvision und ein paar Epics wird mit der ersten Timebox begonnen, langsam eine optimale Lösung zu erarbeiten. In vielen kleinen Zyklen erfolgt eine Annäherung an ein optimales Ergebnis, das zu Beginn der Produktentwicklung noch nicht bekannt ist. 

Agile Methode: Pressemitteilung

User Stories sind das am häufigsten verwendete Verfahren zur Erstellung von Leistungsbeschreibungen. Eine gute Alternative, wenn die Stakeholder mit dem Erstellen von User Storys Schwierigkeiten haben, besteht darin sie eine kurze Pressemitteilung schreiben zu lassen.

Die Aufgabenstellung an die Anforderer:

„Schreiben Sie eine Pressemitteilung für die Einführung des neuen Releases für die Anwender. Kommunizieren Sie alles wissenswerte über das neue Release auf maximal einer halben Din A4 Seite.“

Eine solche Pressemitteilung ist länger als eine User Story. Die Auftraggeber haben damit die Möglichkeit mehr Text zur Beschreibung der von ihnen gewünschten Ergebnisse zu verwenden. Außerdem werden sie nicht in den rechte engen Rahmen der Regeln gedrückt, der für die Erstellung von User Stories vorgegeben ist. Für viele Anforderer ist das Erstellen vom Pressemitteilung damit leichter. 

{article 245}[text] {/article}

Agile Methode: Präsentationsfolien „Anwenderkonferen“

Eine Alternative zu den üblichen User Stories. Die Stakeholder erstellen zur Leistungsbeschreibung Präsentationsfolien wie für eine Anwenderkonferenz. 

Die Geschichte für die Anforderer:

„Entwerfen Sie maximal drei Präsentationsfolien, die Sie auf einer Anwenderkonferenz nutzen, um Ihr Produkt (oder Funktionalität) einem Fachpublikum in drei bis fünf Minuten zu präsentieren.“

Die Zahl der Folien ist dabei auf Zwei bis Drei begrenzt. Die stark textorientierte Form der User Storys kann durch die Präsentationsfolien aufgelöst werden. Hier können auch Bilder und Zeichnungen genutzt werden um die Anforderungen darzustellen und für das Umsetzungsteam verdeutlicht zu werden. Das Tool ist damit weniger formalisiert, als User Stories. Für vielen Stakeholder sind Präsentationsfolien ein gewohntes Medium. Es fällt ihnen leichter eine aussagefähige Folien zu erstellen und ihre Anliegen damit zu präsentieren.

Agile Methode: Visionsbox

Das Tool Visionsbox ist eine Alternative zu der Leistungsbeschreibung durch User Stories. Sie ist stärker handwerklich/taktil/visuell  als intellektuelle abstrakt und unterstützt dabei Menschen mit diese Ausrichtung stärker bei der Beschreibung der Anforderungen.

Die Aufgabenstellung für den oder die Anforderer:

„Malen Sie einen Verpackungskarton (oder basteln Sie einen Verpackungskarton), in dem das Produkt an den Kunden ausgeliefert werden soll. Beschriften Sie den Karton mit den Eigenschaften, die den Kunden, nur durch die Aufschrift der Verpackung zum Kauf motivieren.“

Die Zahl der Merkmale sollte dabei nicht größer als 3 bis 5 sein. Die stark visuelle orientieren dieser Methode entspricht der bildhaften Beschreibungen, die im Agilen gerne verwendet wird. Die „Verpackung“ steht für den Inhalt und damit für das, was in dem neu zu entwickelnden Produkt enthalten ist. Gerade für kreative und taktil visuell orientierte Menschen ist die Form der Aufgabenbeschreibung ideal. 

Alternativ zu einer Visionsbox, kann die Anforderung, bzw. das gewünschte Ergebnis des Leistungserstellungsprozesses auch auf einen Flip-Chart gemalt, bzw. skizziert werden.

 {article 245}[text] {/article}

Agile Methode: Produktdatenblatt

Alternativ zu User Story können auch Produktdatenblätter als Leistungsbeschreibung bei agilen Projekten verwendet werden. Insbesondere bei technischen Produkten kann das sehr vorteilhaft sein.

Die Aufgabe für den Anforderer:

„Erstellen Sie ein Produktdatenblatt für die von Ihnen gewünschte Funktion, die den Umfang einer Din A4 Seite nicht überschreitet und die von Ihnen gewünschte Funktionalität allgemeinverständlich erklärt.“

Dieses Produktdatenblatt entspricht dem Eintrag im Product Backlog. Es kann sich dabei um ein festgelegte Formular handeln. Das Produktdatenblatt kann aber von den Anforderern auch frei gestaltet  werden. Viele Ingenieure sind an Beschreibungen von Produkten mit Hilfe von Produktdatenblättern gewöhnt. Entsprechend leicht fällt es ihnen ihre Anforderungen in dieser Form zu erstellen. Außerdem sind gerade bei technischen Produkten zukünftige Leistungen mit klaren Datenvorgaben beschrieben. Nehmen wir nur die Entwicklung eines neuen Dieselmotors, der den Vorgaben der neuen Abgasnorm entsprechen muss und natürlich auch den marktüblichen Fahrzeugklassenwerten. Diese Vorgaben in Form von User Stories klar zu formulieren scheint sehr kompliziert. Die Vielzahl an Einzelwerten, die dieser neue Motor erfüllen muss, lässt sich auf ein paar Produktdatenblättern viel einfacher und schneller zusammenfassen.

{article 245}[text] {/article}

Agile Methode: Elevator Pitch (Kurzpräsentation)

In einem Elevator Pitch stellt der Vortragende seine Ideen innerhalb von maximal 60 Sekunden dar. Es handelt sich also um eine meist mündliche Kurzpräsentation. In der Präsentationspraxis entwickelt der Vortragende im Vorfeld, seine Präsentation auf maximal einen Flip-Chart und verwendet dieses als Medienunterstützung für seinen Vortrag.

 Der Elevator Pitch arbeitet mit folgender Aufgabenstellung:

„Stellen Sie sich vor, Sie befinden sich in einem Aufzug. In diesem Aufzug ist auch ihr potentieller Geldgeber.

Sie müssen ihn von ihrem Investitionsvorschlag überzeugen, bevor er den Fahrstuhl verlässt. 

Eine solche Fahrstuhlfahrt dauert 60 Sekunden.“

Die daraus entstehende mündliche Kurzpräsentation kann als Video aufgezeichnet werden und dann als Anforderung schriftlich dokumentiert werden. In Agilen Projekten ist die Präsentation nur die Basis für eine spätere gemeinsame Diskussion über die hier beschriebenen Leistungsanforderungen. Wichtig ist, dass zumindest einige Mitglieder des Umsetzungsteams bei dem Elevator Pitch anwesend sind und an der nachfolgenden Diskussion beteiligt werden. Nur so ist sichergestellt, dass sie bei der späten Umsetzung der Leistungsanforderungen, diese auch ausreichend verstanden haben.

Agile Methode: Product Owner (Produkt Verantwortlicher, Produkt Eigner)

Die Bezeichnung „Product Owner“ wird hier als Rolle verstanden. Analog zu dem üblichen Verständnis des Begriffes „Rolle“, kann ein Mensch mehrere Rollen haben. 

Der Product Owner ist eine Kommunikationsschnittstelle zwischen den Stakeholdern und dem Entwicklerteam.

Stakeholder sind alle Personen, die

• an dem Produkt ein Interesse haben,
• von dem Produkt betroffen sind, 

Dazu gehören insbesondere: die Auftraggeber, die Kunden, die Nutzer, die Kostenträger, das eigene Management, das Management des Auftrag gebenden Unternehmens, etc. Der Stakeholder Begriff ist hier also sehr weit gefasst. Aufgabe des Product Owners ist es, diese Stakeholder zu identifizieren und sie in die Produktentwicklung zu integrieren. Eine gute Methode zur Identifikation und Bewertung der Stakeholder ist die Stakeholder-Analyse. Da die Stakeholder Analyse aus dem klassischen Projektmanagement kommt, wird sie hier nicht dargestellt.

Wenn ich davon rede, dass der Product Owner etwas macht, bzw. „verantwortlich ist für…“, dann bedeutet das immer, dass er die Interaktion und Kommunikation zwischen den Stakeholdern, incl. des Entwicklerteams koordiniert. Anders gesagt: Der Product Owner tut nichts alleine! Er fasst keine einsamen Beschlüsse, erarbeitet keine selbständigen Lösungen oder entwickelt Konzepte alleine an seinem Computer. Alles, was er macht, macht er in Zusammenarbeit mit anderen Menschen und in Abstimmung mit diesen. 

Im Focus der Rolle des Product Owners steht die Entwicklung und Weiterentwicklung des Produktes. Dabei erfasst er die Anforderungen der Stakeholder. Er hilft den Stakeholdern diese Anforderungen zu formulieren (z.B. in User Stories), gemäß ihres Wertes zu sortieren (Priorisieren) und den Aufwand des Leistungserstellungsprozesses für die einzelnen Anforderungen zu schätzen.

Die Ergebnisse dieses Prozesses werden im Product Backlog dokumentiert. Die Pflege dieses Product Backlogs ist die Hauptaufgabe des Product Owners. 

Die andere Hauptaufgabe liegt in der Durchführung der Reviews. In den Reviews präsentiert das Entwicklerteam den Stakeholdern die erstellten Inkremente. Der Product Owner bleibt auch hier in seiner, die Kommunikation koordinierenden, Rolle. Die Begutachtung und Bewertung erfolgt durch die Stakeholder. Er ist lediglich dafür verantwortlich den Prozess des Reviews zu koordinieren und muss die Ergebnisse des Reviews mit den möglichen Veränderungen in dem Product Backlog dokumentieren. Anders ausgedrückt: Ein Review ohne Stakeholder – nur mit dem Product Owner –  ist nicht agil.

Die wichtigsten Eigenschaften eines Product Owners liegen also im Bereich der Kommunikation und Moderation. Er sollte die „Sprache der Leistungsersteller“ ebenso gut sprechen wie die „Sprache der Anforderer“. Seine Aufgabe wird häufig darin bestehen, für beide Gruppen „zu übersetzen“.  Wichtig sind auch gute Kontakte zu den Stakeholdern in der Auftrag gebenden und Auftrag nehmenden Organisation. Wenn er Erfahrung mit der Entwicklung ähnlicher Produkte hat, ist auch das hilfreich. – Hilfreich, aber nicht notwendig, da er selber keine Beschlüsse fasst.

{article 245}[text] {/article}

Agile Methode: Produkt Vision entwickeln

Eine der ganz großen Visionen wurde 1961 von dem amerikanischen Präsidenten Kennedy formuliert:

„Ich glaube, dass das Land sich dem Ziel widmen sollte, noch vor Ende des Jahrzehnts einen Menschen auf dem Mond landen zu lassen und ihn wieder sicher zur Erde zurück zu bringen.“

Eine gute Vision besteht aus wenigen, unmissverständlichen Worten. Die Vision ist quasi die oberste Ebene der Produktbeschreibung. Ausgehend von der Vision werden dann die Epics, User Stories, Funktionsbeschreibungen und das erste Product Backlog entwickelt. Aber am Anfang steht immer die Vision. 

Es gibt eine Reihe an Formaten, in denen Visionen formuliert werden können. 

• Elevator Pitch
• Produktdatenblatt
• Visionsbox
• Präsentationsfolien „Anwenderkonferenz“
• Pressemitteilung

Die Vision kommt von den Anforderern, bzw. Auftraggebern. Der Product Owner unterstützt diese Stakeholder bei der Entwicklung einer solchen Vision. 

In vielen Organisationen ist mit der Entwicklung einer Vision, auch die Aufgabe verbunden, einen Projektauftrag, Projektantrag, Projektfreigabe, Projektgründung oder Projektanbahnung zu entwickeln. Die Genehmigung eines solchen Projektauftrages durch die Auftrag gebende Organisation ist dabei eine Voraussetzung dafür, dass mit der Produktentwicklung begonnen werden darf. 

In vielen Unternehmen ist die Erstellung eines Projektauftrages ein aufwendiger, streng formalisierter Prozess, der planungsintensiv ist und häufig sehr detailliert und excessiv durchgeführt wird. Die exzessive Planungsanforderung, bei der die Produktplanung im Vorfeld des Projektes durchgeführt wird, steht häufig im Widerspruch zu einem agilen Vorgehen.

Der Vorgang der Visionsfindung sollte so einfach wie möglich gehalten werden. Die Planung sollte nur soweit durchgeführt werden, dass eine Vertrauensschwelle der Entscheider überschritten werden kann. Es geht nur darum, die Basis für die nächste Finanzierungsentscheidung zu schaffen. Die Produktentwicklung muss gerade soweit spezifiziert werden, dass der wirtschaftliche Filter für die Freigabevorgaben für Produktentwicklungen durchschritten werden kann. Je höher die Freigabeanforderungen sind, bzw. je dichter der wirtschaftliche Filter, umso aufwendiger muss die Planung sein.

Nehmen wir einmal an, der amerikanische Kongress hätte Kennedy geantwortet:

„Wir können dem Vorhaben nicht zustimmen. Zunächst brauchen wir einen genauen Zeitplan für die Produktentwicklung. Bitte sagen Sie uns genau, welche Produktkomponente bis wann entwickelt ist und machen sie uns eine Aufstellung aller Komponentenkosten. Weder der Zeitplan, noch der Kostenplan dürfen überschritten werden. Außerdem brauchen wir eine Auflistung aller Risiken, wobei die Risiken in Risikokosten bewertet werden müssen. Ob die einzelnen Komponenten dann freigegeben werden, das ist natürlich davon abhängig, wie hoch sie die Kosten veranschlagen. Wir behalten es uns vor, diese Komponenten gegebenenfalls aus der Gesamtkonfiguration heraus zu streichen. Sollte der Zeit- oder Kostenplan- überschritten werden oder die Vision nicht verwirklicht werden, dann ist ihre Karriere zu ende.“

Glauben sie, dass dieses Vision realisiert worden wäre?

Häufig wird die Schranke zur Freigabe von Produktentwicklungen von dem Auftrag gebenden Unternehmen so hoch gesteckt, dass ein agiles Arbeiten bereits vor der Freigabe des Projektauftrages unmöglich ist. Viele der Vorhersagen, die sich hinter einer frühen Detailplanung und Kostenrechnung verbergen, basieren auf Annahmen, die auf Annahmen beruhen, die dann eine objektive Zahl ergeben. Die Annahme dahinter: 10% Eintrittswahrscheinlichkeit * 25% Eintrittswahrscheinlichkeit * 20% Eintrittswahrscheinlichkeit = 100% Sicherheit. 

Ein agiler Weg besteht darin, zunächst nur die Finanzierung für die ersten Timeboxes zu vereinbaren und dann bei dem Review zu entscheiden, ob die Leistungserstellung weiter finanziert werden soll. Das gibt dem Team die Möglichkeit, sich auf die kurzfristigen Planungshorizonte zu konzentrieren und ihre Zeit nicht damit zu vergeuden, Funktionalitäten zu planen, die in dieser Form nie entstehen werden. Die Finanzierung erfolgt dann fließend mit dem Prozess der Leistungserstellung.

{article 245}[text] {/article}