Crossfunktionale Teams und Integration von UXB in Scrum

Markus Stroh - 11.11.2019

Wie schon häufiger an dieser Stelle möchte ich ein paar Impressionen aus unserem internen Wissensforum rund um die Themengebiete Scrum / Agile veröffentlichen, in der Hoffnung, dass es vielleicht dem einen oder anderen Kollegen weiterhilft. In diesem SOFA-Talk (Scrum Open Forum ARITHNEA) entfernten wir uns bewusst von den klassischeren Fokusthemen und griffen das Thema: „Crossfunktionale Teams und Integration von UXB in Scrum“ auf.

Im Themenlead waren dieses Mal Volker Bogacki (Projektleiter und Vertreter der Scrum Initiative), Ulrike Steininger (Creative Director im Bereich UXB) und Markus Stroh (Scrum Master, Vertreter der Scrum Initiative und Gründer des SOFA-Talks).

 

Startpunkt crossfunktionale Teams

Schon zu Beginn des Talks war allen Kollegen klar, dass crossfunktionale Teams und T-shaped Entwickler einen essentiellen Aspekt darstellen und dass wir deutliche Vorteile durch unabhängige Teams erzeugen. Dabei ist der Grundgedanke von autarken Teams, die eigenverantwortlich handeln können und dazu handlungsfähig sein müssen, Dreh- und Angelpunkt eines jeden Scrum Teams. Wenn wir es nicht bewerkstelligen können „Selbstversorger“ zu sein, dann geraten wir immer wieder in Situationen in denen wir nicht agieren können. Die Kollegen in der Runde und im Publikum teilten diese Auffassung.

Aus dieser Richtung kommend nahm die Diskussion einen Schwenk: Wie sind crossfunktionale Teams bei uns überhaupt aufgestellt? Komplexe Projekte benötigen Kollegen im Backend - teilweise auf mehreren Ebenen - sowie im Frontend und auch in Konzeption und Design. Zählen wir dabei den Frontend-Experten bereits zu UXB? Möglicherweise ist die Zuordnung gar nicht zentral wichtig. Dennoch war die Erkenntnis vorherrschend, dass es in der Praxis deutliche Unterschiede gibt, wenn wir von crossfunktionalen Teams reden. Häufig ist es möglich Backend- und Frontendbestandteile in einem Sprint zu erledigen. Oftmals haben wir hier bereits den ersten Einschnitt und sind dazu gezwungen in einem Sprint Frontend vorzulegen, um es dann im nächsten Sprint in das Backend zu integrieren. Vom Grundsatz „potentially shippable“ und „functional value“ entfernen wir uns damit.

Wer mehr über Theorie und Praxis von Scrum erfahren möchte kann sich kostenlos unser Whitepaper dazu herunterladen.

 

Mit No-Limit-Mindset zu neuen Gedankengängen

Der Austausch wurde ab diesem Zeitpunkt mit einem No-Limit-Mindset weitergeführt und kam zu einigen interessanten Erkenntnissen. Es wurde klar, dass Konzeption und Design durchaus noch einen weiteren Interaktionsloop hinzufügen und dass wir diesen Loop aktuell selten bis gar nicht vollumfänglich in unseren Scrum Teams und in die Sprints direkt integrieren. Warum ist das so?

Ganzheitlichkeit von Usability und Design im Gesamtkontext einer Webseite oder eines Shops waren hier zentrale Diskussionspunkte. Wir möchten gerne zuerst alles durchdenken, da wir ansonsten kein scharfes Bild vom zukünftigen Ergebnis haben. Kontrovers diskutiert: Vielleicht braucht man dieses Bild gar nicht? Möglicherweise würde ein grober Rahmen genügen, in dem man sich dann iterativ voran bewegt und auch Dinge wieder verwirft und neu implementiert. Bedeutet, dass wir hier potenziell mehr Abfall produzieren könnten, aber auch flexibler werden und dadurch näher an den Sprint und seine anspruchsvollen Timings herankommen. Insgesamt könnte das auch den agilen Gedanken greifbarer werden lassen.

 

Sprinttimings und Storyschnitte

Sprinttimings wurden zum nächsten Diskussionsfokus. Der vorherrschende Weg würde einen weiteren Interaktionsloop integrieren. Im schlimmsten Fall würden wir damit drei Sprintlängen benötigen, um etwas zu erschaffen das „potentially shippable“ ist. Häufig gehen Projekte mit drei-wöchigen Sprints ins Rennen. Bedeutet, dass alle Beteiligten erst nach einem 9-Wochen-Zyklus ein vollumfängliches Ergebnis zu Gesicht bekommen. Bei Verzögerungen sogar später, zumindest in den Worst-Case-Fällen. Hier wurde es oppositionell: Würden wir unsere Sprints auf eine Woche reduzieren, dann könnten wir trotz der getrennten Interaktionsloops in drei Wochen etwas Ganzheitliches abliefern. Natürlich müsste dazu der Storyschnitt gravierend anders vollzogen werden und auch die einzelnen Abteilungen müssten gänzlich unterschiedlich mit ihrer Arbeit umgehen. Klang dennoch interessant!

Dabei wurde jedoch deutlich, dass wir wieder Scheiben schneiden, in Silos denken und die Interaktion zwischen den Kollegen inhomogen wirkt. Die Kollegen brachten einen zweiten Ansatz in den Austausch ein: Bekommen wir alle Abteilungen in einem drei-wöchigen Sprint unter? Auch wurde offensichtlich, dass man gravierend Umdenken müsste. Design-Sprints wurden in der Runde diskutiert, die mit klaren täglichen Timeboxen versuchen, zu einem zeitlich fokussierten Ziel zu gelangen. Die User Stories müssten funktional kleiner werden, könnten dafür den kompletten Durchstich ermöglichen. Die Belohnung wäre ein reines Deliverable, welches von Design bis Umsetzung in einem Sprint abgefertigt werden könnte. Allerdings schwang bei dieser Herangehensweise auch die Angst vor gerissenen Sprints und Verzögerungen mit.

Sie arbeiten bereits mit Scrum? Dann empfehle ich unsere zehnteilige E-Mailserie in der sie wöchentlich einen Tipp zur Verbesserung Ihrer Scrum-Prozesse erhalten. Jetzt kostenlose E-Mail-Serie abonnieren.

 

Take-Away

Sehr spannend bei diesem Talk war, dass wir uns gemeinschaftlich schnell und klar einig darüber geworden sind, welche Vorteile uns crossfunktionale Teams bringen. Das Ziel alle Interaktionsloops in einem Sprint zu handhaben wäre wünschenswert. Vor allem aus dem Fokus heraus die Time-to-Market zu reduzieren und dem Kunden etwas Greifbares übergeben zu können. Die Herausforderungen dabei liegen auf der Hand: man müsste dazu in der eigenen Aufstellung, Abarbeitung und Erwartungshaltung anders vorgehen als bisher. Auf der anderen Seite gehört auch der Kunde als zentraler Punkt mit dazu. Sieht er die Vorteile? Versteht er Continuous Improvement als Chance, auch wenn dafür Dinge im schlechtesten Fall mehrfach angefasst werden müssen?

Letztlich gibt es passende Ansätze die Kollegen in einen Sprint zu integrieren, egal aus welcher Domäne sie dabei kommen. Eine offene Herangehensweise und moderne Methoden sind dazu zwingend notwendig, da ansonsten der harte Zeitanschlag zu einem unüberwindbaren Hindernis wird. Wir konnten in unserer Diskussionsrunde nicht zweifelsfrei klären, ob Design-Sprints bzw. Continuous Improvement-Ansätze womöglich zu einer schlechteren Wahrnehmung der Usability innerhalb einer Webseite führen, weil vorab weniger Zeit in Upfront-UX geflossen ist. Vielleicht ist es an der Zeit für ein mutiges Experiment!

In diesem Sinne: Keep calm and Scrum on!

Tags: Agile Business - Beratung & Strategie - Inside-ARITHNEA

Kommentar

newsletter-phone

ARITHNEA Newsletter

Aktuelle Trends, interessante digitale Lösungen, neue Best-Practice-Projekte von ARITHNEA oder Infos über wichtige Branchenevents – mit unserem monatlichen Newsletter sind Sie im Digitalen Business stets up to date.

Kostenlos Abonnieren