Das Dokument thematisiert die Herausforderungen und Ansätze agiler Softwareentwicklung im E-Commerce, betont die Notwendigkeit klar definierter Projektziele und die Bedeutung der Zusammenarbeit zwischen Kunden und Dienstleistern. Es beschreibt Best Practices für die Erstellung von Projektanforderungen und erläutert, wie durch iterative Entwicklungsansätze und regelmäßige Reviews der Nutzen maximiert und Kosten kontrolliert werden können. Abschließend werden verschiedene Vertragsoptionen und deren Vor- und Nachteile in einem agilen Kontext diskutiert.

1. @BjoernSchotte | bjoern.schotte@mayflower.de | 0931 / 35 96 5 - 15
Bessere Software schneller
liefern.
Webinar - 14. Mai 2013

2. MAYFLOWER
Leidenschaft für
erfolgreiche
Softwareprojekte.
Zu Ihrem Nutzen.

3. Agilität im E-Commerce I Mayflower GmbH I Nov 19, 2012 I
Alte Welt der Software-Entwicklung

4. Langwieriges
Pflichtenheft
oder
Visionsdokumente

5. Lange
Entwicklungszeiten
(viele Monate, Jahre)

6. Umständliche
Umsetzung
Business-
Anforderungen
in der Plattform

7. CHAOS REPORT 2011
klassisch Wasserfall
14%
57%
29%
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2011

8. Kaum genutzte Funktionen in Software
Never Used
45%
Rarely
19%
Sometimes
16%
Often
13%
Always
7%

9. Agilität im E-Commerce I Mayflower GmbH I Nov 19, 2012 I

10. Passt nicht mehr zur
heutigen Zeit

11. Go Agile
or Die

12. Agile Methoden
(Scrum, XP) haben
den Mainstream
erreicht.

13. Agile Methoden
erzeugen
Herausforderungen auf
Kunden- wie auf
Dienstleisterseite.

14. Fragestellungen für Kunden

15. Lieber Kunde,
kennen Sie Ihre
Produkt-/Projektvision?

16. Lieber Kunde,
haben Sie Vollzeit Zeit
für das Projekt?

17. Lieber Kunde,
haben Sie Zeit, sich mit
Ihren internen
Stakeholdern
abzustimmen?

18. Lieber Kunde,
wissen Sie, was Sie mit
dem Projekt überhaupt
erreichen wollen?

19. Lieber Kunde,
konnten Sie schon erste
Anforderungen
definieren?

20. Lieber Kunde,
was ist wichtiger?
Budgettreue oder fixer
Funktionsumfang oder
Einhaltung des
Zeitrahmens?

21. Fragestellungen für
Dienstleister

22. Lieber Dienstleister,
sind die Team Mitglieder
dem Projekt Vollzeit
zugeordnet?

23. Lieber Dienstleister,
besteht das Team aus
mehr als 1 bis 2
Personen?

24. Lieber Dienstleister,
ist das Team cross-
funktional aufgestellt?

25. Lieber Dienstleister,
stellst du einen Product
Owner (Assistant)?

26. Lieber Dienstleister,
ist ein sauberer Vertrag
aufgesetzt, der agiles
Arbeiten ermöglicht und
fördert?

27. Lieber Dienstleister,
wurde der Vertrag mit
dem Kunden
durchgesprochen und
beidseitig verstanden?

28. Lieber Dienstleister,
wie ermöglichst du
Gewerke in deinem
Projekt?
Macht das überhaupt
Sinn?

29. Vertrauen zwischen
Kunde & Dienstleister.

30. Best Practices
Softwareprojekt

31. Konzeption

32. Wir erinnern uns:
Lieber Kunde,
kennen Sie Ihre
Produkt-/Projektvision?

33. Für Hobby-Handwerker
die in Eigenregie ihr Haus modernisieren
ist EsIstDeinProjekt.de ein Online-Shop
der den einfachen Einkauf von
Handwerksmaterialien ermöglicht.
Anders als OBI/HORNBACH/PRAKTIKER
bietet unser Online-Shop
- den bequemen Einkauf per Tablet
- die Online-Konfiguration von Fenstern
- die größte Auswahl an Bohrern
- eine 100 Tage Geld-zurück-Garantie

34. Personas.
Beschreiben Sie Ihre Nutzergruppen. So
ausführlich wie nötig. So schlank wie möglich.
Name + Bild.
Was sind die für das Projekt relevanten
Charakteristiken der Persona? Zum Beispiel Job,
Alter, Position bei sich im Unternehmen.
Bedarf. Welchen Bedarf stillt diese Person auf Ihrer
Fachanwendung?
http://www.romanpichler.com/blog/agile-product-innovation/persona-template-for-agile-product-
management/

35. Product Canvas.
Ähnlich Business Canvas. Beschreibt auf einen
Blick die wichtigsten Personas, Customer Journeys,
EPICs, Constraints (zB Performance der
Anwendung) und Ready Stories.
http://www.romanpichler.com/blog/agile-product-innovation/persona-template-for-agile-product-
management/ (Product Canvas (C) by Roman Pichler, licensed CC-BY-SA)

36. Definition von
Anforderungen

37. Keine große
Einmalplanung.

38. Grobe Einmalplanung
& kontinuierliche
Planung im Projekt

39. (Einmal)planung:
Themen, Epics, Stories

40. Händler-Backend Produktverwaltung Produkt anlegen
Produkt ändern
Produkt löschen
Produkte
importieren
Produkttext
übersetzen
Fakturierung
Meinen Umsatz
anzeigen
Profildaten
Mein Logo
anlegen
Mein Logo ändern
Meine Adresse
anlegen
Meine Adresse
löschen
Thema EPIC Stories

41. - Produktname, Kategorie, Preis und Text können gepflegt werden
- das Produkt kann aktiviert und deaktiviert werden
- ein deaktiviertes Produkt ist im Shop-Frontend nicht sichtbar
Nutzergeschichte:
Akzeptanzkriterien:
Als Händler möchte ich ein Produkt anlegen,
um es im Shop EsIstDeinProjekt anzeigbar zu
machen

42. Der Dienstleister
unterstützt beim
Schreiben der
Nutzergeschichten.

43. Projektvergabe
Geschichten aus dem
Projektalltag

44. „Tragen Sie mal in das
Excel-Dokument die
Aufwände der einzelnen
Positionen ein.“
(Lies: „Ich will die Einzelaufwände vergleichen
und suche mir den Dienstleister mit dem
günstigsten Preis. Ich habe noch nicht verstanden,
worauf es eigentlich ankommt.“)

45. „Wir behalten uns vor,
einzelne Bestandteile an
andere Auftragnehmer
zu vergeben.“
(Lies: „Wir glauben, dadurch Risikostreuung zu
betreiben. Wir sind uns nicht bewusst, dass das die
Komplexität im Projekt erhöht, Vertrauen minimiert
und häufig nicht funktioniert.“)

46. „Jetzt sagen Sie doch: was
kostet‘s und garantieren Sie, dass
es bis zum <UTOPIEDATUM>
fertig wird?“
(Lies: „Wir haben mit dem 3-seitigen
Konzeptdokument ein halbes Jahr lang
verdaddelt. Der Dienstleister soll es bitteschön bis
zum Messetermin in vier Wochen richten. Der, der
das Konzept begonnen hatte, ist übrigens nicht
mehr bei uns beschäftigt.“)

47. „Wir wollen unbedingt
Gewährleistung auf das Projekt.
Das muss definitiv sein.“
(Lies: „Wir haben zwar nicht definiert was wir
wollen, und daher gehen wir [scheinbar] auf
Nummer sicher und wälzen das Risiko komplett
auf dich ab. Wir haben noch nicht verstanden,
dass es doch darum geht, möglichst schnell
Nutzen zum kleinen Preis zu realisieren. Und dass
Software per se nie fehlerfrei sein kann.“)

48. Tipps für die
Projektvergabe

49. Folgen Sie Ihrem Herzen. Wählen Sie einen
Dienstleister besonders nach diesen Kriterien.
Kompetenz. Vertrauen. Der Sie führt & geleitet.
Der sagt, was nicht passt. Die Zeitlinie
möglicherweise nicht zu halten ist. Darauf achtet,
wichtige & Funktionen, die Nutzen stiften, zuerst
zu implementieren. Sie und Ihre Kunden im Blick
hat. Auch mal NEIN sagt. Den Sie als Partner
betrachten. Der Sie auf Augenhöhe betrachtet.
Gemeinsam. Erfolgreich.

50. Anforderungsworkshop
mit einem Dienstleister.
Definition erster EPICs &
Stories.
Ergebnis: erste
Annäherung an das WAS.

51. Descoping von: unwichtigen Funktionen,
Anforderungen die jetzt noch nicht
wichtig sind. Ganz unten rein ins
Backlog.
Priorisierung der Anforderungen.
Definition eines „Walking Skeleton“ für
einen Überblick, der schärft.
Ergebnis: Reihenfolge der wichtig(st)en
Anforderungen. Klarheit für den
Projektstart.

52. Aufwandsschätzung eines
Beispiel-EPICs mit seinen User
Stories. Näherungsweise
Extrapolation auf die anderen,
noch nicht definierten EPICs.
Ergebnis: Korridor für mögliche
Aufwände und damit auch ein
Budgethorizont.

53. Vertragsgestaltung

54. Disclaimer:
I Am Not A Lawyer.
Dies ist keine
Rechtsberatung.

55. Dienstleistungsvertrag
vs
Werkvertrag
vs
Agil mit Festpreis

56. Ist ein Dienstleistungsvertrag in solchen Projekten
überhaupt sinnig?
Ja. Wenn die Kosten nach oben gedeckelt sind
(Projektdauer x Teamkapazität x Teamkosten/
Sprint). Natürlich sind dann die Features variabel.
Projekt“kontrolle“? Sprint-Rhythmus. Scope-
Änderung nach jedem Sprint möglich.
Nutzwertgenerierung.
Und: Projektabbruch möglich. Wie? Das zeige ich
später.

57. Ist ein Werkvertrag in solchen Projekten überhaupt
möglich?
Ja. Das Gewerk ist nicht das Gesamtprojekt, denn
das kennen Kunde & Dienstleister zu Projektbeginn
nicht vollständig.
Ein Gewerk kann vielmehr eine einzelne User
Story sein. Auf dieser Basis ist dann eine
Realisierung nach Werkvertrag, zB agil mit
Festpreis, möglich.

58. Tipps für die Vertragsverhandlung:
Anwalt involvieren. Vertragsgrundlagen auf Basis
gegenseitigen Vertrauens schaffen. Den Vertrag so
einfach wie möglich, so kompliziert wie nötig
gestalten.
Herausforderung: Entkopplung von Legal und
Einkauf-Abteilungen zur operativen Ebene und
damit Verständnis über die Projektziele. Alle an
einen Tisch bringen.

59. Projektverlauf

60. Sprint: regelmäßiger Rhythmus.
Jede 14 Tage Planung. Jede 14 Tage
Review. Was haben wir geschafft? Wo
gab es Schwierigkeiten? Was muss in
den nächsten Sprint noch mal rein?
Ziel: Nutzen generieren.
Fehleranfälligkeit durch kurze Rhythmen
minimieren. Möglichkeiten zur
Kursänderung schaffen. Einen weiteren
Teil des Großen Ganzen fertig stellen.

61. Kostenkontrolle: weg von der Frage „Was kostet
mich das Gesamte?“ (kann vorher nicht exakt
beziffert werden)
Hin zu: „wieviel vom Gesamtbudget habe ich
noch und was könnte ich mit diesem Rest noch an
Funktionen erreichen?“
Herausforderung: zu Beginn dieses Projekts ist die
Frage schwer zu beantworten. Nach jedem Sprint
schärft sich jedoch der Blick.
Wichtig: Stakeholder und Projekt-Sponsoren
kontinuierlich über den Verlauf des Projekts
informieren.

62. Abbruchszenarien. Sie brechen das Projekt
nicht aus Mangel an Vertrauen ab. Sie
brechen das Projekt gemeinsam dann ab,
wenn genügend Business Value geliefert
wurde.
Beispielprojekt:
Projektvolumen nach erster Schätzung
600kEUR.
Ein Sprint von 14 Tagen Dauer kostet etwa
30kEUR.

63. Variante 1: fixer Werkvertrag & Upfront
Design.
Dienstleister wird auf Erfüllung und Realisierung der 600kEUR
bestehen, obwohl nach 10 Sprints (=300kEUR) schon alles
realisiert wurde, was Ihnen Nutzen bringt. Denn während der
Projektlaufzeit haben sich Anforderungen, die ursprünglich geplant
gewesen sind, als nicht mehr sinnvoll erwiesen.
Die verbleibenden 300kEUR müssen in Funktionen realisiert
werden, die nicht viel weiteren Nutzen für Sie und Ihr Business
bringen.
Weiteres Geld muss über Change Requests investiert werden, um
den veränderten Anforderungen des Business gerecht zu werden.
Gesamtkosten steigen erheblich, der Gesamtnutzen sinkt.

64. Variante 2:
Nach 9 Sprints (=270kEUR) beendet man
das Projekt mit einem Sprint (=30kEUR)
Vorlauf. Weil alles realisiert wurde, was
Nutzen bringt. Gesamtkosten 300kEUR statt
geplanter 600kEUR.

65. Variante 3:
Nach 10 Sprints (=300kEUR) stellt man fest, dass das Business
noch weitere Anforderungen hat. Diese werden nach Nutz-Wert
priorisiert und noch 3 weitere Sprints (=90kEUR) nachgeschoben.
Danach wird das Projekt beendet, da alle wichtigen Anforderungen
erfüllt sind.
Gesamtkosten: 390kEUR. Der Gesamtnutzen ist deutlich höher,
weil viel effektiver darauf geachtet wurde, Nutzen zu generieren.
Der Wert ist bei kleinerer Geldmenge deutlich höher als das, was
durch komplettes Upfront-Design realisiert werden konnte. Auch,
weil sich die Anforderungen Ihres Marktes während der
Projektlaufzeit verändert haben und nur das realisiert wurde, was
wichtig ist.

66. Wie können Sie weiteren
zusätzlichen Nutzen im
Projekt generieren?

67. Kaum genutzte Funktionen in Software
Never Used
45%
Rarely
19%
Sometimes
16%
Often
13%
Always
7%

68. Releasen Sie neue Versionen frühzeitig.
Messen Sie direkt in der Software, wie Ihre
Kunden die Software nutzen.
Ziel: möglichst günstig & schnell neue Funktionen
releasen, Akzeptanz messen und Verhalten
validieren. Funktionen, die keinen Wert für Sie &
Ihre Kunden bringen, wieder wegwerfen.
Ergebnis: auf Nutzwert fokussierte Funktionen in
der Software. Hebelwirkung durch massive
Wertsteigerung. Damit zufriedenere Kunden - und
letztlich mehr Revenue für Sie.

69. Zusammenfassung
&
wie geht es weiter?

70. Und jetzt?
Fragen & Antworten.