Alistair Cockburns Keynote „I come to bury Agile, not to praise it“ als Video

Alistair Cockburns keynote auf der Agile 2009 in Chciago steht als Video kostenlos zur Verfügung: http://www.infoq.com/presentations/cockburn-bury-not-praise-agile. Wer Cockburn noch nicht kennt, kann seinen kritischen und fundamentalen Blick auf Agilität kennenlernen, ebenso wie auch seinen Vortragsstil. Wer ihn kennt, kann sich über seine leicht adaptierte Rede des Marc Antonius aus der Beerdigungsszene von Shakespears „Julius Cäsar“ freuen, aus der er auch den Titel des Vortrags entnommen hat. Diese Rede hält Marc Antonius in dem Schauspiel als Antwort auf Brutus‘ Nachruf am Grabe Cäsars. Für alle, die sich näher dafür interessieren, habe ich unten das Original von Shakespear angehängt, das einiges zum Verständnis von Alistairs Text beiträgt.

Wer Cockburn selbst in relativ kleiner Runde erleben will, hat Ende November dazu in Deutschland Gelegenheit im Rahmen zweier dreitägiger CSM-Kurse. Noch sind Plätze frei.

I come to bury Caesar, not to praise him;
The evil that men do lives after them,
The good is oft interred with their bones,
So let it be with Caesar … The noble Brutus
Hath told you Caesar was ambitious:
If it were so, it was a grievous fault,
And grievously hath Caesar answered it …
Here, under leave of Brutus and the rest,
(For Brutus is an honourable man;
So are they all; all honourable men)
Come I to speak in Caesar’s funeral …
He was my friend, faithful and just to me:
But Brutus says he was ambitious;
And Brutus is an honourable man….
He hath brought many captives home to Rome,
Whose ransoms did the general coffers fill:
Did this in Caesar seem ambitious?
When that the poor have cried, Caesar hath wept:
Ambition should be made of sterner stuff:
Yet Brutus says he was ambitious;
And Brutus is an honourable man.
You all did see that on the Lupercal
I thrice presented him a kingly crown,
Which he did thrice refuse: was this ambition?
Yet Brutus says he was ambitious;
And, sure, he is an honourable man.
I speak not to disprove what Brutus spoke,
But here I am to speak what I do know.
You all did love him once, not without cause:
What cause withholds you then to mourn for him?
O judgement! thou art fled to brutish beasts,
And men have lost their reason…. Bear with me;
My heart is in the coffin there with Caesar,
And I must pause till it come back to me.
William Shakespear

CSM+Crystal Kurse mit Alistair Cockburn

Wie ich bereits vor vier Wochen angekündigt hatte, biete ich gemeinsam mit dem Scrum-Center und andrena objects zwei dreitägige CSM-Kurse inklusive Einführung in Crystal mit Alistair Cockburn an. Die Kurse finden statt am:

Die Kursgebühr beträgt € 1800,00 zzgl. MWSt. Wer jemals einen Workshop mit Alistair erlebt hat, weiß dass sich die Investition lohnt.

Die Kurse finden in Englisch statt, Rückfragen können aber auch auf Deutsch gestellt werden.

Darüber hinaus gibt es auch noch die Möglichkeit von Inhouse-Workshops mit Alistair Cockburn und mir oder Alistair Cockburn alleine. Anfragen können Sie per E-Mail an mich senden.


Kursbeschreibung von Alistair

Alistair Cockburn
Certified Scrum Master and Introduction into the Crystal method family

This workshop is based on the award-winning book Agile Software Development: The Cooperative Game, on Crystal Clear: A Human-Powered Methodology for Small Teams, and on Agile Project Management with Scrum. The first part of the course gives the attendee a gut feeling for the is and isn’t of agile development; the second sets out Scrum and the role of the ScrumMaster; the third introduces Crystal with it’s 7 Properties of Highly Successful Projects.

Each part introduces its concepts with small lecture, followed by team activities to anchor them. The activities are constructed to give attendees a sense for how it feels to be doing some of the key practices as well as what how it feels not to do them. The techniques reviewed are valuable in carrying out any kind of project, not only agile ones.

  • Basic Agile
    • How to understand agile development in the larger context of real-world software development.
    • Cooperation, communication, incremental development and reflection as critical factors in project success.
  • Scrum
    • The heart of Scrum: collaborate & deliver; inspect & adapt.
    • The ScrumMaster role (including becoming a Certified ScrumMaster)
  • Crystal
    • How Crystal’s reflection adds to generic agile and generic Scrum.
    • Applying the 7 properties of highly successful projects

Course Goal for Attendees

  • Understand what is agile and what isn’t agile development
  • Have a gut feeling for teamwork, communication, frequent customer interaction and frequent delivery
  • Understand Scrum, the role of the ScrumMaster, and the Crystal methodology family as techniques in setting up and running projects
  • Have a few techniques to take home and use immediately
  • Walk away with a „Certified ScrumMaster“ certificate

Instructor

Dr. Alistair Cockburn, author of the Jolt-award winning books, Agile Software Development: The Cooperative Game and Writing Effective Use Cases , coauthor of the Agile Manifesto and Project Management Declaration of Interdependence, and Certified Scrum Trainer.

Level: Beginner and Intermediate

Who Should Attend: Participants keep saying, „I wish my boss had come to this!“, so it is a good idea if people from every level and role attend.

Alistair Cockburn gibt CSM-Kurs in Deutschland im November

In Zusammenarbeit mit dem Scrum-Center und andrena objects ist es uns möglich, voraussichtlich zwei dreitägige CSM-Kurse mit Alistair Cockburn in der zweiten Hälfte November anbieten zu können. In Planung ist derzeit ein Kurs in München und einer in Frankfurt. Bei mindestens einem davon werde ich assistieren.

Zudem gibt es ein kleines Zeitkontingent für Inhouse-Workshops entweder mit Alistair alleine oder Alistair und mir gemeinsam.

Alistair ist der Schöpfer der Crystal Methodenfamilie und einer der Autoren des agilen Manifests. Ich persönlich habe nicht nur einen großen Teil meines eigenen agilen Handwerks von ihm gelernt, sondern auch seinen interaktiven Stil in Workshops und Schulungen immer sehr genossen. Dies ist eine seltene Gelegenheit für alle, die Agilität von einem ihrer Schöpfer kennen lernen wollen und dabei auch noch ein Zertifikat als „Certified Scrum Master“ erhalten wollen. Die Kurse werden in Englisch stattfinden, Alistair spricht aber gut genug Deutsch, um auch auf deutsch gestellte Fragen beantworten zu können.

Nähere Informationen zu den Schulungen werden wir im Laufe der nächsten Wochen veröffentlichen. Bei Interesse an Inhouse-Workshops wenden Sie sich bitte an mich.

Kundennutzen in Agilen Projekten

Felix Rüssel hat vor einiger Zeit in seinem — übrigens insgesamt sehr lesenswerten — Blog einen älteren Beitrag von mir zum Kundennutzen unter dem Titel „Kundenzufriedenheit vs Kosten“ in die Kritik genommen. Einer von Felix‘ Kernsätze war: „Die agile Sichtweise schlägt […] stark vereinfacht vor, Kundennutzen grundsätzlich zu maximieren. Dies darf jedoch nicht zu Lasten des Gesamtbudgets des Projektes gehen! Dieser Konflikt muss durch den ProductOwner bzw. den Projektleiter erkannt und zusammen mit dem Kunden gelöst werden“, und er beklagt sich: „Die Kundenzufriedenheit spielt […] unbestritten eine zentrale Rolle, wird jedoch gerade in der agilen Welt zu oft als alleiniges Heilmittel angesehen. Es wird oft aus der Sicht des Ingenieurs argumentiert, der Prozesse und Arbeitsergebnisse optimieren möchte.“

Ich teile Felix‘ Auffassung nicht, dass die alleinige Fokussierung auf die Kundenzufriedenheit nur aus einer technokratischen Sicht kommt. Ich denke, sie hat auch handfeste betriebswirtschaftliche Gründe, zumindest wenn der Kontext stimmt. Felix argumentiert in seinem Beitrag aus der Sicht eines Softwarehauses: „In den meisten Fällen arbeiten heute Teams in der Projektentwicklung weiterhin mit Werkverträgen, d.h. es wird ein definiertes Ergebnis zu einem bestimmten Termin geschuldet.“ Das bedeutet aber eben nicht nur ein Werkvertrag, sondern auch eine neue, künstlich eingezogene betriebswirtschaftliche Ebene: Für den Auftragnehmer ist in dieser Situation nicht mehr der betriebswirtschaftliche Erfolg der Software relevant, sondern einzig der Erfolg des Projekts ihrer Erstellung, gemessen an Einhaltung von Umfang und Termin möglichst unterhalb des Budgets und zu einer Qualität, die mir nicht gerichtsfest um die Ohren geschlagen werden kann.

Je weiter ich als Projektleiter also kurzfristige Kosten und damit Qualität nach unten drücken kann, um so erfolgreicher bin ich betriebswirtschaftlich als Projekthaus. Allerdings werden dabei die Kosten nicht wirklich reduziert, sondern nur vom Auftragnehmer zum Auftraggeber verlagert: Der Auftragnehmer spart vor der Produktionssetzung Kosten ein, indem er weniger in Qualität investiert, der Auftraggeber muss ein Mehrfaches dieser Kosten hinterher aufbringen, um die Fehler zu beheben, mit den Fehlerfolgen umzugehen und das verkorkste Design weiter zu entwickeln. In der Rechtstheorie könnte er dafür zwar den Auftragnehmer in Mängelhaftung nehmen, in der Praxis ist das jedoch nicht nachzuweisen.

Rob Austin bezeichnet diese Konstellation in einem meiner Lieblingsbücher „Measuring and Managing Performance in Organizations“ als „Measurement Distortion“: Wenn ein System (oder Vertrag) von vier Parametern bestimmt wird (Termin, Umfang, Kosten und Qualität) und ich kann nur drei von ihnen einigermaßen messen (Termin, Umfang und Kosten), so werden diese auf Kosten des schlecht messbaren vierten Parameters (Qualität) optimiert. Wie das im Projektalltag dann aussieht, beschreibt Felix sehr richtig und treffend.

Die Schlussfolgerung ist aber nicht, dass Agilisten „das Thema ‚Kosten‘ gerne verdrängen“ würden, sondern dass Werkverträge nicht geeignet sind, betriebswirtschaftlich sinnvoll ein Softwaresystem zu erstellen: Hier geht es ja nicht nur um Entwicklungskosten (die der Auftragnehmer eines Werkvertrages optimiert), sondern um die Gesamtkosten („Total Cost of Ownership“) des Systems, zu denen unter anderem auch Betriebs-, Wartungs-, Weiterentwicklungs- und Stilllegungskosten gehören. Die Rechnung wird also am Ende der Lebenszeit der Software aufgemacht, nicht zu Produktionsstart. Um die Tatsache abzubilden, dass bei den Kosten auch der Zeitfaktor mitspielt, arbeiten Betriebswirtschaftler mit Abzinsungsmodellen, die ein guter Product Owner meines Erachtens kennen und soweit sinnvoll berücksichtigen sollte. Mike Cohn beschreibt solche Modelle sehr gut in seinem Buch „Agile Estimating and Planning„, Kapitel 10.

Die agile Sicht stellt also dem traditionellen Projekt „Software bis zur Produktionsreife entwickeln“ eine Produktsicht gegenüber: Der Return-on-Investment über den gesamten Lebenszyklus muss optimiert werden. Ich habe diesen Gedanken 2005 einmal in dem Artikel „Projektdämmerung“ weiter ausgeführt. Es geht also um eine globale Optimierung statt einer lokalen, bzw. um eine ganzheitlichere Sicht auch in der betriebswirtschaftlichen Steuerung. In Scrum ist genau das die Aufgabe des Product Owners.

Mit anderen Worten: Die Abkehr vom Werkvertrag ist für den Auftraggeber wichtig und sinnvoll. Die Auftragnehmer haben sich mit Werkverträgen arrangiert, vom meist agilen, kundenorientierten Softwarehaus, das sich bemüht, das Spannungsfeld für alle Seiten einigermäßen erträglich auszubalanzieren bis zum eiskalten Homo Ökonomicus im Großkonzern, für den nur noch Termine und Kostenminimierung zählen und die nicht vertraglich fixierten Interessen des Kunden keine Rolle mehr spielen. Der Auftraggeber liefert sich in beiden Fällen ohne Not dem Auftragnehmer aus, seine Interessen kommen dabei in der Regel unter die Räder.

Certified Scrum Developer und implizites Wissen

Die Scrum Alliance arbeitet derzeit an einem „Certified Scrum Developer“. Nun gut, das bisherige Zertifizierungsprogramm aus Scrum Master, Product Owner, Practitioner, Coach und Trainer hat nicht unwesentlich zum Markterfolg von Scrum und Agilität beigetragen; und welche Folgen es für den Ruf von Scrum und agilen Verfahren hat, wenn 50.000 Scrum „Master“ mit einer jeweils zweitägigen Schulung unterschiedlicher Qualität die Industrie stürmen, um es jetzt „richtig“ zu machen, wird die Zukunft zeigen. Warum also das Erfolgsrezept nicht auch auf Entwickler ausdehnen?

Die Antwort ist einfach: Den Schaden, den ein schlechter Entwickler anrichten kann, ist für das Projekt noch bei weitem höher, als den, den ein schlechter Scrum Master anrichten kann: Den Scrum Master tauscht man zur Not aus und muss dann das Team wieder neu aufbauen und motivieren. Das kostet Geld, Zeit und Nerven, ist aber machbar. Schlechte Entwickler aber hinterlassen ihre Hypotheken im Code, die neue Hypotheken nach sich ziehen, ähnlich wie die Verpflichtungen der HRE.

Software Entwicklung ist in hohem Maße erfahrungs-getrieben. Dies gilt insbesondere für testgetriebene Entwicklung und emergente Architekturen, wie sie im Extreme Programming eingeführt und mittlerweile von allen agilen Verfahren inklusive Scrum übernommen wurden (leider nicht immer mit den gebotenen Referenzen). Erfahrungsgetrieben bedeutet aber, dass viel erfahrungsgebundenes implizites Wissen notwendig ist. Wikipedia beschreibt dieses Wissen folgendermaßen:

„Damit ist ein Wissen gemeint, das sprachlich nicht oder kaum weitergegeben werden kann. In solchen Fällen muss der Betreffende durch eigene Erfahrung oder am Modell lernen, das ihm vorzeigt, was nicht vorgesagt werden kann. Beispiel: Wer guten Nudelteig machen möchte, kann Rezeptbücher lesen. Aber in diesen Büchern steht offenbar nicht alles, was gute Teigköche wissen, weil dies nicht vollständig verbalisierbar ist. Das Gefühl für die richtige „Nässe“ des Teigs beispielsweise erwirbt man nur durch Erfahrung.“

Sicher, gerade die Patternbewegung hat sich erhebliche Verdienste erworben, Teile dieses impliziten Wissens zu heben und explizit zu machen, aber eben nur Teile. Die Eleganz eines Designs, die Strategie eines Umbaus lässt sich ebenso wenig explizieren, wie die Struktur eines Teiges. Hier hilft nur: Üben, üben, üben, viele Erfahrungen machen. Aber auch aus den Erfahrungen anderer lernen, fremden Code ansehen, fremde Architekturen — und zwar nicht nur den Beispielcode des MSDN.

Mir ist unbegreiflich, wie sich Informatik-Professoren damit schmücken können, in ihrem Leben keine 1000 Zeilen Code geschrieben zu haben, wie Architekten stolz darauf sein können „nicht mehr zu programmieren“ (man vergebe mir, dass ich hier keine Namen nenne). Kennen Sie einen Chirurgen, der sich damit brüstet, in seinem Leben kaum mehr operiert zu haben, als drei Platzwunden zu nähen? Würden sie ihm Ihr Leben anvertrauen? Davor schützt uns zum Glück die Ärztekammer. Programmieren aber gilt als niedere Tätigkeit, die man am besten möglichst weit weg schiebt, zum Beispiel nach Indien. Diese Missachtung der Programmierkunst ist ein fataler Irrtum, wie ich denke, der unsere Volkswirtschaft Milliarden Euro jedes Jahr kostet.

Sollte der „Certified Scrum Developer“ implizites Wissen wirklich abdecken, könnte er tatsächlich eine Qualifikation transportieren. Sollte er das nicht leisten, wäre es ein weiterer Versuch, den Markt zu segmentieren in Zertifizierte und Ent-Zertifizierte. Darüber hatten Johannes Link und ich uns ja schon Gedanken gemacht. Das wäre schade, war die Agile Bewegung doch einst als innovativer Gruppenprozess gestartet.

Ziele agiler Planung

Wenn agile Planung richtig durchgeführt wird, leistet sie einen wichtigen Beitrag, das Projekt zum Erfolg zu führen. Dabei ist Erfolg nicht als Einhaltung von Zeit, Umfang, Budget und Qualität definiert, sondern als Beitrag zur Maximierung des Geschäftsnutzens der Software. Das bedeutet, dass agile Planung sowohl die Effektivität der Softwareentwicklung fördern sollte, als auch deren Effizienz – und zwar in dieser Reihenfolge.

Zur Förderung der Effektivität werden mehrere Teilziele verfolgt:

  • Das Team soll sich darauf fokussieren durch die Anwendung den geschäftlichen Mehrwert des Systems zu optimieren
  • Das Planungsverfahren soll Änderungen unterstützen und nicht erschweren. Änderungen gelten im agilen Kontext als unvermeidlich und sind Teil des Lernprozesses aller Beteiligten
  • Risiken sollen minimiert werden, also entweder frühzeitig ausgeschaltet oder durch entsprechende Sicherungen unschädlich gemacht werden. In diesem Sinne ist Risikomanagement integraler Bestandteil agiler Planung

Weitere Teilziele sollen die Effizienz der Entwicklungsarbeit optimieren:

  • Voneinander abhängige Aktivitäten sollen koordiniert werden
  • Die Planung soll realistische Voraussagen ermöglichen, damit sich andere Projektbeteiligte rechtzeitig darauf einstellen können. Zum Realismus zählt auch das explizite Eingeständnis, dass jede Voraussage nur mit einer gewissen Wahrscheinlichkeit eintritt. Eine Abschätzung für diese Wahrscheinlichkeit ist eine der „Königsdisziplinen“ agiler Planung
  • Die Planung sollte eine Basis für realistische Statusbestimmungen liefern. Dafür muss klar definiert sein, wann eine Aufgabe abgeschlossen ist. Dieses Kriterium muss sich an dem Beitrag zum Projektergebnis orientieren, es muss eindeutig feststellbar sein und darf nicht interpretierbar sein. Der Fortschritt sollte sich an den ausgeräumten Risiken orientieren und der Status muss ausreichend Informationen enthalten, um schnelle Eskalationen zu ermöglichen

Interessant sind aber auch Ziele, die oft mit Plänen verbunden werden, die aber von agilen Planungsverfahren explizit nicht verfolgt werden:

  • Es soll keine korrekte Vorhersage des Projektablaufs erstellt werden, weil das nicht möglich ist. Erfolg ist der geschaffene Mehrwert, nicht das Einhalten eines Plans
  • Die Mitarbeiter- und Ressourcenbelegung soll nicht vorausgeplant werden, weil diese Pläne in einem nicht vorhersehbaren Umfeld sehr aufwändig und fragil sind und keinen Nutzen stiften
  • Agile Planung ist kein Vehikel, um über „ambitionierte Pläne“ Druck auf das Team auszuüben. Hilfreicher Druck kommt in agilen Teams vom gemeinsam verfolgten Ziel. Übermäßiger Druck führt zu Qualitätseinbußen und damit kritischen Zeitverzögerungen. Die Grenze zwischen heilsamer Fokussierung und übermäßigem Druck liegt deutlich niedriger, als die meisten Manager glauben
  • Agile Planung ist kein Vehikel, um Verantwortung weiter zu schieben, indem man unrealistische Zulieferungstermine aufstellt und dann den Verzug verantwortlich macht für eigene Verzögerungen. Da Planungen stets mit Wahrscheinlichkeiten versehen sind, versucht wird, Abhängigkeiten aufzulösen und die Teams für Risiken Rückfallstrategien aufbauen, taugen solche Spielchen nicht mehr, um die Verantwortung abzuwälzen
  • Agile Planung erzählt Managern nicht, was sie gerne hören wollen, sondern bietet einen realistischen Blick auf das, was möglich ist. Das erfordert für viele Manager Umgewöhnung, erlaubt ihnen aber, früher zu reagieren und schädliche Auswirkungen zu begrenzen

Agile Planung ist damit ein wichtiges Instrument für das Team und das Management, die Wertschöpfung eines Projekts nicht so sehr trotz, sondern mit Hilfe vieler Änderungen zu optimieren. Wie Jim Highsmith schreibt: „Agile Projektmanager kümmern sich bevorzugt um Wertschöpfung, Teams und Anpassbarkeit. Diese sind für ein erfolgreiches Projekt wichtiger, als die Beschränkungen durch Zeit, Kosten und Anforderungen“ („Cutter Agile E-Mail Advisor“ am 13.11.2008, Cutter Consortium).

Agil und V-Modell XT

Krishan Mathis fasst in seinem Beitrag „Scrum and the German V-Model XT“ das Ergebnis einer Diskussion auf dem letzten Agile Tuesday in München zusammen. Der Beitrag enthält eine sehr lesenswerte Kurzfassung des V-Modell XT und geht auch auf die „Agile Durchführungsstrategie“ ein: „There is very little overlap between this ‚agile‘ model and how Scrum structures activities“. Die Aussage lässt sich durchaus auf die meisten agilen Verfahren übertragen.
Krishan kommt zu dem Schluss, dass man den Product Owner als „Schnittstelle“ zwischen den Welten „missbrauchen“ kann, aber nicht ohne eine Warnung: „It puts however a high degree of tension on the product owner and an associated risk of project failure.“

Ich denke, für alle agilen Verfahren ist die „mechanische“ Kopplung beider Welten über eine „Schnittstelle“ eine mögliche Lösung, nicht nur für Scrum. Man sollte sich dabei aber auch darüber im klaren sein, dass man sich damit auf sehr dünnes Eis begibt. Wird vom Auftraggeber das V-Modell XT verlangt, hat das normalerweise einen von zwei Gründen:

  • Der Auftraggeber ist gesetzlich und per Ausschreibungsrichtlinie gezwungen, das zu verlangen
  • Der Auftraggeber hat sich bewusst für ein hoch-zeremonielles Verfahren wie das V-Modell XT entschieden

In beiden Fällen ist der Schluss naheliegend, dass die interne Kultur des Auftraggebers so gestaltet ist, dass Mechanismen und Ideen des V-Modell XT zur Kultur passen. So kann zum Beispiel die Einhaltung von Vorschriften und unveränderten Verträgen wichtiger sein, als ein schneller RoI, selbst wenn sich das als projektgefährdend herausstellen sollte. Auch kann die Bereitschaft, individuell Verantwortung zu übernehmen, deutlich geringer sein, als zum Beispiel bei einem Startup.

Ist das der Fall, ist die Wahrscheinlichkeit hoch, dass weder Auftraggeber noch Auftragnehmer glücklich werden mit agilen Ansätzen. Der Wunsch, hinter einer V-Modell-Fassade agil zu arbeiten, sollte meines Erachtens also vom Auftraggeber ausgehen, und dieser sollte auch in der Lage sein, die notwendigen Entscheidungen zeitnah zu treffen — und später auch die Verantwortung dafür zu übernehmen. Zudem sollte man sorgfältig abgewogen haben, ob die Fassade wirklich sein muss, oder ein offener Ansatz möglich ist und man sollte sich ggf. auch mit Hilfe eines Spezialisten für Ausschreibungsrecht absichern und mit der zuständigen Innenrevision gesprochen haben.

Das klingt jetzt zwar alles wenig agil, aber man sollte sich auch im Klaren sein, dass die freundliche Gruppenleiterin, mit der man gerade verhandelt, wenig zu melden hat, wenn sich die Herrschaften des Rechnungshofes ankündigen. In diesem Sinne muss man sich nicht nur prozesstechnisch anpassen, sondern eben auch kulturell.

Aber um auch mal etwas positives zu sagen: Verglichen mit dem V-Modell 92 und 97 ist das V-Modell XT bereits ein riesiger Schritt in die richtige Richtung und hat bereits so manche Kritik an den alten Modellen aufgegriffen. Ich glaube, dass sich die Lücke in den nächsten Jahren weiter schließen wird, nachdem die Diskussion, ob agile Entwicklung überhaupt „echtes Software-Engineering“ sei zugunsten der agilen Verfahren ausgestanden sein dürfte.

Roman Pichler zu Produktvisionen

Roman Pichler hat einen schönen Artikel zur Vision geschrieben, die jedem Produkt (und jedem Projekt) zugrunde liegen sollten („The Product Vision„). Für mich waren die fünf Elemente einer guten Vision am wertvollsten, auch wenn sie zum Standard einer guten Produktstrategie gehören:

1. Who is going to buy the product? Who is the target customer?
2. Which customer needs will the product address?
3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
5. What is the target timeframe and budget to develop and launch the product?

Hinzufügen könnte man noch die beiden Fragen, wer das Produkt eigentlich will (und wer nicht!) und was geschehen würde, sollte das Produkt nicht (rechtzeitig) kommen.

Der Schlüssel einer guten Vision ist der richtige Kompromiss zwischen Verständnis und Kürze. Roman verlangt, dass man die Produktvision innerhalb einer Fahrstuhlfahrt erklären können muss — allerdings stammt der „Elevator Pitch“ aus den USA, wo Bürogebäude in der Regel deutlich höher sind, als bei uns… Wichtig ist auch das Verständnis, dass die Vision im Laufe des Projektes reift. Man sollte nicht am Anfang ein halbes Jahr investieren, um die Vision zu erstellen bevor man anfängt zu arbeiten und damit durch die Hintertür den Wasserfall wieder einführen. Kundenfeedback und eigene Erfahrung sind wichtige Bestandteile einer Produktvision und beides bekommt man erst, wenn man schon ein Stück unterwegs ist.

Ich persönlich versuche, die Vision am Anfang eines zwei- bis dreitägigen Kickoff-Workshops erstmals zu fixieren. Das ist zwar häufig nur der allererste Anfang, er stellt aber sicher, dass alle Teammitglieder an ihrer weiteren Ausarbeitung beteiligt sind. Zugegebenermaßen kann man auch deutlich mehr Zeit in eine Vision investieren, ohne gleich dem Wasserfall zu verfallen, doch habe ich die Erfahrung gemacht, dass der Diskussions- und Lernprozess im Team wichtiger ist, als das formale Ergebnis. Und es schadet durchaus nicht, wenn einige Fragen erst im Laufe der ersten Iterationen geklärt werden.