In der Welt der Softwareentwicklung gibt es eine kontinuierliche Debatte darüber, wie man die Erfahrung der Nutzenden (UX) nahtlos in agile Methoden wie Scrum integrieren kann.

UX und Scrum erscheinen wie zwei Welten, die auf den ersten Blick aufgrund eigener Eigenschaften und Prioritäten nicht zusammenpassen.

Unser neuer Blogbeitrag erklärt, wie eine Zusammenarbeit zwischen UX und Scrum erfolgreich gelingen kann.

Um eine realitätsnahe Abbildung zu erreichen, wird zunächst ein projekttypisches Setup skizziert:

In einem Projekt mit einer Laufzeit von einem Jahr stehen vier Entwickelnde, ein Product Owner (intern oder extern) sowie ein Scrum Master im Fokus. Der Projektverlauf ist durch einen strukturierten Rahmen geprägt, der sich in zweiwöchigen Sprints manifestiert.

Jeder Sprint wirft neue Fragen und Antworten auf, während das Gesamtbild des Projekts sich kontinuierlich entwickelt. Trotz dieser klaren Struktur kann der Einsatz von UX in diesem Kontext durch verschiedene Umstände geprägt sein. Daher präsentieren wir vier verschiedene Szenarien, die jeweils unterschiedliche Herausforderungen und Chancen für den Einsatz von UX aufzeigen.

SZENARIO 1: „Preacher“– Empower the team!

In einem Projektszenario mit sehr begrenztem Budget und geringer User-Interaktion können Herausforderungen in unklaren Erwartungen und Einsatzmöglichkeiten liegen, weil der Product Owner bspw. nicht auf eine Zusammenarbeit mit der UX vorbereitet ist.

Wann und wo soll UX in den Entwicklungsprozess integriert werden? Und welche spezifischen Beiträge können UX Designer leisten, sodass sie einen Mehrwert für das Projekt bringen?

Ein weiteres Hindernis sind die limitierten Abstimmungsmöglichkeiten zwischen dem UX-Team und den Entwickelnden, wodurch Missverständnisse aufkommen können.

Diese Unsicherheiten können zu Verzögerungen und ineffektiver Nutzung der begrenzten Ressourcen führen.

Um diesen Problematiken entgegenzuwirken, kann die Rolle des „Preacher" von UX Professionals eingenommen werden.

Der „Preacher“ agiert insbesondere dann als unterstützende Kraft, wenn das Team sehr technisch fokussiert ist und über begrenzte Erfahrung im Bereich UX verfügt, aber dringend einen Anreiz für eine verstärkte Fokussierung auf die Bedürfnisse der Nutzenden benötigt.

Er fungiert als Verfechter der nutzungszentrierten Arbeitsweise und strebt danach, das Bewusstsein im Team für die Relevanz von UX zu stärken.

Dies kann mittels einer Durchführung von Schulungen für Product Owner und das Entwicklungsteam stattfinden, in welchen Möglichkeiten und Methoden der nutzungszentrierten Arbeitsweise aufgezeigt werden. Die Schulungen können verschiedene Hilfsmittel wie standardisierte Fragebögen, Interview Guidelines, Persona Templates und UI Libraries verwenden, um den Teammitgliedern praktische Werkzeuge an die Hand zu geben.

Auch eine Bereitstellung von Konzepten, Forschungsergebnissen (Research) und Designs kann der „Preacher“ übernehmen. Damit diese Zuarbeit im Sprintrhythmus effektiv funktioniert, müssen jedoch bestimmte Spielregeln festgelegt werden.

Der UX Professional als „Preacher“ ist ein zentraler Ansprechpartner für das gesamte Team und sollte daher eine starke Präsenz zeigen, insbesondere in Meetings und Terminen. Es ist wichtig, dass er dabei eine lockere Atmosphäre schafft und ein erhobener Zeigefinger vermieden wird.

Um ein gutes Gefühl für die Rolle des UX Designers im Team zu vermitteln, sind lockere Termine von Bedeutung. In diesen Terminen kann der „Preacher“ durch das Einbringen von guten Beispielen aus anderen Projekten oder Produkten anschaulich machen, was in der Vergangenheit gut funktioniert hat und wie UX einen Mehrwert bieten kann. Dies trägt dazu bei, das Verständnis und die Akzeptanz für die Bedeutung von UX im Team zu fördern und die Zusammenarbeit zu stärken.

SZENARIO 2: „Mentor“- Support and guide!

Im nächsten Szenario herrschen ein knappes Budget und ein hoher Arbeitsaufwand, der bewältigt werden muss. Die Herausforderungen sind vielfältig: Es besteht starker Zeitdruck, da die Entwicklung auf die Zuarbeit angewiesen ist und voranschreitet.

Der Kommunikationsaufwand ist hoch, da eine effektive Abstimmung und Priorisierung der Themen erforderlich sind. Dabei gilt es, einen Einklang zwischen Abstimmung und tatsächlicher Tätigkeit herzustellen, wobei das Team auch Input geben und aktiv werden möchte.

Zusätzlich besteht die Gefahr, dass bei zu vielen Abstimmungen nicht genügend Zeit für die notwendigen Arbeitsaufgaben bleibt. Ein weiterer Aspekt ist der Grad der Ausarbeitung, wobei viele UX Professionals dazu neigen, sich im Detail zu verlieren, was die Effizienz beeinträchtigen kann.

Mit der Rolle des „Mentor“ kann diesen Aufgaben ideal begegnet werden.

Von entscheidender Bedeutung ist dabei, dass der „Mentor“ einen umfangreichen Erfahrungsschatz als UX Designer mitbringt. Der „Mentor“ muss wissen, welche Aufgaben einer eigenen Bearbeitung bedürfen und welche an das Scrum Team delegiert werden können. Eine regelmäßige und intensive Zusammenarbeit mit dem Product Owner, gepaart mit einer klaren Priorisierung der Themen und der Untersuchung notwendiger Recherche, ist unerlässlich. Dabei empfiehlt es sich, einen Fixtermin zwischen UX Designer und Product Owner zu vereinbaren.

Der „Mentor“ sollte aktiv an Refinements und Reviews teilnehmen, um offene Fragen frühzeitig zu klären und Feedback der Stakeholder aufzugreifen.

Zudem ist die Verwendung von Hilfsmitteln nicht nur wichtig, um sie bereitzustellen, sondern auch, um selbst davon zu profitieren. Die Realität solcher Projekte erfordert ein geschicktes Jonglieren mit den verfügbaren Ressourcen und ein stetiges Suchen nach Lösungen, die allen Beteiligten gerecht werden.

Durch die Unterstützung des „Mentor“ haben Teammitglieder die Möglichkeit, ihre Kompetenzen im Bereich UX kontinuierlich weiterzuentwickeln.

Dementsprechend könnte die Rolle des „Mentor“ sich in Zukunft darauf konzentrieren, das Team dazu zu befähigen, UX-Arbeit eigenständig durchzuführen, anstatt sie für das Team zu erledigen. Dies setzt voraus, dass das Team, welches das Frontend entwickelt, bereit ist, diese Verantwortung zu übernehmen. Ein wichtiger Aspekt dabei ist das Verständnis und das Einfühlen in die Rolle der Entwickelnden, um effektive Unterstützung und Anleitung bieten zu können.

SZENARIO 3: „Maker“- Doing instead of talking!

Im dritten Szenario, das zwar von ausreichend Budget und fehlenden Abhängigkeiten geprägt ist, ergeben sich dennoch eine Reihe von Herausforderungen, denen begegnet werden muss.

Viel Budget geht einher mit viel Zeit, was wiederum bedeutet, dass eine Vielzahl von Aufgaben bewältigt werden können.

Eine Herausforderung besteht darin, die erforderliche Transparenz sicherzustellen. Die dringend notwendige Integration von UX in den Sprintrhythmus trägt zu dieser Herausforderung bei, da am Ende jedes Sprints Ergebnisse erwartet werden. Für Tests mit den Nutzenden ist die Planung fester Time Slots nötig, um innerhalb der Sprints Termine mit ihnen zu finden.

Durch nicht vorhandene Abhängigkeiten zu anderen Projekten fehlt es außerdem an einem Fachaustausch mit dem UX-Kollegium, welcher für UX Designer ein wichtiges Gut darstellt.

Die Rolle des „Maker“ widmet sich mit einer Hands-on-Mentalität direkt den UX-Aufgaben und liefert praktische Lösungen. Dieser Charakter arbeitet besonders effektiv, wenn schnelle Ergebnisse gefragt sind und das Team direkte Unterstützung bei der Umsetzung von UX-Themen benötigt.

Der „Maker“ innerhalb des Entwicklungsteams ist von zentraler Bedeutung für die erfolgreiche Integration von UX-Aufgaben in agile Projekte. Ein wesentlicher Aspekt dieser Rolle besteht darin, sich vollständig in die Dynamik und die Arbeitsweise des Entwicklungsteams zu integrieren. Dies beinhaltet die Teilnahme an verschiedenen Team Meetings, wie Dailys und den Sprint Refinements, um kontinuierlich über den Fortschritt und die Anforderungen informiert zu sein.

Auch die aktive Teilnahme an den Sprintevents des Entwicklungsteams ist ein wichtiger Aspekt. Durch diese Beteiligung erhöht der „Maker“ seine Sichtbarkeit im Sprint und ist damit Teil des Sprintrhythmus. Dies ermöglicht eine enge Zusammenarbeit mit den Teammitgliedern und eine effektive Abstimmung der UX-Aufgaben mit den anderen Entwicklungsaktivitäten.

Um sicherzustellen, dass die UX-Aufgaben angemessen berücksichtigt und priorisiert werden, ist es entscheidend, sie im Backlog und Sprint transparent sichtbar zu machen. Die UX-Aufgaben können sowohl als Subtasks innerhalb anderer Storys als auch als eigenständige Storys im Backlog vorhanden sein. Eigenständige Storys dienen als Grundlage für die Entwicklung und erfordern einen zeitlichen Vorlauf zur Planung und Umsetzung.

Zwischen UX Professional und Product Owner braucht es ein Hand-in-Hand-Arbeiten und eine klare Kommunikation der User-Anforderungen und Abhängigkeiten, um eine Planung auf Sicht zu gewährleisten.

Eine entscheidende Funktion des „Maker“ besteht darin, die UX-Themen frühzeitig in den zukünftigen Sprints zu planen und sicherzustellen, dass sie angemessen in die Sprint-Planung integriert werden. Dabei ist es wichtig, nicht zu weit im Voraus zu planen, sondern agil zu arbeiten und sich flexibel auf neue Anforderungen einzustellen.

Es empfiehlt sich außerdem, ein UX Review im Sinne der Definition of Done zu etablieren.

Hilfreich ist dabei die Nutzung einer User Story Map und die Definition eines klaren, minimalen funktionsfähigen Produkts (MVP). Die Technik des User Story Mapping ermöglicht es dem Scrum Team und der UX, die erforderlichen Funktionalitäten besser zu verstehen und grob zu erfassen. Diese grobe Erfassung erlaubt es, im Verlauf der Sprints die Details schrittweise zu verfeinern, während gleichzeitig klar differenziert wird, welche Funktionen Teil des MVP sind und welche nicht.

Insgesamt trägt die Rolle des „Maker“ dazu bei, die Akzeptanz und das Verständnis für die Bedeutung von UX im Entwicklungsteam zu erhöhen. Durch eine enge Zusammenarbeit mit den Teammitgliedern und eine transparente Integration der UX-Aufgaben in die Arbeitsabläufe des Entwicklungsteams wird sichergestellt, dass die UX-Aspekte angemessen berücksichtigt und umgesetzt werden, um ein optimales Benutzungserlebnis zu gewährleisten.

SZENARIO 4: „Daywalker“ – The one who walks between worlds!

Die Herausforderungen im vierten Szenario, das durch ausreichend Budget und Abhängigkeiten zu anderen Projekten gekennzeichnet ist, sind vielschichtig.

Mit steigender Produktkomplexität nimmt der Kommunikationsaufwand zu, da verschiedene Teams an der Entwicklung des Produkts beteiligt sind und in die Planung einbezogen werden müssen. Gleichzeitig kann die Entscheidungsfähigkeit sinken, da Strategieentscheidungen getroffen werden müssen, die Auswirkungen auf mehrere Bereiche haben können. Ein weiterer zentraler Aspekt ist der Wissenstransfer, der kontinuierlich stattfinden muss, um sicherzustellen, dass relevantes Wissen stets geteilt wird und alle Teammitglieder auf dem neuesten Stand sind.

Der „Daywalker“, der zwischen den Welten wandelt, nimmt eine besondere Rolle in der Produktentwicklung ein. Seine Aufgabe besteht darin, Brücken zwischen verschiedenen Teams, Technologien und Projekten zu bauen.

Seine Präsenz erstreckt sich über alle Aspekte des Projekts, er hat Zugriff auf den anderen Rollen verborgene Insights und nimmt an der Entscheidungsfindung teil.

Eine der wichtigsten Funktionen des „Daywalker“ ist die enge Zusammenarbeit mit Softwarearchitekten, um ein besseres Verständnis für die technische Seite des Produkts zu entwickeln und somit Einfluss auf zukünftige Architekturentscheidungen zu nehmen. Dabei geht es nicht nur um das eigene Fachgebiet, sondern auch um die Koordination zwischen Backend- und Frontend-Teams.

Um eine konsistente User Experience sicherzustellen, etabliert der „Daywalker“ regelmäßige UX-Sync-Termine, bei denen über gemeinsame Entwicklungsmöglichkeiten diskutiert wird.

Durch den Austausch von Research-Ergebnissen und der Teilnahme an Reviews anderer Teams trägt er dazu bei, Synergien zu schaffen und ein übergreifendes Verständnis des Gesamtprodukts zu fördern. Dabei ist es auch sinnvoll, einen gemeinsamen Pool von Testpersonen zu schaffen und zu nutzen.

Filter und Hauptnavigationstools sind häufige Themen, bei denen eine Zusammenarbeit es ermöglicht, bereits vorhandene Lösungen effektiv zu nutzen, anstatt sie neu zu erfinden.

Darüber hinaus arbeitet der „Daywalker“ an der Etablierung eines Design Systems, das als Grundlage für ein homogenes Produkt dient.

Um all diese verschiedenen Bereiche zusammenzuführen, fungiert der „Daywalker“ als Bindeglied und trägt dazu bei, dass das Produkt auch bei steigender Komplexität eine klare und konsistente User Experience bietet.

Trotz ihrer scheinbaren Unvereinbarkeit bieten UX und Scrum in der Softwareentwicklung die Möglichkeit einer fruchtbaren Zusammenarbeit.

Die hier vorgestellten vier Rollen liefern verschiedene Ansätze zur Integration von UX in den unterschiedlichsten Projektszenarien: von der beratenden Rolle des „Preacher“ über die das Team anleitende und gelegentlich eingreifende Rolle des „Mentor“; der aktiven, vollends integrierten Rolle des „Maker“ bis hin zum integrierten „Daywalker“, der in vielen Projekten Präsenz zeigt und seltener selbst tätig werden kann.

Eine gute Integration von UX gelingt letztendlich vor allem durch viel aktive Präsenz im Team und das damit einhergehende Sichtbarmachen der Relevanz von User Experience Design.

Die Messbarkeit dieser Integration kann anhand verschiedener Kriterien erfolgen, wie bspw. der Anzahl der UX-Aufgaben im Backlog und im Sprint Backlog. Darüber hinaus können regelmäßige Statusrückfragen der Entwickelnden zur Zusammenarbeit mit dem UX-Team sowie die Erfassung von Feedback in Retrospektiven wichtige Indikatoren sein. Letztendlich ermöglicht es diese Messbarkeit, den Grad der Integration von UX in das Team besser zu verstehen und gegebenenfalls Anpassungen vorzunehmen.

Unabhängig von den spezifischen Herausforderungen und Chancen, denen wir gegenüberstehen, sollte jedoch immer der User im Mittelpunkt stehen. Denn letztendlich sind es die Nutzenden, für die das Produkt entwickelt wird. Ressourcen wie Geld und Lebenszeit bestimmen, welche Möglichkeiten uns zur Verfügung stehen, um ihre Bedürfnisse bestmöglich zu erfüllen. Es ist wichtig, den Weg zu wählen, der am besten zur jeweiligen Situation passt. Dabei sollte man sich bewusst sein, dass es keine universelle Lösung gibt, sondern dass die richtigen Formate gefunden und genutzt werden müssen.

Agile Methoden wie Scrum bieten definitiv eine gute Gelegenheit, alle Teammitglieder in den Entwicklungsprozess einzubeziehen und die Zusammenarbeit zu stärken. Indem die Prinzipien der Nutzungszentrierung in den Mittelpunkt der Arbeit gestellt und sich auf die Bedürfnisse und Erwartungen der Nutzenden konzentriert wird, kann sichergestellt werden, dass das Produkt eine optimale User Experience bietet.