Retrospektive

Die Retrospektive ist der dritte wichtige Steuerkreis des Agilen.

• Durch die Arbeit des Product Owner werden die Anforderungen der Stakeholder gesteuert und als Aufgaben an das Leistungserstellungsteam weitergereicht.
• Durch das Review werden die Ergebnisse der Leistungserstellung überprüft und gesteuert.
• Über die Retrospektiven wird der Leistungserstellungsprozess des Teams von ihm selbst überprüft und gesteuert.

Im Verlauf der Retrospektive untersuchen die Leistungsersteller, incl. Scrum Master und Product Owner, den Prozess, der angewendet wurde, um das Produkt zu erstellen. Wir befinden uns auch hier in dem typischen Plan-Act-Check Vorgehen der agilen Methoden. 

In der Retrospektive wird überprüft, ob der Prozeß der Leistungserstellung verbessert werden kann und wie das möglich ist. Dann wird der Plan in dem nächsten Sprint umgesetzt. Mit der nächsten Retrospektive erfolgt die Überprüfung des Planes. Die Retrospektive gehört damit auch zu den Planungsinstrumentarien des agilen Vorgehens.

Während der Retrospektive werden Verbesserungen erarbeitet. Diese werden dann nach der Retrospektive im nächsten Teil des Leistungserstellungsprozesses umgesetzt.

Die Retrospektive bietet die Möglichkeit für eine kurze Zeit aus dem Druck der Leistungserstellung auszusteigen, zu verharren und über das Getane in Ruhe zu reflektieren. In dieser Zeit denkt das Team darüber nach, was es getan hat. Es reflektiert, diskutiert und überprüft so seine Arbeitsweise, Arbeitsmittel und den Prozess in dem es arbeitet, die Kommunikation untereinander und mit den Stakeholdern. Außerdem überprüft es die Werkzeuge, die es verwendet, die Nützlichkeit der Artefakte, etc.

Die Retrospektive findet nach jeder Timebox statt und nicht erst am Ende des Leistungserstellungsprozesses. Das gibt dem Team die Möglichkeit, Verbesserungen frühzeitig in den Leistungserstellungsprozess einfließen zu lassen. So ergeben sich die Möglichkeiten, im nächsten Sprint mit den Veränderungen zu experimentieren. Basierend auf diesen Erfahrungen kann der Leistungserstellungsprozess kontinuierlich verbessert werden.

Möglicher Ablauf einer Retrospektive

Es gibt keinen festen Ablauf einer Retrospektive. Der hier beschriebene Ablauf zeigt lediglich ein mögliches Vorgehen. 

Gerade am Anfang, wenn ein Team dabei ist sich zu bilden, gibt es eine Vielzahl an Themen über die gesprochen werden muss. Jeder der Teilnehmer hat viele Themen, die ihm am Herzen liegen und die er aus seiner persönlichen Perspektive betrachtet haben möchten. Das Review liegt in der Verantwortung des Product Owners. Die Retrospektive in der Verantwortung des Scrum Masters. Wie wir schon bei dem Review gesehen haben, bedeutet das aber nicht, dass diese Rolleninhaber die Veranstaltung leiten müssen. Insbesondere bei der Retrospektive ist es extrem wichtig, dass der Scrum Master die Retrospektive nicht dominiert. Jeder Beteiligten muss sich hier voll einbringen können.

Damit hat jede Besprechung zu Retrospektive die besten Chancen genauso zu verlaufen, wie jede andere schlecht vorbereitete Besprechung. Chaotisch, konfliktträchtig und ergebnislos. Zu jeder Retrospektive gehört also eine entsprechende Vorbereitung. 

Eine Themensammlung, eine Agenda, ein zeitlicher Ablauf, die Fakten zu den jeweiligen Themen, etc. sollten im Vorfeld der Retrospektive gesammelt werden – oder spätestens am Anfang dieser Besprechung. 

Retrospektiven sind zeitlich begrenzt und werden eher kurz gehalten. Es kann also sinnvoll sein, eine Retrospektive auf einen bestimmten Focus, der von dem Team als „besonders regelwert“ empfunden wird, zu beschränken. – Allerdings besteht dann auch das Risiko, dass die Menschen, die innerhalb des Teams dominant sind, die Themen bestimmen und die Fragestellungen der anderen Teilnehmer nicht berücksichtigt werden. 

Ein möglicher Ablauf könnte so aussehen:

• Den Focus bestimmen, z.B. durch eine vorherige Themenauswahl, Punktwertverfahren zum Abstimmen über Themen, Agenda oder sonstigem.
• Übung auswählen, die die Teilnehmer in das Thema herein bringt, eine entsprechende Atmosphäre schafft und zum Nachdenken anregt. Beispiele für solche Übungen finden sich in den Moderationsverfahren für große Gruppen. Ein Brainstorming, Ergebnis Zeitstrahl, Emotionaler Seismograph und ähnliche Methoden können hier unterstützen. 
• (Objektive) Daten sammeln, als Basis für die weitere Diskussion. Der Begriff Objektive ist hier bewusst eingeklammert. Die Wahrnehmung eines Sachverhaltes kann bei unterschiedlichen Teilnehmern durchaus sehr unterschiedlich sein. Auch die Interpretation „objektiver Daten“ kann bei den Teilnehmern unterschiedlich sein. Viel wichtiger ist es, zunächst einmal die Unterschiede der Wahrnehmung heraus zu arbeiten. Die Behauptung, dass „dies objektive Daten sind“, wird zu häufig benutzt, um jede Diskussion zu verhindern und die eigen Ansicht unangreifbar zu machen. 
• Subjektive Wahrnehmung der Teilnehmer und das subjektive Erleben der Teilnehmer in Bezug auf die objektiven Daten transparent machen und nach Möglichkeit eine gemeinsame Wahrnehmung erreichen.
• Verbesserungsmöglichkeiten, bzw. Änderungsmöglichkeiten diskutieren und eine Auswahl dieser Verbesserungsmöglichkeiten treffen. 
• Die Verbesserungsmöglichkeiten schriftlich fixieren und dann in den nächsten Prints umsetzen.

Eine gute Möglichkeit, den ganzen Prozess für alle Teilnehmer transparent zu machen, findet sich in der Methode Fakten und Konsens. Damit sich das Team die Entwicklung über den Sprint vergegenwärtig und die Gefühle, die innerhalb dieses Sprints aufgrund der Ereignisse gegenseitig verdeutlicht, kann die Methode Ereignisse und Gefühle genutzt werden. Viele der Coaching Methoden, die sich auf dieser Web-Site finden, können für die Gestaltung der Retrospektive situationsabhängig genutzt werden. Die meisten Methoden sind zwar für ein Einzelcoaching entwickelt worden, lassen sich aber leicht auf Gruppen übertragen.

Ein sehr einfacher, aber wirkungsvoller Ablauf für die Retrospektive kann in vier Fragen bestehen:

1. Was ist gut gelaufen? Was hat funktioniert?
2. Was ist schlecht gelaufen? Was hat nicht funktioniert?
3. Was wollen wir beibehalten?
4. Was soll wie geändert werden?

{article 245}[text] {/article}

Agile Methode: Review

Die Reviews sind ein fester Bestandteil der agilen Methoden. Sie sind das wichtigste Steuerungsinstrument der Produktentwicklung. 

Nach jeder Timebox oder wie in Scrum am Ende jeder Timebox wird ein Review durchgeführt, bei dem die Ergebnisse der Arbeit von den Stakeholdern begutachtet werden. 

Basierend auf dieser Begutachtung findet eine Überarbeitung des Product Backlogs statt. Anderes formuliert: bei jedem Review werden die Anforderungen neu betrachtet, verfeinert, verändert und den Gegebenheiten angepasst. Das Review wird damit für alle Beteiligten zur wichtigsten Lernschleife. 

Die Stakeholder erhalten Einblick in den realen aktuellen Zustand des bisher fertigen Produktes. Sie erleben konkret die Weiterentwicklung des Produktes. Sie sehen und erleben, wie sich das Produkt durch die Arbeit in der Timebox entwickelt hat.

Sie sehen also nach jeder Timebox die Entwicklung an dem Produkt selber. Das konfrontiert sie mit dem direkten Produkt und dessen Entwicklung. Dieses direkte Erleben des Produktes verhindert böse Überraschungen, erhöhte Erwartungen. Die Stakeholder sehen Fehlentwicklungen unmittelbar und können diese verhindern.

Aus diesem Erleben heraus geben sie ein unmittelbares Feedback und verändern das Product Backlog innerhalb dieses Reviews aufgrund des unmittelbar erlebten. 

Auch die Leistungsersteller kommen in einen direkten, persönlichen Face to Face Kontakt zu den Stakeholdern und erhalten ein entsprechend direktes Feedback von den Menschen, für die das Produkt entwickelt wird. Das fördert das gegenseitige Verstehen und schafft das Gefühl für „richtige Menschen“ zu arbeiten und diese Menschen als solches zu Verstehen und nicht nur als „abstrakte“ Kunden oder „diffuse Gruppe“ von Nutzern, die wärend der Produktentwicklung niemals in reale Erscheinung treten.

Die Teilnehmer des Reviews

Das Review lebt von den Teilnehmern und der Interaktion zwischen ihnen. Ohne diese Teilnehmer und zwar Vertreter aller Gruppen, die hier genannt werden, ist ein Review mehr oder weniger wirkungslos. Oder anders formuliert: wie auch immer diese Treffen genannt werden, es ist kein Review im Sinne der agilen Leistungserstellung.

An dem Review sollten alle an der Leistungserstellung beteiligten teilnehmen. Also insbesondere alle Mitglieder des Entwicklerteams und der Product Owner. Natürlich auch der Scrum Master, wenn wir in einer Scrum Organisation sind. Das Review ist die Veranstaltung des Product Owners. Er leitet das Review. Die Präsentation der Inkremente sollte nach Möglichkeit von allen Leistungserstellern übernommen werden. Es sind interne Stakeholder, wenn die Produktentwicklung von einer Auftrag nehmenden Organisation durchgeführt wird. Hier sind insbesondere die Stakeholder erwünscht, die für die Finanzierung der Produktentwicklung zuständig sind und die Personen, die fachlich für die Ergebnisse mitverantwortlich sind. 

Die externen Stakeholder sind zunächst einmal die Vertreter der Auftraggeber die eine finanzielle Verantwortung haben und die Fachabteilungen, in deren Auftrag das Produkt entwickelt wird. Wenn das Produkt für die Kunden des Auftraggebers hergestellt wird, sollten auch diese Endanwender um ein Feedback gebeten werden. Wenn es weiter externe Stakeholder gibt, dann kann es nützlich sein auch Vertreter dieser Gruppe einzuladen. 

Was und wie sollte präsentiert werden?

In dem Review wird das fertige Produktinkrement vorgeführt. Ziel ist es den Teilnehmern ein „Look and Feel“ Gefühl des Produktes zu vermitteln. Eine Powerpoint Präsentation verhindert genau dieses Gefühl. Auch eine umfangreiche Präsentation der kaufmännischen Entwicklung des Leistungserstellungsprozesse, abstrakt und mit vielen Charts – wie sie bei den üblichen Präsentationen „Projektleiter präsentiert vor dem Management“ Besprechungen gemacht wird, wiederspricht der Idee eines Reviews. 

Ziel eines Reviews ist eine intensive Diskussion der Teilnehmer über die Leistungseigenschaften an dem realen Objekt.

Abnahme durch den Product Owner

Der Product Owner bekommt von dem Team das Inkremen, das der Definition of Done entspricht, geliefert. Er prüft dieses Inkrement und bestätigt dem Team, dass das Inkrement der Definition of Done entspricht. 

Dieser Prozeß muss vor dem Review stattfinden.

{article 245}[text] {/article}

Agile Methode: Kosten ermitteln

Auf den ersten Blick scheinen Kosten in der agilen Produktentwicklung nur eine untergeordnete Rolle zu haben, während sie im klassischen Projektmanagement sehr dominant sind. Dieser Eindruck täuscht allerdings. Wenn wir uns mit der Priorisierung von Anforderungen beschäftigen, dann basiert der Wert einer Funktionalität auf der klassischen kaufmännischen Sichtweise:

Wert = Nutzen – Aufwand.

Der Aufwand wird dabei in Story Points, Idealtagen und ähnlichem geschätzt. Irgendwann innerhalb der Planung, wird dann ein Zusammenhang zwischen einem Personentag und den Story Points, oder anderen Schätzgrößen hergestellt. 

Der nächste Schritt von dem Personentag zu den Personentagessätzen ist dann nur noch sehr klein – und damit sind wir wieder in der üblichen Welt der altbekannten Projektkostenrechnung angekommen. 

Die Kosten für eine Timebox sind sehr leicht zu berechnen.

• Die Dauer einer Timebox ist bekannt und bleibt über die Dauer der Produktentwicklung fix.
• Das Team (incl. Product Owner und Scrum Master) bleibt (im Idealfall) über den gesamten Produktentwicklungsprozess zusammen.
• Alle Mitarbeiter im Team sind der Produktentwicklung zu 100% ihrer Arbeitszeit zugewiesen.

Damit können die Personalkosten innerhalb einer Timebox leicht ermittelt werden. Die altbewährte Berechnung der Personenstunden kann hier genutzt werden. Über die Zahl der geplanten Timeboxes ergibt sich die Höhe der Gesamtkosten.

Wenn die durchschnittliche Höhe der Story Points pro Timebox als Team Velocity bekannt ist, können auch die erwarteten Kosten pro Story Point errechnet werden. 

Die Kostenberechnung ist also recht einfach, soweit primär Mitarbeiterkosten entstehen. Wenn das Produkt, das erstellt werden soll, zusätzlich teure Materialen oder Dienstleistungen benötigt, die bei den einzelnen Funktionalitäten variieren, dann wird die Berechnung der Kosten wesentlich schwieriger. 

Nehmen wir einmal die unspezifische Anforderung: „Wir brauchen ein Auslieferungsfahrzeug.“

Wenn wir klassisch vorgehen würden, dann würden wir jetzt genau festlegen, wie das Fahrzeug beschaffen sein könnte und dann berechnen lassen, wie hoch die Materialkosten sind. Wir könnten auch verschiedene Kostenvoranschläge einholen, die basierend auf einem genauen Pflichtenheft erstellt werden. Die Unsicherheiten und Ungenauigkeiten und der Aufwand bei der Erstellung und Änderung solcher Berechnungen sind ja hinlänglich bekannt. Ich werde sie hier also nicht erörtern. Wir erhalten als Kalkulationsbasis eine Zahl, die auf der Multiplikation von Wahrscheinlichkeiten mit Wahrscheinlichkeiten basiert. Die genauen Kosten bleiben bis zur Fertigstellung des Daches unsicher.

Wenn wir agil vorgehen, dann steht diese unspezifische Anforderung zunächst einmal im Product Backlog und wird dann genauer spezifiziert, wenn wir wissen, wie genau das Fahrzeug beschaffen sein soll und wie sich die Materialpreise entwickelt haben. Erst dann erfolgt eine genaue Beschreibung. Danach erfolgt eine Kalkulation der Kosten, die wesentlich weniger unsicher ist, als die „frühe Kalkulation“. Die genauen Kosten kennen wir auch in dieser Situation erst nach der Fertigstellung des Daches.

Was verändert sich durch das agile Vorgehen?

In dem klassischen Vorgehen wird, bevor mit dem Projekt begonnen wird, genau spezifiziert und berechnet, was gebraucht werden wird. Die Kosten sind – mit den üblichen Unsicherheiten bekannt. Im Verlauf des Projektes erkennen wir, dass wir etwas anderes brauchen. Spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Dann erkennen wir, dass wir etwas anderes brauchen, spezifizieren genau und berechnen die Kosten mit den üblichen Unsicherheiten. Und so weiter. In dem letzten Zyklus spezifizieren und kalkulieren wir genau und erstellen die Funktionalität. Ist sie fertig, kennen wir die Kosten genau.

Im agilen Vorgehen leben wir mit der Unsicherheit, berechnen, spezifizieren erst kurz vor der Leistungserstellung mit sehr hoher Sicherheit. Erst wenn die Funktionalität fertig ist, kennen wir sie genau.

Welches Vorgehen ist jetzt besser?

• Bei dem klassischen Vorgehen, ist die Unsicherheit kleiner, da wir zumindest eine „grobe Richtung“ der Kosten haben. Dafür ist der Aufwand zu Anfang größer.
• Im Verlauf des klassischen Vorgehens ändern wir die Spezifikation / Kostenschätzungen mehrmals mit zusätzlichem Aufwand.
• Bei dem agilen Vorgehen ist die Unsicherheit größer, denn es gibt noch nicht einmal eine „grobe Richtung“. Es entsteht kein Aufwand.

Die letztendliche Spezifikation ist in beiden Fällen sehr ähnlich. Die Endkosten sind identisch. Das agile Vorgehen ist mit weniger Aufwand und einer größeren Unsicherheit verbunden.

Aber: Ist das „agile Vorgehen“ genau wie in dem Bild oben beschrieben?

• Im Product Backlog wird jede Anforderung in eine Hierarchie gebracht und der Aufwand wird geschätzt. Lediglich die Schätzung ist nicht so genau, wie in dem klassischen Vorgehen.
• Erfolgt eine Änderung einer Anforderung, dann wird das Product Backlog geändert. Im agilen Vorgehen reden wir von Backlog Pflege. Im Rahmen dieser Backlog Pflegen, erfolgt natürlich auch eine „Neuschätzung“ des Aufwandes. 
• Die Änderungen im Product Backlog erfolgen in Abstimmung des Product Owners mit den Stakeholdern und den Leistungserstellern.

Und schreibt das „klassische Projektmanagement“ (nach PMI, Prince2, GPM-IPMA) das Vorgehen vor, dass in dem Bild oben beschrieben wurde?

• Die Anforderungen der Stakeholder werden in einer Leistungsbeschreibung erfasst. Hier folgt eine Hierarchisierung der Ziele und in der Planung ein Schätzung des Aufwandes, der notwendig ist, um diese Ziele zu erreichen.
• Der Aufwand der Anforderungen wird im Verlauf des Planungsprozesses geschätzt. Die Anweisung in allen Systemen: „so genau wie nötig, so grob wie möglich“. Es wird immer empfohlen bei frühen Schätzungen eine „von … bis“ Spanne anzugeben.
• Eine Änderung der Anforderungen und des Planes ist jederzeit möglich, sofern der Änderungsprozess eingehalten wird. Der besagt: Änderungen müssen mit den Stakeholdern besprochen und von den Auftraggebern genehmigt werden. Ein Änderungsantrag beinhaltet: Beschreibung der Änderung, Beschreibung der Folgen der Änderung in Bezug auf Kosten, Budget, Risiken, etc…

Wie unterschiedlich sind die Vorgehensweisen also wirklich? Liegen die Probleme, die in dem klassischen Vorgehen liegen, wirklich in den Projektmanagement-Methoden begründet? Und ist die Problemlösung, die im agilen Vorgehen liegt, so unterschiedlich von dem „klassischen Projektmanagement“?  

Oder sind die Probleme in der Interpretation des Vorgehens zu suchen? Und besteht dann nicht das Risiko, dass genau die gleichen Interpretationsprobleme bei der Anwendung der agilen Methoden erneut gemacht werden?

Die Frage, welches Vorgehen jetzt besser ist, bleibt weiterhin bestehen.

Die wesentlichen Fragen reduzieren sich auf die klassische Abwägung, die bei Schätzungen immer im Mittelpunkt stehen:

• Wie sicher ist eine Vorhersage?
• Wie dringend brauche ich eine sichere Vorhersage?
• Mit welchem Aufwand kann ich die Sicherheit der Vorhersage erhöhen?

 {article 245}[text] {/article}

I

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}