Wer hat Angst vorm ersten Wurf?

Seit einiger Zeit bin ich nun auf einem Projekt, in dem die größte Herausforderung darin besteht, Hardware, Elektronik und Software derart zu synchronisieren, dass der gewählte agile Rahmen nicht zur Farce verkommt. Ein wichtiger Teil dieser Herausforderung ist es vor allem bei der Entwicklung von Hardwarekomponenten, nicht versehentlich doch in der Wasserfalle zu versinken: Wenn die Anforderung lautet: „Als Hans-Peter möchte ich die Höhe meines Schreibtischstuhls per iPhone-App steuern, um mir nicht ständig die Finger einzuklemmen“, ist die Verlockung groß, zu sagen: In Sprint 1 machen wir erstmal drei Konzepte für höhenverstellbare Schreibtischstühle, dann wählen wir im Review das Beste aus und fangen in Sprint 2 mit der Detailkonstruktion an. Im Anschluss können wir dann die notwendigen Teile bestellen und wenn der Einkäufer die Lieferanten ordentlich auf Spur gebracht hat, können wir die Teile sogar schon in Sprint 3 zusammenbauen. Am Ende des dritten Sprints wird dann gereviewt und es passiert - oh Wunder - in der Regel Folgendes: Entweder es gibt Verbesserungsvorschläge, die in Sprint 4 eingearbeitet werden können, oder man merkt, dass das Konzept zwar auf dem Papier super aussah, es allerdings jedwede Praxistauglichkeit vermissen lässt. Das bedeutet wiederum, dass man zu einem der anderen Konzepte umschwenken muss. Zu allem Überfluss schieben Elektroniker und Softwerker jetzt schon die Frustkugel, weil sie noch von überhaupt gar niemandem nach ihrer Meinung gefragt wurden. Das Ganze hat dann den agilen Charme eines Hochseedampfers beim Rückwärtseinparken.Die Kunst besteht also darin, auch hier das Prinzip „fail early and often“ bewusst anzuwenden und vor allem davon auszugehen, dass ich als Product Owner ein Team von Experten mit der Entwicklung meines Produktes betraut habe. Die Wahrscheinlichkeit ist also gering, dass ich statt eines Schreibtischstuhls auf einmal einen Terassenklappstuhl in Toskana-Optik bekomme. Voraussetzung hierfür ist allerdings auch, dass ich meine Akzeptanzkriterien klar formuliert habe.Ganz ohne Konzept geht es natürlich auch nicht. Ziel muss es aber sein, bereits mit einem Konzept lauffähig zu sein und schon im ersten Sprint Konzept, Konstruktion und Bestellung unterbringen zu können. So kann, die entsprechende Lieferzeit vorausgesetzt, bereits im nächsten Sprint zusammengebaut und begutachtet werden. Tritt hierbei Feedback zutage, kann dieses ohne weiteres in den kommenden Sprint eingebaut oder eben in das Backlog für spätere Sprints aufgenommen werden. Sollte sich herausstellen, dass sich die Ausarbeitung dieses Konzeptes als komplett nutzlos erweist, kann das Team nun, ohne Zeitverlust, ein neues Konzept erstellen, oder es greift - beispielsweise bei längeren Lieferzeiten - auf ein in der Zwischenzeit erarbeitetes Konzept zurück und der Zyklus wiederholt sich.Und wo sind die Elektroniker und Softwareentwickler in der Zwischenzeit? Na immer mittendrin! Die unmittelbare Zusammenarbeit in der Konzeptions und Ausarbeitungsphase gibt den genauen Rahmen vor, innerhalb dessen diese Komponenten miteinander zu funktionieren haben. Der Schlüssel ist auch hier mal wieder „vertraue dem Prozess“. Wer sich früher davon verabschiedet, bereits im Vorfeld alle Eventualitäten einplanen zu wollen, kann auch früher damit beginnen, das ohnehin aufkommende Feedback zu integrieren.