Scrum bei alpha-board (Teil 3): Produkte entwickeln, an die vorher niemand gedacht hat

Was wir nun wissen ist, wie man möglichst endanwenderorientiert Anforderungen aufsetzt (Scrum bei alpha-board - Teil 1) und warum wir diese stets kurzfristig spezifizieren (Scrum bei alpha-board - Teil 2). Was wir noch nicht geklärt haben: Wer schreibt die Anforderungen? Im klassischen Projektmanagement macht das oft ein Business Analyst oder ein Anforderungsingenieur intern im Fachbereich oder extern beim Kunden. Die Detailspezifikation von Anforderungen ist in diesen Fällen also sowohl personell als auch zeitlich von der Umsetzung getrennt.Das Ideal "Entwickeln, statt nur umsetzen“ hatte sich bei der alpha-board GmbH, einem Dienstleister für agile Hardware-Entwicklung, schon vor meiner Ankunft (vielleicht unbewusst) durchgesetzt. Die personelle Trennung zwischen Spezifikation und Umsetzung, wie im ersten Absatz beschrieben, war teilweise schon gar nicht mehr vorhanden. Unvorstellbar? Keineswegs, während meines Aufenthalts haben wir diese Mauer zwischen Spezifikation und Umsetzung kontinuierlich eingerissen. Im Folgenden sehen Sie einen Überblick über den Anforderungsprozess, mit dem wir als Team arbeiten. Als ideale Grundlage dient der Design-Thinking-Prozess, ausführlich auch beschrieben von Boris (Gloger 2014). Design Thinking lässt sich grundlegend in fünf Phasen unterteilen:

Discovery - Lass uns entdecken!

In der ersten Phase wird das Problem des Kunden von allen Beteiligten entdeckt. Es war der erste Workshop mit meinem neuen Scrum-Team und der Geschäftsleitung. Auch Vertreter aus dem Vertrieb wurden in dieses „Erkundungsteam" einbezogen. Während der Gespräche sorgten diese Kollegen immer wieder für einen neuen Blickwinkel auf Problematiken, das Gespräch war konstruktiv und vielseitig. Die initiale Idee für das Produkt hatte das Team bereits vorher kennengelernt. Für mich war essenziell, dass das Team diese Idee verstand, um die Herausforderungen der potenziellen Endanwender besser kennenzulernen. Das klassische Design Thinking geht hier weiter und versucht, wenn möglich, den Anwender selbst beim Auftreten des Problems zu beobachten oder über den Problemkontext zu interviewen (vgl. Gloger 2014, S.59ff). Auch der „Lean Start-up“-Gedanke greift dieses Vorgehen unter dem Begriff "Customer Discovery" auf.

Interpretation - ist alles.

Nachdem das Team die Problematik verstanden hatte, ging es nun darum, sie zu interpretieren. Boris schreibt dazu: Das Team soll nun die „Bedeutung“ und "den tieferen Sinn“ (suchen) und damit "Einsichten finden“ (vgl. Gloger 2014, S.73). In unserem Fall wich die nun generierte Vision im Ergebnis von der vorherigen initialen Produktidee ab. Durch die neue Vision wurde uns klar, dass speziell für eine Komponente die technischen Anforderungen höher waren als für marktübliche Vergleichsprodukte. Damit stieg das technische Risiko des Gesamtprodukts. Abschließend wurden die ersten Personas entwickelt (siehe Scrum bei alpha-board - Teil 1). Damit war der erste Tag vorüber. Es war anstrengend, aber im Großen und Ganzen waren alle zufrieden, denn der Grundstein für das neue Produkt war gelegt.

Ideation - Zuerst ist alles erlaubt.

Am nächsten Tag trafen wir uns wieder. Die dritte Phase des Design Thinkings ist die Ideengenerierung. Die Vision und die Endanwender gaben die Richtung vor. Die Ideation kann man mit der initialen Anforderungerhebung des Projektstarts vergleichen. Um den Endanwenderfokus nicht zu verlieren, benutzen wir dazu User Stories. Nach einem kleinen Crash-Kurs folgte schon die Übung: Wir schrieben die ersten Epics und User Stories zum aktuellen Produkt. Wichtig ist: Am Anfang ist grundsätzlich alles an Vorschlägen erlaubt, ganz nach der Brainstorming-Regel „Ideen sind immer wertvoll“. Im zweiten Schritt dachten wir über weitere Rahmenbedingungen für das Produkt nach. Zum Beispiel sollte unser Produkt zu Normteilen auf dem Markt kompatibel sein. Erst im letzten Schritt ging es an das Aussieben der Ideen. Outcome dieses Schrittes war ein konkretes funktionales Konzept für einen ersten Prototyp. Es hatte sich schlussendlich eine abgewandelte Variante der ursprünglichen Produktidee entwickelt.

Experimentation - Das ist unser Quality Gate.

Aus Scrum-Sicht befanden wir uns erst jetzt im Sprint. Schon beim Bauen des ersten Prototyps erhielt das Scrum-Team erstes Feedback: Was funktionierte und was nicht? Am interessantesten war für uns das Feedback eines außenstehenden Nutzers: Bei unserem Produkt bot es sich an, ein paar unbeteiligte Kollegen testen zu lassen. Wir waren überrascht, wie viel Feedback in kurzer Zeit von Anwendern generiert wird. Aus diesem Feedback entstanden neue Anforderungen oder alte wurden geändert. Qualität wird also darüber definiert, was funktioniert und was gut ankommt. Gesprochenes ist einfach erfassbar, Verhalten im Kontext zum Produkt zu interpretieren dagegen erfordert meist Übung und Kompetenz. Doch schon der bloße Fokus auf diese impliziten Informationen hilft dem Entwicklungsteam, sich in den Endanwender zu versetzen und so Potenziale zu heben.

Evolution - Der nächste, bessere Prototyp

Hatten wir zuerst gehofft, auf eine Regelungseinheit verzichten zu können, wurden wir in der Experimentation-Phase eines besseren belehrt. Zwar war die Funktion grundsätzlich erfüllt, aber unsere Anwender gaben uns das deutliche Feedback, dass der erhoffte Nutzen noch nicht eingetreten war. Die Evolution ist nichts anderes als die nächste Iteration: Unsere Hypothese wurde verfeinert und neue wurden formuliert. Und somit ging's in die nächste Runde auf dem agilen Weg der Produktentwicklung und wir bekamen die Chance, ein noch besseres Produkt zu bauen.

Hypothese und Learnings

Wenn wir einen Produktentwicklungprozess effektiv datengetrieben gestalten können, benötigt es

• eine Datenerhebung,
• die Erlaubnis, Anforderungen dort zu ändern, wo diese Daten entstehen,
• die Fähigkeit, veränderte Anforderungen in den aktuellen Produktentwicklungsprozess einfließen zu lassen
• und so wenige Übergaben wie möglich zwischen diesen Punkten.

Gerade der letzte Punkt wird im Design Thinking nochmal hervorgehoben, da schlussendlich alles in einem Team erledigt wird. Schon deshalb hat es mir geholfen, diesen Prozess tiefer zu untersuchen. Sich in dieser Offenheit des Produktentwicklungsprozesses ständig an den Endnutzer zu adaptieren, ist der große Vorteil agilen Arbeitens.In diesem Sinne, euer MarcusQuelle:Gloger, B. (2014). Wie schätzt man in agilen Projekten. München: Carl Hanser Verlag.