Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An...

25

Transcript of Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An...

Page 1: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don
Page 2: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

Agiles Produktmanagement

mit Scrum

Inhalt.indd iInhalt.indd i 16.12.2011 09:39:2416.12.2011 09:39:24

Page 3: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

Inhalt.indd iiInhalt.indd ii 16.12.2011 09:39:5916.12.2011 09:39:59

Page 4: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

Roman Pichler

Agiles Produktmanagement

mit Scrum

An imprint of PearsonMünchen • Boston • San Francisco • Harlow, England

Don Mills, Ontario • Sydney • Mexico CityMadrid • Amsterdam

Inhalt.indd iiiInhalt.indd iii 16.12.2011 09:39:5916.12.2011 09:39:59

Page 5: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.

Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht.Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.Bei der Zusammenstellung von Abbildungen und Texten wurde mit größter Sorgfalt vorgegangen.Trotzdem können Fehler nicht vollständig ausgeschlossen werden.Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen.Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar.

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien.Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig.

Fast alle Hardware- und Softwarebezeichnungen und weitere Stichworte und sonstige Angaben, die in diesem Buch verwendet werden, sind als eingetragene Marken geschützt.Da es nicht möglich ist, in allen Fällen zeitnah zu ermitteln, ob ein Markenschutz besteht,wird das ®-Symbol in diesem Buch nicht verwendet.

Autorisierte Übersetzung der amerikanischen Originalausgabe » Agile Product Management with Scrum«.Authorized translation from the English language edition, entitled Agile Product Management with Scrum, by Roman Pichler, published by Pearson publishing as Addison Wesley, Copyright © 2010.

10 9 8 7 6 5 4 3 2 1

14 13 12

ISBN 978-3-8273-2915-8

© 2012 by Roman Pichlerein Imprint der Pearson Deutschland GmbH,Martin-Kollar-Straße 10–12, D-81829 München/GermanyAlle Rechte vorbehaltenLektorat: Brigitte Bauer-Schiewek, [email protected]Übersetzung: Roman Pichler und Jürgen DubauFachlektorat: Roman PichlerKorrektorat: Sandra GottmannHerstellung: Martha Kürzl-Harrison, [email protected] und -gestaltung: Marco Lindenbeck, webwo GmbH, [email protected]: Reemers Publishing Services GmbH, Krefeld, www.reemers.deDruck und Verarbeitung: Drukarnia Dimograf, Bielsko-BialaPrinted in Poland

Inhalt.indd ivInhalt.indd iv 16.12.2011 09:39:5916.12.2011 09:39:59

Page 6: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

Für meine ElternGeorg und Christine Pichler

Inhalt.indd vInhalt.indd v 16.12.2011 09:39:5916.12.2011 09:39:59

Page 7: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

Inhalt.indd viInhalt.indd vi 16.12.2011 09:39:5916.12.2011 09:39:59

Page 8: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

2

PRODUKTVISION UND PRODUKT-ROADMAP

Telefonkonferenzen in den frühen 1990er Jahren waren meist wenig effektiv. Die Teilnehmer mussten oft laut in ein Mikrofon sprechen, das sich nicht auf dem Tisch befand. Redeten mehrere Personen gleichzeitig, wurden ihre Stimmen stark verzerrt. Polycom, ein auf Telepräsenz-, Video- und Audiolösungen spezialisier-tes Unternehmen, erkannte, dass seine Kunden Telefonkonferenzen führen woll-ten, die ein normales Gespräch ermöglichten – ohne Verzerrungen, Echos oder andere Störungen. Folglich entwarf Polycom die folgende Vision für ein neues Produkt (Lynn und Reilly 2002, 63):

• Hervorragende Audioqualität: Mehr als eine Person kann gleichzeitig spre-chen und dennoch verstanden werden.

• Einfache Bedienung: Keine irritierenden Knöpfe oder Kabel• Erstklassiges Erscheinungsbild: Passt in das Besprechungszimmer der

Geschäftsleitung

Das fertige Produkt wurde SoundStation getauft und 1992 in den Markt ein-geführt. Den Grundstein für seinen Erfolg legte die Produktvision.

ABBILDUNG 2.1 Polycoms SoundStation

Inhalt.indd 27Inhalt.indd 27 16.12.2011 09:40:0916.12.2011 09:40:09

Page 9: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

28 • • • PRODUKTVISION UND PRODUKT-ROADMAP

Dieses Kapitel beschreibt die Produktvision und die Produkt-Roadmap. Den Anfang macht die Vision mit ihren Eigenschaften.

D I E P R O D U K T V I S I O N U N D I H R E E I G E N S C H A F T E N

Gemeinsames Ziel und Hypothese

»Würdest Du mir bitte sagen, welchen Weg ich von hier aus einschl agen soll?«, fragt Alice die Grinsekatze in der Geschichte Alice im Wunderland. »Das kommt darauf an, wohin du willst«, antwortet die Katze. »Das ist mir eigentlich egal«, sagt Alice. »Dann kommt es auch nicht darauf an, welchen Weg Du nimmst«, erwidert die Katze (Carroll 1998, 56).

Ganz ähnlich ergeht es uns bei der Entwicklung eines Produkts: Nur wenn wir uns grob vorstellen können, was unser Produkt leisten und wie es aussehen soll, können wir zielorientiert arbeiten. Unsere Vorstellung halten wir in der Produktvision fest.7 Diese skizziert das neue Produkt bzw. die neue Produktversion und formuliert das übergreifende, gemeinsame Ziel. Wie in dem eingangs beschriebenen Polycom-Beispiel charakterisiert die Produktvision das Produkt grob und selektiv und erfasst dabei die Essenz des Produkts – die für die Entwicklung und Markteinführung kritischen Informationen. Detailliert wird die Produktvision im Product Backlog. Anders gesprochen nutzte ich die Vision insbesondere bei Produktneuentwicklungen, um zu entscheiden, welche Einträge ins Backlog auf-genommen werden sollen.

Beachten Sie, dass die Vision eine Hypothese bildet. Sie hält Annahmen über das neue Produkt fest und beschreibt skizziert das Produkt basierend auf dem aktuellen Wissensstand. Validiert und gegebenenfalls angepasst wird die Vision durch Kunden- und Anwenderfeedback.

Beschränken Sie den Aufwand der Visionserstellung auf ein Minimum und testen Sie die Vision schnellstmöglich – am besten, indem Sie rasch ein erstes Produktinkrement erstellen und hierzu Kunden- und Anwenderfeedback einholen. Je schneller Sie die Vision validieren, desto rascher verstehen Sie, ob Sie auf dem richtigen Weg sind. Schließlich können auch die besten Techniken und Tools nicht garantieren, dass Sie eine erfolgversprechende Produktvision formuliert haben!

7. Die Produktvision ist zwar kein Bestandteil des Scrum Frameworks, wird aber bereits kurz im ers-ten Scrum-Buch erwähnt (Schwaber und Beedle 2002, S. 34). Scrum macht keine spezifischen Empfehlungen zum Inhalt, zur Form und zur Erstellung der Produktvision.

Inhalt.indd 28Inhalt.indd 28 16.12.2011 09:40:0916.12.2011 09:40:09

Page 10: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

DIE PRODUKTVISION UND IHRE EIGENSCHAFTEN • • • 29

Eine effektive Produktvision sollte die nachfolgend ausgeführten Eigen-schaften erfüllen.

Von al len mitgetragen

Alle an der Produktentwicklung Beteiligten sollten sich mit der Vision identifizieren: das Scrum-Team, das Management, die Kunden und Anwender und alle weiteren Stakeholder. »Eine Vision ist dann geteilt, wenn du und ich eine ähnliche Vorstellung haben und wir uns ihr gegenseitig verpflichtet fühlen und nicht nur jeder von uns alleine seiner Vorstellung folgt«, schreibt Peter Senge (2006, 192). Eine von allen mit-getragene Vision schafft eine gemeinsame Ausrichtung und schweißt die Beteiligten zusammen. »Wenn die Leute wirklich über eine gemeinsame Vision verfügen, dann sind sie verbunden, zusammengeschlossen durch ein gemeinsames Streben.« (Senge 2006, 192) Folgen die Beteiligten aber ihren individuellen Vorstellungen, so ist effek-tive Teamarbeit schwer möglich. Die Entwicklung eines erfolgreichen Produkts ist unwahrscheinlich. Ein frühes Einbinden der Teammitglieder und der Stakeholder in die Visionserstellung erleichtert das Schaffen einer gemeinsamen Vision.

Grob und motivierend

Die Produktvision sollte ein grobes und motivierendes Ziel beschreiben: Ein Ziel, das das Entwicklungsprojekt anleitet, aber noch genügend Raum für Kreativität lässt. Marissa Meyer, Vice President Search Products und User Experience bei Google, beschreibt, wie Google die Produktvision nutzt:

Wir ziehen ein Team von Leuten zusammen, denen ein Thema wirklich am Herzen liegt. Interessant ist: Wir verwenden immer noch keine detaillierten Spezifikationen. Wenn man ein 70 Seiten umfassendes Dokument erstellt, das das zu entwickelnde Produkt beschreibt, dann geht dabei die Kreativität verloren. Wie der Entwickler, der sagt: »Weißt Du was, hier ist ein Feature, das Du vergessen hast und das ich gerne noch einbauen würde.« Diese Kreativität wollen wir nicht aus dem Produkt verdrängen. Ein konsensori-entierter Ansatz, bei dem das Team gemeinsam eine Vision erstellt, die auf dem basiert, woran es gerade arbeitet, und der genügend Raum für jedes Teammitglied lässt, um sich kreativ einzubringen, ist wirklich begeisternd. Mit einer solchen Vision haben wir einige unserer besten Ergebnisse erzielt.8

8. »Inside Google’s New-Product Process,« BusinessWeek.com, 30. Juni 2006, www.businessweek.com/technology/content/jun2006/tc20060629_411177.htm.

Inhalt.indd 29Inhalt.indd 29 16.12.2011 09:40:0916.12.2011 09:40:09

Page 11: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

30 • • • PRODUKTVISION UND PRODUKT-ROADMAP

Kurz und bündig

Ihre Produktvision sollte nur die Informationen enthalten, die für den Produkterfolg ausschlaggebend sind. Die Visionen der in Lynn und Reillys Studie aufgeführten Erfolgsprodukte weisen beispielsweise nicht mehr als sechs Features auf. Die Produktvision ist also keine Feature-Liste! Dazu merkt Jim Highsmith, Experte für agiles Projektmanagement, an: »Fünfzehn oder zwanzig Produkteigenschaften aufzuzählen, ist einfach. Die drei oder vier zu selektieren, die jemanden dazu bringen, das Produkt zu kaufen, ist schwierig.« (2009, 97) Donald Reinertsen, Experte für schlanke Produktentwicklung, stimmt dem zu: »Die meisten erfolgreichen Produkte verfügen über einen klaren und einfach zu beschreibenden Mehrwert. Käufer wählen unter konkurrierenden Produkten meist auf der Basis von drei oder vier Faktoren aus.« (1997, 174 f.) Ein guter Test für Ihre Vision ist Moores Fahrstuhltest. Dieser lautet: »Können Sie Ihr Produkt während einer Fahrstuhlfahrt erklären?« (2006, 152) Fällt die Antwort negativ aus, so ist die Produktvision zu lang oder komplex.

D A S E R S T E L L E N D E R P R O D U K T V I S I O N

Zusammenarbei t und Kont inui tät

Die Vision wird am besten vom Product Owner, von den Teammitgliedern sowie ausgewählten Interessenvertretern erstellt. Spielt beispielsweise Wartbarkeit eine wichtige Rolle für den Produkterfolg, so sollte ein Mitarbeiter aus der Servicegruppe an der Visionserstellung teilnehmen, um das entsprechende Know-how einfließen zu lassen. Das gemeinsame Erstellen der Vision nutzt das Wissen und die Ideen der verschiedenen Beteiligten. Dies erhöht die Wahrscheinlichkeit, dass die Vision stimmig ist und von allen mitgetragen wird. Der Product Owner sollte dabei die Visionserstellungsarbeit leiten.

Achten Sie darauf, dass die an der Visionserstellung Beteiligten auch die Umsetzung der Vision begleiten – entweder als Teammitglieder oder als Stakeholder. Denn Übergaben führen leicht zu Informationsverlusten und Wartezeiten; Missverständnisse und Fehler schleichen sich ein. Schließlich ist Produktentwicklung Wissensarbeit, und das Wissen steckt in den Köpfen der Mitarbeiter.

Inhalt.indd 30Inhalt.indd 30 16.12.2011 09:40:0916.12.2011 09:40:09

Page 12: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

DAS ERSTELLEN DER PRODUKTVISION • • • 31

Das Product Vis ion Board

Um die Produktvision insbesondere von neuen Produkten festzuhalten, benutze ich am liebsten das von mir entwickelte Product Vision Board. Das Board hilft, die wichtigs-ten Aspekte einer Vision zu beschreiben: die Zielgruppe, die Bedürfnisse von Kunden und Anwendern, das Produkt und die Wirtschaftlichkeit. Zusätzlich wird die Vision kurz und bündig in einem Satz zusammengefasst. Abbildung 2.2 stellte das Board dar:

Welchen Mehrwert generiert das Produkt für Kunden und Anwender? Welche Bedürfnisse adressiert es? Welche Emo onen weckt es beim Benutzer?

Was sind die drei bis fünf wich gsten, für den Erfolg des Produkts ausschlaggebenden Features? Wie soll das Produkt grob aussehen Welche Technologien und Architekturprinzipien sollen zum Einsatz kommen?

Wie nützt das Produkt dem Unternehmen? Was sind die Einnahme-quellen und Vertriebskanäle? Wie hoch ist der Verkaufspreis?

Zielgruppe Bedürfnisse Produkt Wirtscha - lichkeit

Vision Statement Phrase oder Satz, der die Vision prägnant zusammenzufasst.

Welches Marktsegment, welche Kunden und Anwendern adressiert das Produkt?

ABBILDUNG 2.2 Das Product Vision Board

Die Fragen in Abbildung 2.2 wollen Ihnen helfen, die vier Aspekte so weit zu untersuchen, dass Sie Ihr initiales Product Backlog anlegen und zielgerichtet den ersten Sprint starten können. Wie sein Name andeutet, wird das Vision Board im Regelfall im Bürozimmer aufgehängt, sodass es für alle Beteiligten gut sichtbar ist. Ein fertiges Vision Board sieht beispielsweise so aus:

Inhalt.indd 31Inhalt.indd 31 16.12.2011 09:40:1016.12.2011 09:40:10

Page 13: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

32 • • • PRODUKTVISION UND PRODUKT-ROADMAP

Vision Statement Ein einfach zu bedienendes, cooles und erschwingliches Megaprodukt.

Zielgruppe Bedürfnisse Produkt Wirtscha - lichkeit

Scenario 1 Lorem ipsum dolor sit amet, sectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam.

ennnnnnnnnnnnnnnnnnnnaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrrrrrrrrri Feature #1 Feature #2 Feature #3

tttttttttttttttttttttttttttttuuuuuuuuuuuuuuuuuuuuuuuuuuuurrrrrrrrrr

.

Scenario 3 Lorem ipsum dolor sit amet, sectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam.

ennnnnnnnnnnnnnna

3

ABBILDUNG 2.3 Ein Beispiel eines Product Vision Boards

Das Board in Abbildung 2.3 enthält zwei Personas, drei Szenarien, die drei wichtigsten Features, eine Designskizze der Benutzeroberfläche, eine Architek-turskizze und ein grobes Geschäftsmodell. Die nachfolgenden Abschnitte erläu-tern die Abschnitte des Boards samt Artefakten. Bitte beachten Sie, dass die aufgeführten Artefakte für Ihr Produkt nicht ausreichend sein können und Sie ggf. weitere Arbeitsergebnisse wie zum Beispiel eine Wettbewerbsanalyse erstellen und in das Board mitaufnehmen sollten.

Visionsbox und RezensionZwei alternative Darstellungsformen der Produktvision sind Visionsbox und Rezension. Eine Visionsbox ist eine Verpackungsattrappe, die das Scrum-Team am besten gemeinsam bastelt (vgl. Highsmith 2009, 96 f.). Auf der Vorderseite der Box werden der Produktname, eine Abbildung des Produkts sowie drei Schlagwörter festgehalten, die einen Kaufanreiz darstellen. Auf der Rückseite finden sich weitere Produktinformationen wie die Zielgruppe und der Mehrwert des Produkts.

Eine Rezension beschreibt die Produktkritik, die Sie in Fachzeitschriften nach der Markteinführung Ihres Produkts lesen möchten (Cohn 2009, 232). Diese Technik hilft, die Erfolgsfaktoren des Produkts herauszuarbeiten und gleichzeitig zu über-prüfen, ob Scrum-Team und Stakeholder über eine gemeinsame Vision verfügen – vorausgesetzt, die Rezension wird gemeinsam erstellt bzw. besprochen.

Inhalt.indd 32Inhalt.indd 32 16.12.2011 09:40:1116.12.2011 09:40:11

Page 14: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

DAS ERSTELLEN DER PRODUKTVISION • • • 33

Die Zielgruppe mit Personas beschreiben

Das Board in Abbildung 2.3 enthält zwei Personas, die die Zielgruppe charakte-risieren. Eine Persona ist ein »hypothetischer Archetyp«, der einen Zielkunden oder -anwender verkörpert (Cooper 1999). Um eine Persona zu erstellen, erfin-den wir am besten eine repräsentative Person. Dieser geben wir einen Namen, ein Alter, einen Beruf, Hobbys, ein soziales Umfeld und ein Gesicht, z.B. in Form eines Fotos. Die demografischen Angaben helfen uns u.a., über die Positionierung des Produkts zu entscheiden: Soll es sich um preisgünstige Massenware oder ein Premiumprodukt handeln? Manche Teams gestalten Personas als menschengroße Pappfiguren und stellen diese im Teamzimmer auf. Dies erinnert alle Beteiligten an die Anwender und Kunden des Produkts.

Meine Empfehlung für den Einsatz von Personas lautet: Begrenzen Sie deren Anzahl auf zwei bis drei pro Produktversion. Benötigen Sie mehr, um den Mehrwert Ihres Produkts herauszuarbeiten, so kann dies ein Indiz dafür sein, dass es eine zu große Zielgruppe adressiert. In diesem Fall rate ich Ihnen, die Zielgruppe für die nächste Produktversion einzuschränken, um so ein minimales Produkt zu entwickeln. (Ich erläutere minimale Produkte später in diesem Kapitel.)

Die Bedürfnisse mithi l fe von Szenarien untersuchen

Der Mehrwert für Anwender und Kunden wird in Abbildung 2.5 durch drei Szenarien beleuchtet. Diese untersuchen, wie das Produkt das Leben der Personas beeinflusst. Dabei halten wir fest, wie eine Persona ihr Ziel ohne und mit dem neuen Produkt erreicht.9 Szenarien helfen uns, den Mehrwert des Produkts zu überprüfen: Sind alle Features wirklich notwendig? Generieren sie einen Mehrwert für alle Personas? Sind die Attribute Alleinstellungsmerkmale? Verstecken sich noch weitere wichtige Features in dem Produkt?

Das Trennen von Bedürfnissen und Lösung im Vision Board erlaubt uns zu hinterfragen, warum das Produkt benötigt wird, was es in etwa leisten soll und wie es grob aussehen muss. Es ermöglicht uns außerdem, verschiedene Alternativen zu untersuchen, um die geeignetsten Features herauszufinden. Ein Touchscreen stellt beispielsweise eine Möglichkeit dar, eine einfache Bedienung zu realisieren.

9. Szenarien lassen sich auch in Form von Consumption Maps darstellen (Womack und Jones 2005). Hierzu erstellen wir zunächst eine Wertstromanalyse des aktuellen Prozesses inklusive Wartezeiten, Defekten und anderen Formen von Verschwendung. Anschließend zeichnen wir den neuen Prozess, der die Schritte mit Verwendung des Produkts festhält.

Inhalt.indd 33Inhalt.indd 33 16.12.2011 09:40:1416.12.2011 09:40:14

Page 15: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

34 • • • PRODUKTVISION UND PRODUKT-ROADMAP

Eine Alternative ist die Verwendung einer geringen Anzahl großer Tasten oder aber der Einsatz von Sprachsteuerung.

Das Produkt skizzieren

Das Produkt wird in Abbildung 2.3 durch die drei wichtigsten Features, eine Skizze des UI-Designs und eine Architekturskizze umrissen. Beachten Sie, dass Kunden ein Produkt nicht nur aufgrund seiner Funktionalität erwerben, sondern weil sie hoffen, sich durch den Besitz und Gebrauch des Produkts besser zu füh-len. Boatwright und Cagan (2010, 13) bezeichnen die Emotionen, die ein Produkt bei Kunden und Anwendern hervorruft, als Produktemotionen und stellen fest: »Das iPhone war anfangs nicht aufgrund seiner Funktionalität, sondern wegen sei-ner Produktemotionen erfolgreich: den Gefühlen, die die Menschen hatten, wenn sie das Produkt sahen, berührten und benutzten, und der Art und Weise, wie es in ihr Leben und zu ihrem Lifestyle passte.« Damit ein Produkt erfolgreich ist, sollte es also nicht nur die richtige Funktionalität zur Bewältigung einer Aufgabe bereitstellen, sondern positive Emotionen bei seinen Kunden und Anwendern aus-lösen. Eine ähnliche Empfehlung spricht das Kano-Modell aus, wenn es dazu rät, dass jedes Produkt mindestens ein Begeisterungsmerkmal aufweisen sollte (Kano 1984).10

Untersuchen Sie nicht nur die funktionalen Eigenschaften des Produkts, sondern auch die nichtfunktionalen, um die drei bis fünf wichtigsten Features herauszuarbeiten. Erstere sind spezifische Produktfunktionen, die ein Anwender nutzen kann, wie beispielsweise das Tätigen oder Empfangen eines Anrufs. Beispiele für nichtfunktionale Anforderungen sind Performanz, Robustheit, Style, Design und Benutzerfreundlichkeit. Nichtfunktionale Attribute kön-nen Alleinstellungsmerkmale bilden und das Nutzererlebnis (engl. user expe-rience) sowie die Erweiterbarkeit und Wartbarkeit des Produkts beeinflussen. Letztere beeinflussen die vom Produkt verursachten Gesamtkosten und seine Lebenserwartung. Die entscheidenden Features für die Entwicklung des Google Chrome Browsers waren beispielsweise die drei nichtfunktionalen Eigenschaften Geschwindigkeit, Einfachheit und Sicherheit.11

Stehen Features im Konflikt zueinander wie zum Beispiel Interoperabilität und Wartbarkeit, so kann es hilfreich sein, diese zu priorisieren. Auf verschiede-

10. Ich bespreche das Kano-Modell ausführlicher in Kapitel 3.11. »Technology overview«, http://www.google.com/about/corporate/company/tech.html

Inhalt.indd 34Inhalt.indd 34 16.12.2011 09:40:1416.12.2011 09:40:14

Page 16: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

DAS ERSTELLEN DER PRODUKTVISION • • • 35

nen Systemen und Geräten einsetzbar zu sein, bedingt typischerweise ein gewisses Maß an architektureller Komplexität. Wartbarkeit hingegen legt nahe, eine ein-fache, leicht veränderbare Architektur zu verwenden. Beides gleichermaßen gut umzusetzen, ist – so überhaupt möglich – teuer und schwierig. Daher müssen wir uns entscheiden und eine Eigenschaft als wichtiger ansehen. Dabei wende ich gerne folgende Faustregel an: Features, die mehrere Bedürfnisse adressieren, sind besonders wichtig und somit von höchster Priorität.

Vermeiden Sie den Fehler, das Produkt- bzw. UI-Design möglichst voll-ständig vorab festzulegen. Konzentrieren Sie sich auf die Aspekte, die essenziell für die Benutzererfahrung und den Produkterfolg sind und die sich zu einem späteren Zeitpunkt nur unter sehr hohen Kosten ändern lassen. Der Großteil des Designs sollte inkrementell von Sprint zu Sprint entstehen, um so von Kunden- und Anwenderfeedback zu profitieren! Neben dem Erstellen einer Skizze kön-nen Storyboards oder Wegwerfprototypen hilfreich sein, um wichtige Aspekte des Benutzeroberflächendesigns zu untersuchen, Entscheidungen festzuhalten und ggf. erstes Anwenderfeedback einzuholen.

Ähnliches gilt für die Softwarearchitekturskizze: Machen Sie Ihre Annahmen über die zentralen Architekturprinzipien wie SOA oder komponentenbasiert und die wichtigsten Technologien wie beispielsweise .Net oder Enterprise Java expli-zit. Die Architekturdetails und das Softwaredesign sollten aber in den Sprints erstellt werden, um auf Änderungen reagieren und Lernergebnisse einarbeiten zu können.12 Besitzt Ihr Produkt eine innovative oder komplexe Architektur bzw. Technologieauswahl, so ist es meist sinnvoll, die Architekturskizze mithilfe von Spikes – ausführbaren Wegwerfprototypen – zu erstellen und dabei Ideen und Optionen rasch zu validieren.

Experimentieren mit (Wegwerf-)PrototypenWenn wir uns mit einer innovativen Produktidee beschäftigen, verfügen wir meist nur über wenig Wissen. Oftmals ist uns nicht bewusst, was wir alles nicht wissen. Fällt es uns schwer, die Fragen in Abbildung 2.2 zu beantwor-ten, so kann gezieltes Experimentieren mit Prototypen sinnvoll sein, das rele-vante Wissen schnell zu erwerben. Die erstellten Prototypen sind typischerweise Wegwerfartefakte, die schnell und kostengünstig entwickelt werden können. Ein neues Telekommunikationsprodukt, an dem ich als Entwicklungsleiter mitarbei-tete, sollte beispielsweise eine deutlich verbesserte Benutzbarkeit ausweisen. Also

12. Pichler und Roock (2011) erläutern die Themen Architekturvision und inkrementelles Design sowie weitere agile Entwicklungspraktiken ausführlich.

Inhalt.indd 35Inhalt.indd 35 16.12.2011 09:40:1416.12.2011 09:40:14

Page 17: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

36 • • • PRODUKTVISION UND PRODUKT-ROADMAP

erstellte das Team einen Prototypen bestehend aus einer Geräteattrappe und einem Flash-Programm und simulierte so wichtige Aspekte der neuen Benutzeroberfläche. Anschließend wurden Kunden eingeladen, den Prototyp zu testen. Das Feedback half, das Produktdesign richtig zu gestalten und eine tragfähige Vision zu kreie-ren. Das Erstellen eines ersten Produktinkrements zum Austesten der Benutzbarkeit wäre übrigens zu teuer und langwierig gewesen; bestand das Produkt doch aus Hardware, Firmware, Software und einer Gerätehülle aus Plastik.

Experimentieren untersucht die Beziehung zwischen Ursache und Wirkung, wobei die Ursache so lange verändert wird, bis sich der gewünschte Effekt einstellt. Für ein erfolgreiches Experimentieren ist das Kultivieren einer offenen, spielerischen Haltung genauso wie ein systematisches Vorgehen notwendig. Um effektiv zu expe-rimentieren, folgen wir am besten einem vierstufigen Prozess, der auch als Deming-Zyklus, PDCA oder wissenschaftliche Methode bezeichnet wird.13 Abbildung 2.4 stellt den Prozess dar.

Planen

Aus- führen

Über- prüfen

Handeln

ABBILDUNG 2.4 Der Deming-Zyklus

Im Deming-Zyklus entwickeln wir zuerst eine Hypothese (Planen). Dann testen wir diese (Ausführen) und begutachten das Ergebnis (Überprüfen). War das Experiment nicht erfolgreich, wird – wenn nötig – die Hypothese angepasst und eine weitere Experimentierrunde eingeleitet, entweder um das Ergebnis zu verbes-sern oder einen anderen Lösungsweg zu testen (Handeln). Thomas Edison, der Schöpfer der ersten kommerziell erfolgreichen elektrischen Glühbirne und Gründer von General Electric, wusste um das Scheitern als notwendigem Bestandteil von Innovation, als er sagte: »Auch wenn etwas zehntausend Mal nicht funktioniert, so bin ich doch nicht gescheitert. Ich bin auch nicht niedergeschlagen, weil jeder falsche Versuch mich einen Schritt nach vorne bringt.«

13. PDCA steht für Plan, Do, Check und Act. In jüngerer Zeit hat sich der Begriff Build-Measure-Learn verbreitet, der die Schritte Act und Plan durch Learn zusammenfasst (vgl. Ries 2011).

Inhalt.indd 36Inhalt.indd 36 16.12.2011 09:40:1416.12.2011 09:40:14

Page 18: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

DAS ERSTELLEN DER PRODUKTVISION • • • 37

Eine Wirtschaft l ichkei tsbetrachtung vornehmen

Schließlich findet sich in der letzten Spalte des Boards in Abbildung 2.3 eine Wirtschaftlichkeitsbetrachtung in Form eines vereinfachten Business Model Canvas.14 Diese enthält die Partner, die Vertriebskanäle, die Kundenbeziehung, die Kostenstruktur, Umsatzquellen, Ressourcen und die wichtigsten Aktivitäten, um das Produkt absetzen zu können. Dabei finde ich es wichtig, dass sich Product Owner und Team Gedanken über die Gründe machen, warum das Unternehmen in die Produktentwicklung investieren sollte. Ein ausgefeiltes Geschäftsmodell und ein detaillierter Business-Plan sind aber nicht immer sinnvoll: Insbesondere für neuartige, disruptive Produkte ist es normalerweise nicht möglich, belastbare Aussagen zu Umsatz und Gewinn zu machen. Schließlich existiert der Markt bzw. das Marktsegment noch nicht. Und ohne unternehmerische Risikobereitschaft gäbe es kein Google Search, Facebook, Twitter und Skype. Denn all diese Produkte wurden entwickelt, ohne dass ganz klar war, wie das jeweilige Unternehmen Geld mit dem Produkt verdienen würde.

Die Informationen visual is ieren

Das Visualisieren der Produktvision halte ich für ganz wichtig: Es schafft Transparenz und erinnert die Projektbeteiligten an das gemeinsame, übergeord-nete Ziel. Gleichzeitig macht der nur begrenzt verfügbare Platz eine Fokussierung auf die wichtigsten Informationen notwendig. Hängen Sie das Vision Board am besten so im Büro auf, dass es für alle Beteiligten gut sichtbar ist.

Für große oder verteilte Projekte, die eine digitale Produktvision notwendig machen, können Sie Ihr Vision Board als Foto auf Ihrem Wiki-Server ablegen oder die in Abbildung 2.2 dargestellte Struktur in einem elektronischen Spreadsheet nachbilden – solange dieses für alle Beteiligten leicht zugänglich ist.

Der Einsatz von konvent ionel len Marktforschungstechniken

Zusätzlich zu den beschriebenen Techniken können Sie selbstverständlich auch herkömmliche Marktforschungsmethoden einsetzen wie Kundenbefragungen oder Fokusgruppen. Beachten Sie hierbei aber Folgendes: Erstens liefert die Verwendung von Prototypen Produktinkrementen meist verlässlichere Daten als das Besprechen von Ideen und Konzepten. Kunden können insbesondere über innovative Produkte

14. Siehe Osterwalder und Pigneur (2010) für mehr Informationen zum Business Model Canvas.

Inhalt.indd 37Inhalt.indd 37 16.12.2011 09:40:1416.12.2011 09:40:14

Page 19: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

38 • • • PRODUKTVISION UND PRODUKT-ROADMAP

keine qualifizierte Auskunft geben, ohne eine Vorabversion des Produkts gesehen oder ausprobiert zu haben. Zweitens sollten Sie zur Erstellung der Produktvision nur so viel Marktforschung ausführen, wie unbedingt nötig ist. Denn die beste Produktvision ist nur eine Hypothese, die möglichst rasch mithilfe eines ersten Produktinkrements überprüft werden sollte. Beachten Sie: Marktforschung endet in Scrum nicht mit der Beschreibung der Vision, sondern setzt sich in den Sprints fort. Die Sprint-Review-Besprechungen sind ein qualitatives Marktforschungsinstrument. Diesen Zusammenhang stellt Abbildung 2.5 dar, indem sie Marktforschungsaufwand (y-Achse) bezogen auf die Zeit (x-Achse) betrachtet:

Traditionell Agil

ABBILDUNG 2.5 Verteilung des Marktforschungsaufwands über die Zeit

Außerdem gilt für neue, disruptive Produkte: Die Anwender existieren-der Produkte sind meist schlechte Informationslieferanten für das neue Produkt (Christensen 1997). Hätte Apple auf die Meinung der Mehrheit der Smartphone-Benutzer im Jahre 2005 gehört, so hätte das iPhone wohl ganz anders ausgesehen. Oder wie Henry Ford sich ausgedrückt hat: »Hätte ich die Kunden gefragt, was Sie wollen, hätten sie geantwortet »ein schnelleres Pferd«. Dies heißt natürlich nicht, dass Kunden- und Anwenderfeedback nicht nützlich oder gewollt ist. Im Gegenteil: In Scrum sollten Sie Kunden und Anwender frühzeitig und regelmä-ßig in die Softwareentwicklung einbeziehen. Dennoch müssen Sie eine eigene Vorstellung, eine eigene Vision von dem zukünftigen Produkt entwickeln. Denn ohne eine solche können Sie das Feedback nur schwer einordnen.

D A S M I N I M A L E P R O D U K T A L S A G I L E P R O D U K T P L A N U N G S T E C H N I K

Um die Produktvision zu erstellen, muss das Scrum-Team in die Zukunft bli-cken und Annahmen über das Erscheinungsbild und die Funktionalität des Produkts treffen. Die Zukunft korrekt vorherzusagen, ist jedoch notorisch

Inhalt.indd 38Inhalt.indd 38 16.12.2011 09:40:1416.12.2011 09:40:14

Page 20: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

DAS MINIMALE PRODUKT ALS AGILE PRODUKTPLANUNGSTECHNIK • • • 39

schwierig. Mit Gewissheit können wir nur sagen, dass die Zukunft unge-wiss ist. Die Marktentwicklung perfekt antizipieren und eine 100% sichere Investitionsentscheidung treffen zu können, ist eine Illusion. Cooper (2001, 10) nennt beispielsweise eine Fehlschlagrate von 25% bis 45% für neue Produkte. Andere Studien sprechen von einer noch höheren Misserfolgswahrscheinlichkeit. Märkte können sich unerwartet entwickeln, und Kundenverhalten ist oft schwer vorhersagbar, wie das unten aufgeführte Beispiel veranschaulicht. Dabei hängt die Vorhersagefähigkeit von der Dynamik des Markts und der Neuheit des Produkts ab. Für etablierte, weitgehend konstante Märkte und reife Produkte kann die Marktreaktion oft einigermaßen gut vorhergesagt werden. Andernfalls ist dies schwierig bis unmöglich, wie im Fall von disruptiven Innovationen, also von Produkten, die das entsprechende Marktsegment drastisch verändern oder einen neuen Markt schaffen. Denn es gilt: »Märkte, die nicht existieren, lassen sich nicht analysieren.« (Christensen 1997, 143)

Als Expertcity 1999 ein interaktives Support-System für PCs in den Markt einführte, hatte das Unternehmen hohe Erwartungen. Denn die Marktforschungsergebnisse deuteten darauf hin, dass das neue Produkt ein durchschlagender Erfolg werden würde. Leider stellte sich dieser nicht ein. Das Unternehmen bemerkte aber, dass die Anwender die Desktop-Sharing-Funktionalität des Produkts anders als gedacht nutzten, nämlich zur Fernwartung von PCs. Expertcity passte folglich sein Produkt an und führte es als Fernwartungstool neu in den Markt ein. Das neue Produkt wurde GoToMyPC getauft und verkaufte sich so erfolgreich, dass das Unternehmen von Citrix für 25 Millionen US-Dollar im Jahre 2003 erworben wurde. GoToMyPC ist seitdem Teil des Citrix-Produktportfolios.

Fällt es uns schwer, die Zukunft korrekt vorherzusagen, so ist unsere beste Erfolgsstrategie, das Produkt möglichst rasch und mit möglichst wenig Geld zu entwickeln. Ermöglicht wird dies durch die Entwicklung eines minimalen Produkts – eines Produkts, das gerade so viel Funktionalität besitzt, um die ausgewählten Kundenbedürfnisse zu adressieren. Um die Menge an benötigter Funktionalität gering zu halten, folgen wir am besten Steven Blanks Empfehlung: »Entwickeln Sie ein Produkt für wenige, nicht für viele [Kunden].« (Blank 2005, S. 29)

Ein gutes Beispiel ist die erste Version des iPhone, das 2007 auf den Markt kam. Apple vermied es, die Konkurrenz bezüglich des Funktionalitätsumfangs überbieten zu wollen. Stattdessen verzichtete das Unternehmen bewusst auf Features: Das erste iPhone wurde ohne Funktionalität ausgeliefert, die bei ande-

Inhalt.indd 39Inhalt.indd 39 16.12.2011 09:40:1516.12.2011 09:40:15

Page 21: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

40 • • • PRODUKTVISION UND PRODUKT-ROADMAP

ren Smartphones zum Standard gehörten – zum Beispiel ohne Copy&Paste und ohne die Verfügbarkeit eines Software Development Kits. Einige Features wie die Sprachqualität zählten außerdem nicht zur Spitzenklasse – ohne dass dies dem Erfolg des Produkts Abbruch tat. Denn das Produkt war so attraktiv und imple-mentierte die für seine Zielgruppe wichtigen Features so gut, dass die Benutzer seine Einschränkungen in Kauf nahmen. Möglich wurde eine Reduktion des Funktionalitätsumfangs durch ein Fokussieren der Zielgruppe: Apple verzich-tete in der ersten iPhone-Version bewusst auf ein lukratives Marktsegment: die Unternehmenskunden.

Durch das Eingrenzen der Zielgruppe und das Fokussieren auf die ent-scheidende Funktionalität konnte Apple das Produkt verhältnismäßig schnell auf den Markt bringen. Dies verhalf dem Unternehmen nicht nur zu einem Wettbewerbsvorteil, sondern Apple konnte das gewonnene Marktfeedback nut-zen, um das Smartphone weiterzuentwickeln. Die zweite iPhone-Generation, das iPhone 3G, besaß eine verbesserte Hard- und Software und war nun auch für Unternehmenskunden geeignet.

Ganz anders verhält es sich mit einem anderen Apple-Produkt, dem Apple Newton. Dieser wurde nach fünf Jahren Entwicklungszeit 1993 auf den Markt gebracht. Erinnern Sie sich noch an die Apple-Werbung aus den 90er-Jahren, die uns den ultimativen PDA versprach, der spielerisch die Handschrift erkennen konnte? In Wahrheit war der Newton zu groß und zu schwer. Sein wichtigstes Feature, die Handschrifterkennung, funktionierte zunächst nicht richtig. Das Produkt war kein durchschlagender Erfolg und wurde folglich 1998 vom Markt genommen. Rückblickend waren Apples Newton-Pläne überambitioniert: Das Unternehmen wollte in dem Produkt zu viel auf einmal umsetzen – und scheiterte dabei.

Da die Entwicklung eines minimalen Produkts unser Investitionsrisiko redu-ziert, können wir Fehlschläge als Teil unseres Wirtschaftens anzusehen, ähnlich wie Google dies tut. Googles Marissa Meyer drückt sich folgendermaßen aus: »Wir wissen, dass wir viele Produkte wegwerfen müssen, aber die Leute werden sich an die erinnern, die über ein hohes Anwenderpotenzial verfügen.«15 Floppt ein minimales Produkt, so kann dies immer noch schmerzlich sein. Aber wir haben vergleichsweise wenig Geld in den Sand gesetzt und rasch unsere Lektion gelernt.

15. »So Much Fanfare, So Few Hits,« BusinessWeek.com, 10. Juli 2006, www.businessweek.com/magazine/content/06_28/b3992051.htm. Eine ähnliche Haltung kommuniziert das folgende Motto, das Art Fry con 3M zugesprochen wird: »Man muss eine Menge Frösche küssen, um einen Prinzen zu finden.« Ein stattlicher Prinz wiegt viele Frösche auf.

Inhalt.indd 40Inhalt.indd 40 16.12.2011 09:40:1516.12.2011 09:40:15

Page 22: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

EINFACHHEIT ALS LEITPRINZIP • • • 41

MMF und MVPDie Idee, wenig Funktionalität schnell in den Markt einzuführen, um vom Feedback zu lernen und das Produkt inkrementell wachsen zu lassen, findet sich bereits in Gilb (1988). Mark Dennes und Jane Cleland-Huangs Buch Software by Numbers führt den Begriff Minimal Marketable Feature Set (MMF) ein, um die kleinste Menge an mehr-wertschaffender Funktionalität zu bezeichnen. In der jüngeren Vergangenheit hat sich der Begriff des Minimal Viable Product (MVP) verbreitet (Ries 2011). Dieser bezeichnet das Produkt, das dem Team erlaubt, möglichst günstig und schnell die Annahmen in der Produktvision zu überprüfen. Oft ist ein Prototyp oder ein Alpha-Release ein MVP. Siehe hierzu auch den Priorisierungsfaktor »Auslieferbarkeit« in Kapitel 3.

E I N F A C H H E I T A L S L E I T P R I N Z I P

Das Prinzip der Einfachheit (engl. simplicity) hilft uns, ein leicht benutzbares Produkt mit minimalem Funktionalitätsumfang zu entwickeln. Einfachheit ist oft nicht einfach zu erlangen. Denn es gilt: »Einfachheit ist die höchste Stufe der Vollendung«, wie Leonardo da Vinci sagte.

Ockhams Rasiermesser

Die Anwendung von Einfachheit als Leitprinzip besitzt eine lange Tradition in Philosophie und Wissenschaft. So soll Wilhelm von Ockham im 14. Jahrhundert vorgeschlagen haben, dass bei funktionaler Gleichwertigkeit stets die einfachere Lösung zu bevorzugen ist (Lidwell, Holden und Butler 2003, 142). Diese Einsicht wird als Ockhams Rasiermesser bezeichnet.

Einfachheit bezieht sich dabei nicht nur auf die Ästhetik des Produkts, sondern bedingt eine Fokussierung auf das Wesentliche – und damit nur das zu entwickeln, was wirklich notwendig ist. Ein einfaches Produkt ist meist leichter zu verändern und zu benutzen wie zum Beispiel Apples iPod. Der Click-Wheel-iPod, bei dem alle Knöpfe auf einer Scheibe platziert sind, ist einfach und schlicht, verfügt aber den-noch über alle wichtigen Funktionen eines MP3-Players, wie Abbildung 2.8 zeigt.

ABBILDUNG 2.6 Click-Wheel-iPod

Inhalt.indd 41Inhalt.indd 41 16.12.2011 09:40:1516.12.2011 09:40:15

Page 23: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

42 • • • PRODUKTVISION UND PRODUKT-ROADMAP

Der Gegenpol der Einfachheit ist die Komplexität. Unnötig komplexe Produkte – Produkte, die mehr Funktionalität aufweisen oder eine komplexere Architektur, als unbedingt notwendig ist, verstoßen gegen das Einfachheitsprinzip. Je komplexer ein Produkt ist, desto mehr Mitarbeiter werden für seine Entwicklung benötigt und umso länger dauert es normalerweise, bis das Produkt auf den Markt gebracht werden kann.

Weniger is t mehr

Üblicherweise nehmen wir an, dass ein Produkt mehr Funktionalität als die Konkurrenz anbieten muss, um erfolgreich zu sein. Mehr Features werden gerne mit besser und begehrenswerter gleichgesetzt. Dem ist aber nicht notwendigerweise so. 37Signals, ein Anbieter preisgekrönter, leicht benutzbarer Webapplikationen, entwirft beispielsweise seine Produkte unter dem Gesichtspunkt der Einfachheit und beschränkt sich dabei auf das Wesentliche (37Signals 2006):

Tun Sie weniger als Ihre Wettbewerber, um diese zu übertreffen ... Nehmen Sie die Funktionalität, die Ihr Produkt Ihrer Meinung nach beinhalten sollte, und halbieren Sie diese ... Beginnen Sie mit einer schlanken, smar-ten Applikation und bringen Sie diese auf den Markt. Dann können Sie Ihr Produkt gezielt erweitern.

Einfachheitsexperte und MIT-Professor John Maeda stimmt dem zu: »Ein-fachheit lässt sich am einfachsten durch bewusstes Weglassen erzielen.« (2006, 1) Und Steve Jobs wird folgendermaßen zitiert: »Innovation heißt nicht, Ja zu allem zu sagen, sondern Nein zu allem, außer den wirklich wichtigen Features.« Das Manifest für agile Softwareentwicklung teilt diese Einsicht. Es führt Einfachheit als eines sei-ner zwölf Prinzipien auf, bezeichnet Einfachheit als essenziell und beschreibt es als »die Kunst, die nichtgetane Arbeit zu maximieren.« (Beck et al. 2001)

Wann immer Sie eine neue Idee haben oder ein neues Feature entde-cken, fragen Sie sich am besten, ob die Funktionalität wirklich wichtig für den Produkterfolg ist. Ist dem nicht so, dann verwerfen Sie die Idee. Dieses Vorgehen führt zu einem einfachen, schlichten Produkt, das nur die Funktionalität enthält, die Kunden und Anwender wirklich benötigen.

Inhalt.indd 42Inhalt.indd 42 16.12.2011 09:40:1516.12.2011 09:40:15

Page 24: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

VORAUSSETZUNGEN FÜR INNOVATIONEN SCHAFFEN • • • 43

Einfache Benutzerschni t ts te l len

Ein weiteres Unternehmen, das Einfachheit als zentrales Prinzip für das Design von Benutzerschnittstellen verwendet, ist Google. »Google nimmt sich nicht vor, Produkte mit einem großen Funktionalitätsumfang zu kreieren; unsere besten Designs beinhalten nur die Features, die die Leute benötigen, um ihre Ziele zu erreichen. Idealerweise sollten selbst die Produkte mit Funktionalität und einer komplexen Benutzerschnittstelle genauso einfach wie mächtig sein. ... Wir hoffen, dass sich unsere Produkte in neue Richtungen entwickeln, anstelle dass wir immer mehr Features dazu packen«, schreibt das Unternehmen.16 Einfache, leicht bedienbare Benutzerschnittstellen zu entwerfen, hat sich laut Lidwell, Bolden und Butler für Google bezahlt gemacht: »Während andere Internet-Suchdienste immer mehr Werbung und Funktionalität zu ihren Webseiten hinzufügten, hielt Google seine schlicht und effizient. Das Ergebnis ist der leistungsfähigste und am einfachsten zu bedienende Suchdienst im Web.« (2003, 143). Und Bernard Girard, Autor von The Google Way (2009, 34), argumentiert, dass Einfachheit von Googles Werbeprogramm AdWords für dessen Erfolg entscheidend ist:

Wie die intuitive Macintosh GUI, die Apple-Produkte so benutzerfreund-lich und einfach zu bedienen macht, so hat auch das Design und die Benutzerfreundlichkeit der Google AdWords-Benutzerschnittstelle dem Produkt zu seinem Erfolg verholfen. Jeder Werbekunde versteht ganz ein-fach, wie eine Werbung platziert wird.

V O R A U S S E T Z U N G E N F Ü R I N N O V A T I O N E N S C H A F F E N

Viele Unternehmen wollen innovativ sein und durch neue Produkte wachsen. Doch in der Hektik des Arbeitsalltags bleibt den Mitarbeitern für die Generierung und Exploration neuer Ideen oft wenig Zeit. Um Raum für Innovationen zu schaf-fen, stellen Unternehmen wie Google und 3M ihren Mitarbeitern ein Zeitbudget für die Beschäftigung mit neuen Ideen zur Verfügung. Bei Google sind dies 20% der Arbeitszeit. Die Innovationsaktivitäten, die im Rahmen dieses Zeitkontingents erfolgen, werden auch als » Forschungsprojekt« (engl. research project) bezeichnet. Die Hälfte aller neuen Google-Produkte, die in den ersten sechs Monaten des Jahres 2005 entwickelt wurden, stammte aus solchen Projekten (Meyer 2006). Die folgen-den Faktoren unterstützten Innovationen bei Google (Savoia und Copeland 2011):

16. »Ten principles that contribut e to a Googley user experience,« www.google.com/corporate/ux.html.

Inhalt.indd 43Inhalt.indd 43 16.12.2011 09:40:1516.12.2011 09:40:15

Page 25: Agiles Produktmanagement mit Scrum - Pearson · Roman Pichler Agiles Produktmanagement mit Scrum An imprint of Pearson München † Boston † San Francisco † Harlow, England Don

Copyright

Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell angebotenen eBook-Zusatzdaten sind urheberrechtlich geschützt. Dieses eBook stellen wir lediglich als persönliche Einzelplatz-Lizenz zur Verfügung!

Jede andere Verwendung dieses eBooks oder zugehöriger Materialien und Informationen, einschließlich

• der Reproduktion,

• der Weitergabe,

• des Weitervertriebs,

• der Platzierung im Internet, in Intranets, in Extranets,

• der Veränderung,

• des Weiterverkaufs und

• der Veröffentlichung

bedarf der schriftlichen Genehmigung des Verlags. Insbesondere ist die Entfernung oder Änderung des vom Verlag vergebenen Passwortschutzes ausdrücklich untersagt! Bei Fragen zu diesem Thema wenden Sie sich bitte an: [email protected]

Zusatzdaten

Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die Zurverfügungstellung dieser Daten auf unseren Websites ist eine freiwillige Leistung des Verlags. Der Rechtsweg ist ausgeschlossen.

Hinweis

Dieses und viele weitere eBooks können Sie rund um die Uhr und legal auf unserer Website herunterladen:

http://ebooks.pearson.de