Wie wir uns die Zusammenarbeit mit unseren Kunden vorstellen - Teil 1
Wir machen bei der Hardware-Entwicklung SCRUM, weil wir glauben, dass wir so unseren Kunden und den Endanwendern (Usern) schneller genau das liefern, was sie wirklich haben wollen. In diesem Satz sind zwei Aspekte enthalten, die wichtig sind:
- schnell
- was Endanwender wirklich haben wollen
Um das hinzukriegen, reicht es nicht aus, dass wir alleine unsere Arbeitsweise ändern. Auch ihr, unsere Kunden, müsst anders mit uns zusammen arbeiten als bisher. SCRUM erfordert auch eine Umstellung der Beziehung und Zusammenarbeit zwischen uns.
Wie diese neue, für SCRUM optimale Form der Zusammenarbeit aussehen sollte, darüber haben beispielsweise Boris Gloger, Andreas Opelt, Wolfgang Pfarl und Ralf Mittermayr in ihrem Buch Der agile Festpreis nachgedacht. Sie beschreiben dort u.a. wie Verträge aussehen sollten, um die Besonderheiten eines SCRUM-Projekts einzufangen. Ihr Fokus liegt auf Software1. Wir machen hier Hardware, was einiges ändert. Wie genau sollten unsere Kunden uns beim Entwickeln von wirklich user-zentrierter Hardware unterstützen?
Im Vordergrund steht das Ausliefern von Ergebnissen
Wir wollen am Ende jeden Sprints etwas an euch, unsere Kunden, liefern, das testbar und funktionsfähig ist. Dafür erwarten wir von euch, dass ihr am Sprint Review teilnehmt, wo wir das Sprintergebnis vorstellen, und uns so schnell wie möglich Feedback zukommen lasst, idealerweise von euren Endanwendern. Ihr solltet die gelieferten Sprint-Resultate auch so schnell wie möglich in deren künftiger Betriebsumgebung testen und uns mitteilen, was ihr dabei lernen konntet.
Lasst uns Änderungen begrüßen
Aber als Kunden müsst ihr wissen, dass Änderungen an der gewünschten Funktionalität leichter umzusetzen sind als Änderungen an den vor Projektbeginn vereinbarten Rahmenbedinungen. Wir wollen so entwickeln, dass wir in der Lage sind, schnell auf Änderungen reagieren zu können. Am besten ist, dass wir während des Projekts transparent miteinander umgehen und ihr, liebe Kunden, so oft wie möglich bei einigen unserer regelmässigen Meetings dabei seid: z.B. Daily SCRUM, Sprint Planning I und auf jeden Fall dem Sprint Review.
Änderungen fallen auch unter den von Gloger et al. geprägten Begriff EXCHANGE FOR FREE. Bei SCRUM haben wir alle Funktionalitäten eines Hardware-Entwicklungsprojekts in ihrer Komplexität geschätzt und geben für dieses Paket an Funktionalitäten ein Angebot ab. Sollten euch nach Beauftragung weitere Funktionalitäten einfallen, die aus eurer Sicht unbedingt ins Projekt müssen, dann schätzen wir auch diese ein. Dann gibt es zwei Möglichkeiten:
- wir machen Exchange for free, indem ihr alte, nun nicht mehr benötigte Funktionalitäten mit dem entsprechenden Schätzwert streicht, bevor wir die neuen Funktionalitäten in den Vertrag aufnehmen
- ihr wollt nichts streichen, dann sind die neu hinzugekommenen Funktionalitäten eine Erweiterung, deren Aufwand zusätzlich bezahlt werden muss. Dabei verlängert sich auch die Projektdauer.
Wir wollen mit euren Endanwendern reden
Wir brauchen Zugang zu Fachexperten und Endanwendern, um schnell herauszufinden, ob wir in der gewünschten Richtung unterwegs sind. Entscheidend ist dabei die Aussage der Endanwender, die das Produkt anwenden sollen - und nicht beispielsweise der Abteilungsleiter, in deren Abteilung das Produkt angesiedelt ist. Die Wahrheit über das zu lösende Problem der Endanwender und mögliche Lösungen dafür kennen nur die Endanwender. Deswegen brauchen wir idealerweise Endanwender zum Testen. Aber auch für Rückfragen anderer Art sollte bei euch im Hause immer jemand verfügbar sein. Wir können nur agil entwickeln, wenn wir unsere Fragen schnell beantwortet kriegen.
Vertraut uns (erstmal)
Agil entwickeln heisst auch immer ein bisschen experimentieren. Wir wissen nicht, wie die optimale Lösung für das Problem eurer Endanwender aussieht, also müssen wir iterieren: wir entwickeln was und testen es mit Endanwendern. Wir beobachten sie und reden mit ihnen, wie es lief. Daraus lernen wir, was gut war und was nicht so sehr. Dann verstärken wir das, was gut lief und lassen das sein, was schlecht lief.
Dafür brauchen wir Vertrauen. Denn Iteration ist keine gerade, kürzeste Linie vom Ausgangspunkt zum Ziel. Iteration solltet ihr euch besser als viele kleine Schleifen vorstellen - und Experimentieren erfordert etwas Zeit und Mut. Nur so finden wir aber nicht nur lokale Maxima in der Endanwender-Zufriedenheit, sondern globale. Lasst uns also mindestens drei Sprints Zeit, um uns und unsere Ergebnisse zu beurteilen.
Von Angesicht zu Angesicht
In unserem Hardware-Entwicklungsprojekt, das wir für euch durchziehen, werden wir viel miteinander zu bereden haben. Unsere Erfahrung dabei ist, am besten redet es sich miteinander von Angesicht zu Angesicht. Dazu sollten wir idealerweise im selben Raum sein. Dokumente, auf die ihr am Ende nicht verzichten könnt, sind das Ergebnis unseres im Projekt gelungenen Miteinander-Redens (und natürlich einiger individueller Arbeitsphasen). Dokumente sollten nie unser Haupt-Kommunikationsweg sein.
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
- Immer dran denken: Software ist soft, Hardware ist hard. ↩︎