Im Anwendungsfall wird untersucht, ob die Methode eine intensivere Teamarbeit (Zufriedenheit) fördert, indem jedes Mitglied seine*ihre Ideen direkt in die Produktentwicklung einbringt. In kurzen Zyklen (tageweise) werden Prototypen direkt von und mit den Usern und Userinnen getestet. Somit können falsche Annahmen und Abweichungen schnell erkannt und im Teamentscheid korrigiert werden. Die intensive Zusammenarbeit in einem Focus Sprint bildet somit die logische Weiterarbeit nach dem Methoden-Workshop.
Am Ende der Woche werden in einer Feedback-Runde (Retrospective) die Resultate und der Prozess mit den Entwickelnden, Designern und Designerinnen und Entscheidungstragenden reflektiert. Falls gewünscht, kann der Prozess in nachfolgenden Sprints wiederholt respektive weitergeführt werden.
Können durch hohe Beteiligung des Entwicklungsteams am Designprozess die Zufriedenheit gesteigert werden und vielfältigere Lösungen entstehen?
Das Entwicklungsteam arbeitet im Moment mit einem an Kanban angelehnten Scrum Framework (Scrumban) im zweiwöchigen Intervall an verschiedenen Projekten gleichzeitig. Nun soll der Fokus auf die Produktentwicklung eines neuen Visualisierungstools gelegt werden. Das gesamte Scrum-Team arbeitet während einer Woche ausschliesslich an diesem Produkt oder nimmt wenigstens am Methodenworkshop am ersten Tag teil. Damit hat jede Person die Möglichkeit sich beim Ideen-Sammeln einzubringen und die Lösung mitzugestalten, zu testen und mit wertvollem Feedback zu verbessern.
Die «How Might We…» - Frage des Entwicklungsteams lautete: “Wie können wir der Kundschaft helfen, ihre mit Sensirion Sensoren gesammelten Daten nach einer Messung in intuitiver und ansprechender Form nachzuvollziehen?”
Kick-off
Im Kick-off der Methode erfolgte dessen Erklärung und was es mit dem folgenden Focus Sprint auf sich hatte. Dies geschah im Anschluss an das reguläre Sprint-Planning in mündlicher/informeller Form im Sitzungszimmer.
Self-Study
Im Anschluss ans Kick-off wurde die Eigenrecherche von den Team-Mitgliedern am eigenen Arbeitsplatz durchgeführt. Einigen war noch nicht ganz klar, wie sie präsentieren mussten, resp. was genau das Präsentationsobjekt sein soll. Es wurde den einzelnen Personen nochmals klar erklärt, dass eine analoge Form (Papier) mit Notizen (für alle anderen sichtbar auf A3) gewünscht ist und sie diese in den Workshop mitbringen sollen.
Workshop
Bestehend aus Warm-up, Ideate & Sketch, Share, Decide
Der Workshop geschah an einem Nachmittag und wurde noch ohne Pause durchgeführt (diese kam erst in der 2. Iteration der Methode hinzu). Die Teilnehmenden haben sich gut einbringen können, obwohl die 1-2-4-All Methode ein wenig chaotisch durchgeführt wurde. Der Ablauf glich eher Einzelpräsentationen, die direkt in die Diskussion übergingen. Da die Ideen und der «Flow» sehr gut waren, liess der*die Facilitator*in/Moderator*in es so laufen und notierte sämtliche Diskussionen in tabellarischer Form kurz und prägnant. Der Product Owner (Entscheidungstragende) sowie die Entwicklungsleitung konnten sich ebenso wie alle Entwickler*innen und Designer*innen einbringen und lobten die Ideen und Partizipation der Teilnehmenden. Am Schluss wurde (aus Zeitgründen nur kurz) versucht den Product Backlog zu erstellen. Es resultierte eine Produkte-Vision mit unscharf definierten User-Stories.
Focus Sprint
Die Herangehensweise des «fail fast» durch kurze Build-Measure-Learn Zyklen inklusive Tests konnte leider nicht ganz so eingehalten werden. Zwar gab es unter den Entwicklern und Entwicklerinnen viele gute Diskussionen, die aber leider auch ineffizient waren. Gründe:
- Unklare User-Stories
- Arbeitsunterbrüche und Kontext-Wechsel durch Daily-Business Anfragen
- Die Beteiligung vom kompletten Team im Workshop war sehr hoch. Sämtliche Entwickler*innen brachten sich in der Ideenfindung ein.
- Die Resultate (langfristige Produkte-Vision und Wireframes) wurden von allen und insbesondere vom Product Owner sehr geschätzt.
- Der Team-Spirit war hoch und der Zusammenhalt spürbar.
- Einige Entwickler*innen mussten höher priorisierten Projekten nachgehen und konnten nur kleinere Rollen bei der Implementierung einnehmen.
- Einige Entwickler*innen empfanden den MVP technisch zu wenig spezifiziert (User Stories hätten detaillierter ausgeführt werden können).
- Von aussen wirkten die häufigen Diskussionen und Tests ineffizient. Teilweise waren sie es auch.
- Es konnte nicht der gesamte Product Backlog abgearbeitet werden. Die darin enthaltenen User Stories können im Scrum Framework in künftigen Sprints regulär eingeplant werden.
- Tipp für die Zukunft: Focus Sprint besser zwei Wochen lang, dafür nur nachmittags durchführen. So haben Daily-Business (am Morgen) und Focus Sprint (am Nachmittag) Platz.
