Wie wir uns die Zusammenarbeit mit unseren Kunden vorstellen - Teil 2
Dies ist der zweite Teil einer Mini-Blogpost-Serie darüber, wie unser SCRUM für Hardware-Entwicklung die Zusammenarbeit mit unseren Kunden verändert. Teil 1 erschien vor einiger Zeit.
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. 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?
Nachhaltige Geschwindigkeit
Unser Team legt selber fest, wie viel Funktionalität sie in einem Sprint schaffen wollen. Damit sie ihre Zusagen auch halten, sollten wir sie von außen während eines Sprints nicht stören. Mitten im Sprint neue Funktionalitäten ins Team drücken und Endtermine vorziehen usw. führt nur zu Überstunden und Frust und letztendlich zu Entwicklern, die irgendwann keine Lust auf ihre Projekte haben.
Stimmen wir überein, dass Hardware-Entwicklung eine ziemlich komplexe Arbeit ist, bei der Kreativität gefragt ist? Dann spielt Motivation und ungestörtes Arbeiten eine große Rolle für die zu erwartende Qualität der Arbeit. Am besten ist es also, wir lassen die Entwickler entwickeln, was im Sprint vorher gemeinsam festgelegt wurde - und ändern das alles nicht mittendrin.
Qualität beginnt im Geiste
Wir haben unseren Fokus auf technischer Exzellenz und gutem Design, denn das fördert unsere Agilität beim Entwickeln. Ihr als Kunden erwartet von uns diese hohe technische Qualität in unseren Hardware-Designs, in unserer Software für eure Hardware und in unserer Dokumentation. Nun, dann ist wohl klar, dass es hohe technische Qualität nicht für Dumping-Preise gibt. Deswegen solltet ihr uns als euren Dienstleister für agile Hardware-Entwicklung nicht nur wegen unseres Preises auswählen, oder?
Keep it simple, stupid (KISS)
Wir sind auf der Suche nach der einfachsten Lösung, die wir professionell finden können und die unserem Anspruch nach technischer Exzellenz und gutem Design genügt. Wir wollen kurze Projektlaufzeiten und deswegen schnell liefern.
Ihr als Kunden müsst dafür schauen, dass ihr immer noch jede Funktionalität haben wollt, die ihr anfangs beauftragt habt. Sowas kann sich ja ändern. Was sich ganz oft ändert, ist die Priorisierung der Funktionalitäten: welche Funktionalität ist euch und euren Usern am wichtigsten? Die sollten wir auch als erstes liefern. Deswegen solltet ihr die Funktionalitäten immer wieder prüfen und ggf. neu sortieren.
Wenn wir alles geliefert haben an Funktionalität, was euch derzeit wichtig ist, sollten wir beide in der Lage sein, das Projekt kurzfristig zu beenden. Und von Anfang an sollten unsere Verträge das auch so ermöglichen. Das erfordert eventuell gewisse Änderungen in den Verträgen, die normalerweise in unserer Branche verwendet werden.
Selbstorganisation hilft am besten
Wir glauben daran, dass selbstorganisierte Teams am besten in der Lage sind, mit Komplexitäten umzugehen. Glaubt mir, Hardware-Entwicklung ist sehr komplex. Lassen wir das Team sich selber organisieren, so kriegen wir am Ende einfach bessere Ergebnisse.
Dafür dürft ihr keine Lösungen definieren, sondern nur die Anforderungen an die Lösungen. Und dann lasst ihr uns unsere Arbeit machen. Wir müssen dafür beide transparent miteinander umgehen: wie sehen eure Systeme aus, in die unsere Hardware sich einfügen muss? Wir sind dafür transparent, was unsere Arbeit und unsere Resultate angeht. Wir arbeiten proaktiv miteinander.
Lerne aus Post-Mortems
Am Ende jeden Sprints gibt’s einen gemeinsamen Review, in dem wir herausfinden, ob wir uns im Projekt in die richtige oder in eine falsche Richtung bewegen. Wir machen gleich danach, team-intern, eine Retrospektive, um aus dem Sprint zu lernen, was wir effektiver und besser machen. Wir wollen unser Verhalten bereits im nächsten Sprint anpassen.
Dafür solltet ihr erwarten, von unseren Fehlern zu hören und wie wir sie künftig vermeiden wollen. Wenn ihr eingeladen werdet, kommt ihr bitte auch zur Retrospektive und helft uns, unsere Zusammenarbeit zu verbessern. Wenn wir mit Änderungswünschen zu euch kommen, um beispielsweise unsere Produktivität zu steigern, seid ihr bitte offen dafür, soweit möglich.
Fazit
Und das war’s. Nicht besonders viele und nicht besonders komplexe Regeln, die unsere Zusammenarbeit in einem agilen Hardware-Entwicklungsprojekt deutlich verbessern können. Wollen wir das mal gemeinsam ausprobieren?
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
- Immer dran denken: Software ist soft, Hardware ist hard. ↩︎