Erhöhte Teamarbeit im Focus Sprint

Von Christian Jäggi 

Die Methode Challenge Take-off! wird am ersten Tag vom einwöchigen Focus Sprint (1 Woche, 1 Projekt, alle Entwickler) angewendet.

Im Anwendungsfall wird untersucht, ob die Methode eine intensivere Teamarbeit (Zufriedenheit) fördert, indem jedes Mitglied seine Ideen direkt in die Produktentwicklung einbringt. In kurzen Zyklen (tageweise) werden Prototypen direkt von und mit den Usern 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 Entwicklern, Designern und Entscheidungsträgern reflektiert. Falls gewünscht, kann der Prozess in nachfolgenden Sprints wiederholt resp. weitergeführt werden.

Können durch hohe Beteiligung des Entwicklerteams am Designprozess die Zufriedenheit gesteigert werden und vielfältigere Lösungen entstehen?

Ausgangslage

Das Entwicklerteam 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 Kunden helfen, ihre mit Sensirion Sensoren gesammelten Daten nach einer Messung in intuitiver und ansprechender Form nachzuvollziehen?”

Vorgehen & Methodenanwendung

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 Teilnehmer 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 Facilitator/Moderator es so laufen und notierte sämtliche Diskussionen in tabellarischer Form kurz und prägnant. Der Product Owner (Entscheidungsträger) sowie Entwicklungsleiter konnten sich ebenso wie alle Entwickler und Designer einbringen und lobten die Ideen und Partizipation der Teilnehmer. 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 inkl. Tests konnte leider nicht ganz so eingehalten werden. Zwar gab es unter den Entwicklern viele gute Diskussionen, die aber leider auch ineffizient waren. Gründe:

  • Unklare User-Stories
  • Arbeitsunterbrüche und Kontext-Wechsel durch Daily-Business Anfragen
Ergebnisse & Reflexion
  • Die Beteiligung vom kompletten Team im Workshop war sehr hoch. Sämtliche Entwickler 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 mussten höher priorisierten Projekten nachgehen und konnten nur kleinere Rollen bei der Implementierung einnehmen.
  • Einige Entwickler 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.
Systembeschreibung des Anwendungsfalls Focus Sprint
Systembeschreibung des Anwendungsfalls Focus Sprint
Vorlage für Workshop-Teilnehmer
Vorlage für Workshop-Teilnehmer
Ergebnisse im Workshop
Ergebnisse im Workshop