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.

Agile Toolbox
Produktentwicklung
Hardware
Scrum
bgloger-redakteur
July 18, 2016

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen
BG

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?
BG

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?

Scrum by the book - Die Power agiler Prinzipien
BG

Scrum by the book - Die Power agiler Prinzipien

Organisieren für das Dringliche – oder der Verlust des Wesentlichen
BG

Organisieren für das Dringliche – oder der Verlust des Wesentlichen

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode
BG

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode

Statt einer Rezension – OKR als Rezept
BG

Statt einer Rezension – OKR als Rezept

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren
BG

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen
BG

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt
BG

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt

FRAGE: Warum macht ihr eigentlich kein SAFe®?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe®?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?