Estrategy#36 Leseprobe

E-Commerce // Onlinemarketing // SEO // SEM // Development // Mobile // Technik // Usability // Recht // Tipps&Tools

#36 09/2018 - 12/2018

s e l i g A r e b ü Fünf Irrtümer

t n e m e r i u q e R

g n i r e e Engin

E-Commerce klassische ITSM-Methoden und Agilität – Widerspruch oder doch vereinbar?

Projektmanagement mit dem Barcamp agil werden

Payment-Methoden erfolgreiches Unified-Commerce Strategie

Online-Strategie Kundenverständnis ist King

© fotogestoeber / Fotolia

powered by

www.estrategy-magazin.de

CROSSFUNCTIONAL CONFERENCE HOCHSCHULE ROSENHEIM 28.09.2018 JETZT REGISTRIEREN

EINBLICKE UND IMPULSE FÜR DIE ARBEITSWELT VON MORGEN AUSTAUSCHPLATTFORM FÜR STUDIERENDE,WIRTSCHAFT UND WISSENSCHAFT USE CASES & BEST PRACTICES INTERAKTIVE BARCAMP SESSIONS RUNDUM VERPFLEGUNG GET-TOGETHER AM ABEND

SPEAKER

MARGARETE VOLL

DR. SEBASTIAN SPÖRER

ROBERT FRANK

SACHA STORZ

Abteilungsdirektorin, Projekt-

Führender Experte zum Thema

Leiterin “Allianz in Führung”

Neuro-Agile Leadership

Director Employee Success DACH, Salesforce Inc.

Dipl. Psychologe, Agile Coach, Autor und Speaker

Die X-Conference ist eine Gemeinschaftsveranstaltung der Hochschule Rosenheim und TechDivision.

www.x-conference.de

Editorial

Fünf Irrtümer über Agiles Requirements Engineering Agiles Arbeiten bzw. Projektmanagement ist inzwischen in nahezu allen Bereichen angekommen und es ist mittlerweile einfach “schick”, agil zu sein bzw. agil zu arbeiten.

Agile Projekte haben den Ruf, öfter und besser zu funktionieren als klassische. Dennoch: Auch agile Projekte laufen manchmal aus dem Ruder. Woran liegt das? Aus unserer Erfahrung liegt es oft daran, dass im Requirements Engineering (RE) und der Planung etwas nicht passt. Ja, auch technische Herausforderungen können ein agiles Projekt ins Schlingern bringen. Gutes agiles RE und Planen sollte dieses Schlingern jedoch früh erkennen und abfangen und so Risiko und negativen Impact minimieren.

Das geschieht oft nicht. Häufig planen „Agilisten“ nur auf Sicht, hangeln sich von Sprint zu Sprint im Wochenrhythmus vorwärts, sehen nur Bäume und verlieren den Wald aus den Augen. Die Folge ist, dass der intelligente Plan für das große Ganze fehlt. Natürlich ist das ein Missverständnis des agilen Ansatzes, à la „Mit dem Barcamp Agile werden“. Nichts könnte von der Wahrheit weiter entfernt sein – agiles Vorgehen heißt, dass man mehr plant, nicht weniger.

Aber fangen wir mit den weniger komplexen Problemen (Irrtümern) an. Nämlich wie im agilen Projekt sog. Requirements verstanden werden.

In unserem aktuellen Leitartikel der vorliegenden Ausgaben versuchen wir fünf Irrtümer über agiles Requirements Engineering als zentrales Element im agilen Projektmanagement zu identifizieren und zu beleuchten.

Die

Möglichkeiten

im Web sind nahezu

grenzenlos.

Darüber hinaus gibt´s wieder jede Menge spannenden Lesestoff rund um E-Commerce und Online-Marketing. So haben wir unter anderem einen Artikel mit dem Titel “Der beste Verkäufer im stationären Handel ist das Web” im Angebot und werfen einen detaillierten Blick auf ein Content Audit, mit dem Web-Inhalte analysiert, verbessert und strategisch ausgebaut werden können.

Abgerundet wird die aktuelle Ausgabe erneut wieder mit einigen spannenden Web- und Buchtipps – eine ideale Lektüre für die jetzt immer länger werdenden Herbstabende.

In diesem Sinne wünsche ich Ihnen einen spannenden Herbst mit möglichst viel Zeit und Ruhe zum Lesen unseres Magazins. Viel Spaß dabei!

Ihr Josef Willkommer Chefredakteur 3

Inhalt: 03/2018

11

fotolia.com/warmworld © fotogestoeber / Fotolia alphaspirit © 123RF.com

Fünf Irrtümer über Agiles Requirements Engineering Agile Projekte haben den Ruf, öfter und besser zu funktionieren als klassische. Dennoch: Auch agile Projekte laufen manchmal aus dem Ruder. Woran liegt das? Fünf Thesen, die zu Problemen (Irrtümer) führen können, werden in diesem Artikel besprochen.

3 Editorial 6

Surftipps & Blogs

8 Buchempfehlungen

LEITARTIKEL

11 Fünf Irrtümer über Agiles

Requirements Engineering

E-COMMERCE 18 Agiles ITSM – klassische

Methoden auf dem Abstellgleis?

18

Agiles ITSM – klassische Methoden auf dem Abstellgleis?

sdecoret/Shutterstock

NEWS

Die Welle der Agilität hat auch das IT-Service-Management (ITSM) ergriffen. Schon lange haben agile Prozesse auch das IT-Service-Management (ITSM) erreicht. Können die traditionellen ITSM-Methoden da überhaupt noch mithalten?

22 Ist NewStore der “Dritte

Streich” von Stephan Schambach?

28

Warum Payment ein wichtiges Bindeglied für eine erfolgreiche Unified- Commerce-Strategie ist

34 Digitale Mitgift: Kundendaten

als Erfolgsfaktor bei Unter nehmensübernahmen 39 5 Fehler, die man im

E-Commerce vermeiden sollte 43 Content Audit – Inhalte

analysieren und die richtigen

Schlüsse ziehen

28

Constantin Stanciu/Shutterstock

Warum Payment ein wichtiges Bindeglied für eine erfolgreiche Unified-CommerceStrategie ist Erfahren Sie, welche Aspekte Kunden beim Shopping online und im Laden wichtig sind und wie Händler mit den folgenden Best Practices ihre Kundenbindung stärken können.

4

Inhalt: 03/2018

43

PROJEKT MANAGEMENT

Der Content Audit dient als Inventur vorhandener Inhalte und deren Bewertung anhand der gesetzten Ziele. Wie Sie von Content Audit profitieren und hieraus die richtigen Schlüsse ziehen, beschreibt Andreas Schülke Head of Content Marketing und Teamleiter SEO bei der OnlineMarketing-Agentur Bloofusion in seinem Gastartikel.

48 Mit dem Barcamp agil werden

Freedomz/Shutterstock adiruch © 123RF.com

Content Audit

48

REDPIXEL.PL/Shutterstock

Mit dem Barcamp agil werden In einer digitalen Welt sind Unternehmenskulturen gefragt, die innovativ, lernfähig und flexibel sind. Wie die Digitale Transformation und der Wandel in der Beziehung zwischen Unternehmen und Agenturen gelingen können, erfahren Sie in diesem Artikel.

ONLINE MARKETING 54

Kundenverständnis ist King – wie ein besseres Verständnis des Kunden das Tandem Händler – Kunde zu einem Erfolg macht

61 Generation Z – mobil,

bequem, anspruchsvoll und

schnell gelangweilt 66 Augen auf bei der Partner wahl: Warum Marketing-

Spezialagenturen im Vorteil sind

MAGAZIN 69 Impressum

61

Rawpixel.com/Shutterstock

Generation Z – mobil, bequem, anspruchsvoll und schnell gelangweilt Ein sehr großer Teil dieser jungen Verbraucher sucht nicht nur Spaß, sondern gleichzeitig auch Erfüllung und Sinn. Die Erwartungen dieser Generation sind hoch und wenn ein Ausbildungs- oder Arbeitsplatz nicht gefällt, sind sie schnell wieder weg.

5

News: Surftipps & Blogs

Surftipps & Blogs Blind - anonym über den Arbeitsplatz austauschen Sich über Gehalt oder über bestimmte Führungskräfte öffentlich zu beschweren, ist in der Regel nicht gern gesehen oder gar förderlich für die eigene Karriere. Anders als andere Social-Intranets können Sie sich mit der App “Blind” vollkommen anonym mit Kollegen oder mit Mitarbeitern der Konkurrenz über Ihren Arbeitsplatz austauschen. Eine Anmeldung ist nur über die beruflichen E-Mail-Adresse möglich. Sobald mindestens 30 Mitarbeiter einer Firma ein Blind-Konto haben, können Sie sich als Blind-Mitglied in einem geschützten Bereich über generelle Karrierethemen, Bezahlung oder andere arbeitsrelevante Themen austauschen. https://www.teamblind.com/

Social-Login-Schutz mit BrowserErweiterung für Google-Chrome Sich bei einer Website oder einer App mit dem bestehenden Nutzerkonto einer großen Plattform wie Google, Facebook oder Twitter anzumelden ist zeitsparender als eigene E-MailAdresse anzugeben, ein neues Passwort zu wählen, den Link in der Bestätigungs-Mail anzuklicken und wieder zur Ursprungsseite zurückzukehren. Um die Social-Login-Funktion gegen Missbrauch abzusichern, wird bei einem Social-Login ein Code an die App von dem soziale Netzwerk zur Bestätigung geschickt. Dieser wird von der Browser-Erweiterung jedoch gegen einen Ersatzcode getauscht, bevor er an die App weitergeleitet wird. So sehen Scripts auf anderen Websites nur den Ersatzcode.

Die Browser-Extension dient somit als Datenübermittler dazwischen. https://sites.google.com/site/wpseproject/

6

News: Surftipps & Blogs

Surftipps & Blogs Workona - bringt Ordnung ins Tab-Chaos Die Chrome-Erweiterung Workona hilft Ihnen dabei sich nicht in unzähligen geöffneten Tabs zu verlieren. Mit HIlfe sogenannter Workspaces können Sie zwischen TapSammlungen hin und her wechseln. Die Tabs der jeweils inaktiven Workspaces werden nicht angezeigt, bleiben jedoch aktiv. Sie können nach belieben Websites oder WebApps in einem Workspace zusammenfassen und dabei die URL aus einer Liste der offenen Tabs per Drag&-Drop auf den gewünschten Workspace schieben. Die Workspace lassen sich zur einfachen Identifikation benennen und mithilfe von Trennelementen gruppieren. Mit Workona haben Sie zudem die Möglichkeit Workspaces mit Kollegen zu teilen. https://workona.com/

TURNING ONLINE PROJECTS INTO SUCCESS Analyse. Konzeption. Design.

Webentwicklung. Online-Marketing.

Von der Analyse bis zur Webentwicklung – wir setzen Ihr Online-Business in Szene und sorgen für einen professionellen Webauftritt.

JETZT KONTAKT AUFNEHMEN

Tel.: + 49 8031 / 22 10 55 - 0 Fax: + 49 8031 / 22 10 55 - 22 info@techdivision.com www.techdivision.com

7

News: Buchempfehlungen

Buchtipps aus der eStrategy-Redaktion Managing for Happiness Übungen, Werkzeuge und Praktiken, um jedes Team zu motivieren Wie können wir die Kultur in unseren Organisationen verändern? Wie können wir unsere Mitarbeiter sinnvoller belohnen und auszeichnen?

Wie können wir Leistungsbeurteilungen ersetzen?

"Managing for Happiness" bietet praxisorientierte Werkzeuge, Spiele und Praktiken für jeden im Unternehmen an, um diese Fragen und viele mehr augenblicklich zu klären. Als Ergebnis steigern sich die Produktivität und Motivation im gesamten Unternehmen. Neudenker, Führungskräfte, Coaches, Wissensarbeiter oder Organisationsentwickler werden viel Freude an diesen 300 farbenfroh gestalteten Seiten haben, in denen der Autor auch eine Lanze für die Abschaffung von Hierarchien bricht.

Autor: Jurgen Appelo, Auflage / Erscheinung: Mai 2018, Umfang: 292 Seiten, Preis: 39,80 Euro, Verlag: Vahlen, ISBN: 978-3-8006-5418-5

Jetzt kaufen!

Tell me!

Wie Sie mit Storytelling überzeugen Das Buch „Tell me!“ verrät Ihnen, wie Sie im Beruf erfolgreich sind. Dabei setzt der Autor Thomas Pyczak auf die Kraft des Storytelling.

Egal ob online oder offline, der Autor beschreibt Techniken und Tools, mit denen Sie kurze und in sich geschlossene Geschichten erzählen, die Ihr Publikum fesseln. Lernen Sie damit, wie Sie Ihre Zuhörer begeistern und machen Sie sich mit den Methoden guten Storytellings vertraut. Zahlreiche „Best Practices“ für alle beruflichen Situationen, die inspirieren und im Gedächtnis bleiben. Ein hilfreiches Buch für alle, die lernen wollen, wie Geschichten im Gedächtnis bleiben und damit im Beruf zu überzeugen.

Autor: Thomas Pyczak, Auflage / Erscheinung: Mai 2017 Umfang: 277 Seiten, Preis: 24,90 Euro, Verlag: Rheinwerk, ISBN: 978-3-8362-4560-9

Jetzt kaufen!

8

News: Buchempfehlungen

Buchtipps aus der eStrategy-Redaktion Programmieren trainieren Mit über 100 Workouts fit in Java und Python Das Übungsbuch gleicht einem ausgefeilten, sich steigernden Programmier-Trainingsplan. Jedes Kapitel beginnt mit einem kurzen Warmup zum behandelten Programmierkonzept. Die Umsetzung wird dann anhand von zahlreichen Workout-Aufgaben eingeübt. So lernt man z.

B. einen PIN-Generator oder einen BMI-Rechner zu programmieren.

Kommt man einmal nicht mehr selbstständig voran, kann auf Lösungshinweise als Hilfestellung zurückgegriffen werden. Die Lösungen liegen kommentiert in den Programmiersprachen Java und Python vor.

Für angehende Programmierer ist das Buch daher ein ideales Training, um ihre Fähigkeiten zu steigern.

Autoren: Luigi Lo Iacono, Stephan Wiefling, Michael Schneider Auflage / Erscheinung: März 2018, Umfang: 576 Seiten, Preis: 23,99 Euro, Verlag: Hanser Verlag, (e-book) 978-3-4464-5503-0

Jetzt kaufen!

Google Data Studio Professionelle Berichte und Dashboards erstellen Datenvisualisierung leicht gemacht. Erfahren Sie, wie Sie Google Data Studio einsetzen, Dashboards konzipieren, Berichte und Datenquellen verwalten u. v. m.

Mit dem Buch von Sacha Kertzel und Sina Myllukus lernen Sie Google Data Studio so anzuwenden, dass auch fachfremde Mitarbeiter oder Kollegen die aufbereiteten Daten mühelos verstehen.

Erfahren Sie zudem, wie Sie Schritt für Schritt neben der nahtlosen Integration in Google Analytics, Google AdWords, Search Console oder Youtube weitere Datenbanken, Google-Tabellen oder Google Big Query anbinden und sogar für Business-Intelligence-Szenarien nutzen.

Autoren: Sascha Kertzel & Sina Mylluks, Auflage / Erscheinung: Juni 2018 Umfang: 391 Seiten, Preis: 39,90 Euro, Verlag: Rheinwerk, ISBN: 978-3-8362-6097-8

Jetzt kaufen!

9

REDPIXEL.PL/Shutterstock

Leitartikel: Fünf Irrtümer über Agiles Requirements Engineering

Fünf Irrtümer über Agiles Requirements Engineering von Sacha Storz, Agile Coach bei der TechDivision GmbH

In diesem Artikel werden wir fünf Thesen besprechen: Im agilen RE geht es nicht um Requirements. User Stories sind keine Anforderungs-Entität. Schätzen ist nicht wichtig. Im Agilen wird mehr geplant als im Klassischen. Der geplante Scope besteht keineswegs aus Features plus nicht-funktionalen Themen. Lassen Sie sich entführen in eine Planung, die iterativ und inkrementell nach Wert und Impact sucht, die Kollaboration und Kommunikation im Zentrum hat, und die stets eine klare (sich zuweilen ändernde!) Roadmap kennt.

11

Leitartikel: Fünf Irrtümer über Agiles Requirements Engineering

Agile Projekte haben den Ruf, öfter und besser zu funktionieren als klassische. Dennoch: Auch agile Projekte laufen manchmal aus dem Ruder. Woran liegt das? Aus unserer Erfahrung liegt es oft daran, dass im Requirements Engineering (RE) und der Planung etwas nicht passt. Ja, auch technische Herausforderungen können ein agiles Projekt ins Schlingern bringen. Gutes agiles RE und Planen sollte dieses Schlingern jedoch früh erkennen und abfangen und so Risiko und negativen Impact minimieren.

Das geschieht oft nicht. Oft planen „Agilisten“ nur auf Sicht, hangeln sich von Sprint zu Sprint im Wochenrhythmus vorwärts, sehen nur Bäume und verlieren den Wald aus den Augen. Die Folge ist, dass der intelligente Plan für das große Ganze fehlt. Natürlich ist das ein Missverständnis des agilen Ansatzes, à la „Wir sind jetzt agil, wir müssen nicht mehr planen“.

Nichts könnte von der Wahrheit weiter entfernt sein – agiles Vorgehen heißt, dass man mehr plant, nicht weniger. Aber fangen wir mit den weniger komplexen Problemen (Irrtümern) an. Nämlich wie im agilen Projekt sog. Requirements verstanden werden.

Im agilen Projekt gibt es (fast) keine Requirements Wie, was, warum? So ein Unsinn. Natürlich gibt es Requirements in unserem Projekt. Wir wissen, dass wir eine Online-Plattform für Wohnungsmakler bauen wollen. Man muss sich einloggen können, Bilder hochladen usw. usf.

Schauen wir genauer hin. Wenn man agiles RE ernst nimmt, dann macht man es nutzerzentriert und wertzentriert. Sie haben sicher schon von sog. „User Stories“ gehört, mit denen das RE im agilen Projekt oft gemacht wird. Eine User Story hat das Format „Als [Rolle] will ich [Funktion], damit [Wert]“. Also z. B. „Als Wohnungsmakler will ich mich auf der Plattform einloggen, um Bilder für Objekt 12345 hochzuladen“.

Ganz brav haben wir eine Rolle verwendet, nämlich unseren Nutzer, den Makler, und aufgeschrieben, was er tun will und warum er es tun will. Offensichtlich ist das Ganze ein Requirement.

dann wäre die Antwort „Naja, steht doch da, er will halt Bilder zu einem Objekt hochladen“. Jeff Patton, der Autor von „User Story Mapping“ (ein Must-Read für agile Projektmanager) beschreibt scherzhaft, dass er irgendwann verstanden hat „Requirement“ heißt „Shut up“. Nachfragen sind unerwünscht, weil offensichtlich sinnlos.

User Story – ganz einfach, oder?

Dabei ist das eine eher ziemlich schlechte User Story. In einer User Story geht es darum, wie immer im agilen RE, auszuloten, was eine bestimmte Rolle, etwa der Makler, Wertvolles erreichen will im Kontakt mit unserem Produkt – sei es Plattform, Software oder sonstiges. Kent Beck, der Erfinder der agilen Methode Extreme Programming und Vater der User Story hat genau deshalb den Benutzer in den Mittelpunkt gestellt und den Wert in den Vordergrund.

Die o.g. User Story „Als Wohnungsmakler will ich mich auf der Plattform einloggen, um Bilder für Objekt 12345 hochzuladen“ behauptet, dass sich jemand einloggen will – aber kein Mensch will sich einloggen. Und er will auch keine Bilder hochladen.

Das Requirement für ihn ist, seine Objekte möglichst gut auf dem Markt zu vermitteln. Wir gehen davon aus, dass Bilder dafür ein gutes Mittel sind (ich würde zustimmen), aber wir wissen es nicht. Wir reden nicht über ein Requirement, sondern über eine Hypothese: Wenn das Objekt mit Bildern ausgestattet ist, ist es besser vermittelbar. Wenn man das wirklich annimmt, muss man testen: Müssen es viele Bilder sein? Große Bilder? Stimmungsvolle oder eher nüchterne Bilder? Und so weiter.

Käme ich zum Projektleiter und fragte ihn „Erklär mir mehr, was will der Makler eigentlich erreichen?“,

12

Leitartikel: Fünf Irrtümer über Agiles Requirements Engineering

Was ein Requirement ist, bestimmt der Markt – und zwar hinterher!

Deshalb ist es im agilen Vorgehen, bei dem es um schrittweises Vorgehen in Richtung des idealen Ergebnisses geht, nicht sinnvoll, von Requirements zu sprechen. Mit Ausnahme von Rahmenbedingungen, die fix sind, auf die wir keinen Einfluss haben, etwa gesetzliche Vorgaben oder Technologieentscheidungen, die unumstößlich sind. Was aber ansonsten Requirements sind, wissen wir erst, wenn wir den Erfolg unserer Ergebnisse im Projekt testen. Wenn Sie etwas produzieren, was dann kein Mensch benutzt, war es offensichtlich kein Requirement. Deshalb kann es beim iterativen, inkrementellen Vorgehen eigentlich kaum ein Requirement geben. Wüssten wir sicher, dass es ein Requirement ist, bräuchten wir nicht agil vorzugehen.

Ok, wollen wir nicht wortklauberisch sein. Letztlich ist es egal, wie wir die Dinge nennen, wenn wir uns einig sind. Nennen wir es Requirement. Aber machen wir uns bewusst: Die Illusion, dass wir wissen, was genau das Ergebnis des Projekts sein soll, en detail und mit Sicherheit, ist gefährlich. Sie verstellt unseren Blick darauf, was eigentlich Wert hat und welche Hypothesen wir schrittweise testen sollten, um nicht Zeit, Geld und Energie zu verschwenden.

Und wie lange dauerts jetzt?

Und wie viel kostets?

Es gibt kaum zwei Fragen, die einen Produzenten oder Dienstleister mehr drücken, und es gibt kaum einen Auftraggeber, für den sie nicht von höchster Brisanz wären. Selten hat man einen Kunden, der sagt: „Mir egal, wie viel Geld Sie verbraten, und wann es fertig ist, ist auch nicht so wichtig.“ Um diesem Problem zu begegnen, wird in klassischen Projekten meist mit Festpreis und scheinbar klarer Spezifikation gearbeitet. Im agilen Vorgehen wird geschätzt. Vielleicht kennen Sie die sog. „Story Points“. Eine User Story wird in Story Points geschätzt, daher der Name. Story Points sind ein elasti-

sches Maß, das Aufgaben grob in Größenordnungen einteilt. Man verwendet meist die Skala 1, 2, 3, 5, 8, 13, 20, 40, 100 und schätzt vergleichend, also: Wenn diese Aufgabe eine 3 ist, dann ist jene mindestens eine 8. Nicht wenig agile Teams schätzten auch einfach nur in T-Shirt-Größen, also Small, Medium, Large, X-Large. Manche schätzen sogar in Zeit, wobei das sehr kritisch zu sehen ist. Zeitschätzungen suggerieren eine Exaktheit und Belastbarkeit, die bei Schätzungen grundsätzlich nicht gegeben ist.

Warum überhaupt schätzen?

Der Wert von Schätzungen liegt darin, dass sie das Abarbeiten von Aufgaben planbar und finanziell bezifferbar machen. Und wenn das ginge, wäre es eine super Sache. Es geht aber nicht. Schätzungen sind immer nur grob. Wenn Ihnen jemand sagt „Diese Aufgabe zu bearbeiten wird 16 Stunden brauchen“ dann lügt er in den meisten Fällen. Bewusst oder dazu politisch gezwungen. Gutes Schätzen ist wahnsinnig schwierig, wie die meisten Statistiken bzw.

Projektverläufe leider zeigen. Deshalb wäre es die Überlegung wert, das Schätzen einfach bleiben zu lassen, denn es ist schwierig und bringt nicht viel.

Wann ist Schätzen nötig?

Wenn Sie sich sicher wären, dass ich das Bestmögliche mit Ihrem Geld mache und wir uns alle zwei Wochen verabreden, um die Fortschritte zu begutachten… Bräuchten Sie dann Schätzungen auf Ebene einzelner Aufgaben? Ich denke nein. Moment, aber Sie müssten dennoch eine Aussage von mir bekommen, ob wir insgesamt über die nächsten 8 Monate das Ganze gewuppt kriegen. Also mit 10-KilometerFlughöhe betrachtet, ohne Details, so das Große und Ganze: Kriegen wir das hin? Auch dafür brauchen Sie keine Schätzung, sondern nur ein Ja oder Nein.

Voraussetzung für den inhärenten Vertrauensvorschuss, sind drei Dinge: • Sie glauben mir, dass ich nur und stets das Beste für Sie tue. Vertrauen ist wichtig; ohne Vertrauen ist agile Zusammenarbeit gar nicht möglich.

13

Leitartikel: Fünf Irrtümer über Agiles Requirements Engineering

• Sie wissen, dass ich die inhaltliche und planeri- sche Expertise habe (i.e. Erfahrung), um über- haupt ein Ja oder Nein antworten zu können.

• Wir gehen in kleinen Schritten voran, damit Sie aussteigen können, wenn Punkt 1 oder 2 sich als Flop erweisen.

Schätzen müssen wir jetzt nur noch, um auszuloten, ob wir vom vermuteten Business Value her das kleinstmögliche Experiment zum Thema X wagen sollen. Ein Beispiel: Joshua Kerievsky (Begründer von Modern Agile) versprach sich etwas von einem Live-Chat-Feature, mit dem sich die Besucher seiner Lernplattform austauschen könnten. Natürlich wusste er nicht, wie viel das Feature wirklich bringen würde. Er ließ einen Button auf die Plattform machen „Jetzt mit anderen Besuchern chatten“.

Der Button tat nichts, außer eine Meldung anzuzeigen: „Dieses Feature steht in Kürze zur Verfügung – wie wahrscheinlich werden Sie es nutzen?“ Nur 6% der Besucher klickten den Button und von denen hielt es die Mehrheit für nicht höchstwahrscheinlich, dass sie das Feature nutzen würden. Also entschied er, die Idee fallenzulassen. Der Chat war wohl kein „Requirement“ – kaum ein Mensch wollte ihn haben.

Die Schätzung, wie viel es kosten würde, diesen Chat zu bauen, ist unnötig. Wir müssen nur wissen, wie viel es kostet, den Button und ein Tracking einzubauen – fast nichts. Dann müssen wir entscheiden, ob der vermutete Business Value dafür steht, dass wir dieses kleine Geld ausgeben.

Schätzen ist nicht wichtig für Planung, sondern für Entscheidung Deshalb ist Schätzen nicht wichtig. Es ist ein Hilfsmittel, um zu entscheiden, ob man etwas ausprobieren will, eine Hypothese testen, wie die mit dem OnlineChat. Es ist kein Instrument, das uns zur Aussage führen soll: „In x Monaten bekommst Du y Stories

zum Preis von z Euro.“ Diese Aussage kann man mit Erfahrung und gesunder Statistik vielleicht machen.

Für dieselbe Aussage reicht es aber, Aufgaben zu zählen, statt ihren Umfang zu schätzen, die Vorhersagegüte ist mindestens gleich gut, oft sogar besser.

Glauben Sie nicht? Schauen Sie sich das Zahlenmaterial in unserem Whitepaper zu Schätzgüte an.

Besprechen Sie also die Aufgaben im Team, damit alle ein gemeinsames Verständnis entwickeln und Input und Kritik liefern können. Aber vergessen Sie das Schätzen. Betrachten wir die Kanban-Community: Kanban schätzt gar nicht. Weil kontinuierlicher Arbeitsfluss und gelungene Entscheidung „Was wollen wir als nächstes“ wichtiger sind, als die Größe der Aufgaben.

Das alles klingt vielleicht merkwürdig. Doch denken Sie daran: Agiles Projektvorgehen ist ein grundsätzlich anderes Vorgehen als klassisches. Es ist nicht dasselbe in grün, es ist etwas wirklich anderes, auch wenn viele das nicht so leben.

Und das Ganze funktioniert nur gut, wenn wir das Projekt nach den Regeln der Kunst agil durchführen, und damit sind wir beim letzten Mythos, den dieser Text angreifen will: Der geplante Scope besteht nicht aus Features und Nicht-funktionalen-Anforderungen.

Er besteht aus Impact-Hypothesen. Deshalb müssen wir anders planen.

Wie ein agiles Projekt planen?

Ein klassisches Projekt ist plangetrieben, ein agiles Projekt ist wertgetrieben. Wie aber beurteilen wir den Wert? Denn wir kennen ihn ja nur ungefähr bzw. vermuten ihn, sonst wäre jede Produktentwicklung ein Welterfolg, jedes Feature ein Killer-Feature, jedes Projektergebnis der reine Wahnsinn. Wenn wir den Scope eines agilen Projekts in Features und anderen Anforderungen betrachten, sitzen wir einem Irrtum auf: Dem Irrtum, dass wir die Zukunft kennen können.

14

Hier endet die Leseprobe der Ausgabe 04/2017

Jetzt vollständiges Magazin kostenlos downloaden unter www.estrategy-magazin.de!