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}

Agile Methode: Burnup Chart (Burn Up Chart)

Der Burnup Chart wird, genau wie der Burndown Chart, zur Darstellung der erbrachten Leistung innerhalb eines Leistungsentwicklungsprozesses verwendet. Der Unterschied zwischen den beiden Verfahren liegt nur in der optischen Darstellung der gleichen Sachverhalte. Welches der beiden Instrumentarien verwendet wird, ist eine Frage des persönlichen Geschmacks.

Die nachfolgende Abbildung zeigt beispielhaft einen Burnup Chart für einen Sprint, basierend auf der Anzahl der geplanten Task (Arbeitspakete)

Die Timebox ist hier auf 19 Arbeitstage begrenzt. Es sind 150 Tasks geplant. Mit zunehmender Abarbeitung der Tasks nähert sich der Burn Up Chart der roten Linie an. Liegt die Team Velocity über der Ideal Linie, dann kommt das Team schneller voran als geplant. Liegen die Werte unter der Ideal Linie, dann erfolgt die Arbeit langsamer. 

Wenn der Brunup Chart zur Kontrolle der Produktentwicklung genutzt wird, dann kann der Entwicklungsfortschritt in Story Points gemessen werden. Veränderungen in der Planung der Story Point und der Entwicklungsdauer können mit dem Burnup Chart dargestellt werden.

Reduziert sich die Zahl der ursprünglich geplanten Story Point (Basisplan) zu einem bestimmten Zeitpunkt, dann sackt die schwarze Linie nach unten. Erhöht sich die Zahl der Story Points, dann geht diese Linie nach oben.

Ähnlich verhält es sich mit der Dauer der Produktentwicklung. Ausgehend von der schwarzen Linie auf der Zeitachse, verschiebt sich diese nach rechts, wenn die Produktentwicklung länger dauern soll, als ursprünglich geplant. Soll die Produktentwicklung verkürzt werden, verschiebt sich die Linie nach links.

Agile Methode: „Product Owner“ Direkte Kommunikation

 Ein Aspekt des agilen Arbeitens liegt darin, dass die Menschen direkt und Face-to-Face miteinander reden. Das ist die beste Form, um zu verstehen, was die andere Seite meint und die schnellste Form des Informationsaustausches.

Ein Aspekt der Rolle des „Product Owners“ ist die Kommunikation mit den Stakeholdern. Der Product Owner sammelt die Anforderungen der verschiedenen Stakeholder in direkten Gesprächen ein, Findet heraus, was – ausgehend von diesen Gesprächen für das Produkt als Ganzes von größtem Wert ist (Priorisierung) und schätzt in Interaktion mit dem Team den Aufwand. 

Der Product Owner ist eine Kommunikationsschnittstelle und ein Informationsfilter zwischen den Leistungsanforderern und den Leistungsentwicklern. Er ist ein Informationsfilter. 

In dieser Funktion als „Informationsfilter“ steht er im Wiederspruch zum dem agilen Grundsatz der direkten Kommunikation. Die Rolle dieses Informationsfilters ist nur darin begründet, dass die direkte Kommunikation von Team und Stakeholdern dazu führen würde, dass das Team nicht gleichzeitig mit allen Stakeholdern kommunizieren und eine Leistung erstellen kann. 

Totz der Rolle des Product Owner ist der direkte Kommunikationsweg zwischen Team und Stakeholdern offen und gewünscht. Innerhalb einer Timebox der Leistungserstellung kann jedes Mitglied Unsicherheiten über eine direkte Nachfrage an den Product Owner klären, aber wenn es schneller oder einfacher geht, kann es auch direkt bei dem jeweiligen Stakeholder nachfragen. 

Auch wenn die Pflege des Product Backlogs in der Verantwortung des Product Owners liegt, bedeutet das nicht, dass er diese Aufgabe alleine macht. Vielmehr koordiniert er die Interaktion von Stakeholdern und Leistungserstellungsteam. Wenn z.B. User Stories im Product Backlog verwendet werden, dann ist die aufgeschriebene Story nur ein Platzhalter für das Verstehen der User Story durch das Team.

Ebenso ist es natürlich, mit der Weiterentwicklung von User Stories von größeren zu kleineren Einheiten und dem Verstehen der Akzeptanzkriterien der Stakeholder durch die Leistungsersteller. Hier ist die direkte Face-to-Face Kommunikation zwischen Anforderer und Leistungsersteller der agile Weg des Verständnisses.

Spätestens beim Review kommen Leistungstersteller und Anforderer wieder zusammen und diskutieren über die Ergebnisse und damit über das gemeinsame Verständnis des Ergebnisses. 

Ein Kernelement des Agil richtet sich gegen Kommunikationsfilter. Natürlich kann das Filtern von Informationen den Kommunikationsaufwand für jeden Einzelnen verringern. Auch die Informationsbeschaffung für die nachfolgenden Einheiten ist einfacher, weil die Informationen bei jedem Filter stärker verdichtet werden. Dem entgegen steht das Risiko einer Fehlinterpretation.

Ganz langsam und schwierig wird es, wenn das Team zwar verstanden hat, dass der Kunde „rot“ möchte, aber ein Detail nachfragen möchte.

Der rote Filter fragt dann den orangen Filter, der dann einen der Stakeholder fragt.

Der antwortet gelb, soweit bei dem gelben Stakeholder nachgefragt wird. Sonst antwortet er vielleicht blau oder pink.

Der grüne Leistungsersteller wartet in der Zeit auf die Information, ohne die er nicht weiter arbeiten kann. 

Der orange Filter versteht gelb. Er meldet das dem roten Filter weiter. Der wird jetzt auch gelb und meldet das dem Team weiter.

Das Team verwirft die Ergebnisse und macht jetzt gelb.

Was passiert, wenn den Stakeholdern, in der Mehrheit blau und pink, das Ergebnis irgendwann präsentiert wird?

 {article 245}[text] {/article}