Ich bringe Teams bei, wie sie UX-Praktiken und Scrum verbinden können. Die 4 Fragen, welche in jedem Training auftauchen, lauten: 

1. Sollen Designaktivitäten nicht einen Sprint vor der Entwicklungsarbeit stattfinden?
2. Gilt die Definition of Done auch für die Entdeckungsarbeit?
3. Was soll ich machen, wenn es keinen dedizierten Designer für unser Team gibt?
4. Sind reine „Lern-Sprints” in Scrum erlaubt?

Wenn du als Scrum Master auch mit diesen Fragen konfrontiert bist, dann findest du hier hilfreiche Einsichten, die ich über die Jahre erlangt habe, um diese Fragen zu beantworten.

Frage #1: Sollen Designaktivitäten nicht einen Sprint vor der Entwicklungsarbeit stattfinden?

In einem Baby-Wasserfall wäre dies vermutlich so.

Die Idee, dass Design- und Validierungsaktivitäten einen Sprint vor der Entwicklung stattfinden sollen, wurde 2007 von Desiree Sy und Lynn Miller publiziert. Mit ihrer Arbeit „Adapting Usability Investigations for Agile User-centered Design”, die im Journal of Usability Studies erschien, haben sie den Grundstein gelegt, UX-Techniken und agile Softwareentwicklung zu kombinieren.

Heute, 15 Jahre später, wissen wir, dass dieses Vorgehen immer noch viele der Nachteile mit sich bringt, die wir bereits aus einer wasserfallartigen Entwicklungsvorgehen kennen. Wenn Designer und Softwareentwickler nicht gleichzeitig an denselben Dingen arbeiten, kommt es zu Missverständnissen, unnötiger Dokumentation und langwierigen Änderungsprozessen. Um diese Verschwendung von Arbeitszeit zu eliminieren, sollten UX-Experten und Entwickler gemeinsam an den gleichen Themen arbeiten. In meinem Professional Scrum mit UX-Training kommt jetzt immer der Einwurf:

„Das ist aber nicht effizient!”

Wenn der einzige Maßstab von Effizienz ist, dass Programmierer zu 100 % programmieren, Designer zu 100 % designen und Tester zu 100 % testen, dann gebe ich den Teilnehmern recht, dass dieses Vorgehen wie Verschwendung scheint. Allerdings ist aus meiner Sicht Auslastung nie das Ziel, sondern Durchsatz! Es geht nicht darum, wie beschäftigt jeder Mitarbeiter ist, sondern wie häufig Teams neue Versionen des Produkts ihren Kunden bereitstellen, um zu validieren, was sie begeistert und was nicht.

Auch wenn unter diesem Gesichtspunkt die enge Zusammenarbeit von UX-Professionals und Entwicklern der einzige sinnvolle Weg ist, bedeutet das nicht, dass diese Tatsache jeder sofort einsieht. Wenn ich mit Teams und Designern zusammenarbeite, versuche ich deshalb immer, zuerst einen gemeinsamen Nenner zu finden. Dieser lautet:

Jeder möchte doch gute Arbeit leisten.

Was bedeutet gute Arbeit? Die Herausforderung, vor der viele Unternehmen stehen, ist, dass mit der Einführung von Scrum sich auch die Arbeitsweise verändern muss. Agilität bedeutet eben nicht, die gleiche Arbeit einfach schneller zu machen, um sie in Sprints pressen zu können. Die Arbeitsweise muss sich anpassen. Im Fall von Softwareentwicklung bedeutet diese, Features in viele kleine Scheiben zu schneiden. Was dann bedeutet, dass die Architektur und die Testabdeckung Stück für Stück mitwächst und somit immer wieder angepasst und verändert werden muss. Auch die Arbeitsweise von Designern muss sich entsprechend anpassen. Bei Teams, die erfolgreich UX-Expertise und Scrum vereinen konnten, habe ich beobachtet, dass Designer weniger designt haben, sondern mehr den Designprozess facilitiert haben. Etwa haben diese Designer häufiger UI-Sketches am Whiteboard mit Entwicklern skizziert, als in Figma über Tage umfangreiche Designs zu erstellen.

Zusammenfassenden würde ich sagen, dass die Mitglieder in wirklich erfolgreichen Scrum Teams eines gemeinsam haben: Sie sind in der Lage, zurückzutreten und sich zu fragen, wie viel wirklich nötig ist, um gute Arbeit zu leisten.

Frage #2: Gilt die Definition of Done auch für die Entdeckungsarbeit?

Laut dem Scrum Guide muss jeder Product-Backlog-Eintrag, der Teil des Inkrements ist, die Definition of Done erfüllen.

Im Scrum Guide steht nirgends geschrieben, dass jede Arbeit, die das Team erledigt, erst fertiggestellt ist, wenn sie die Definition of Done erfüllt. Dies wäre doch sehr dogmatisch.

Und Dogmas können schnell zum Hindernis werden.

Die revolutionäre Einsicht, die hinter der Definition of Done steht, ist, dass es einen minimalen Standard benötigt, der beschreibt, wann eine neue Version des Produkts zum Release bereit ist. Nur wenn jeder im Unternehmen weiß, was es bedeutet, dass ein Produktinkrement von den Nutzern verwendet werden kann, ist der Zustand des Produkts wirklich transparent. So bleiben die Qualitätsansprüche des Unternehmens an das Produkt gewahrt und das Renommee wird nicht durch schlechte Qualität in Mitleidenschaft gezogen.

Aus dem Blickwinkel von User Experience ist der Zustand „potenziell auslieferbar“ eher weniger interessant. Wir interessieren uns hier für den Zustand „validiert”. Wurde die intuitive Nutzbarkeit des UI-Designs von möglichen Nutzern bestätigt oder wurde die Nützlichkeit eines Features von Nutzern validiert? Wir sehen, dass „Done” aus der Sicht von Scrum und der Sicht von UX zwei ziemlich unterschiedliche Konzepte sein können. „Done” in Scrum bedeutet auslieferbar und „Done” in UX bedeutet validiert.

Der goldene Standard für Scrum bleibt aber auslieferbar.

Mit den Teams, mit denen ich in der Vergangenheit zusammengearbeitet habe, haben sich daraus zwei erfolgreiche Arbeitsweisen etabliert, wie sie mit reiner Entdeckungsarbeit im Backlog umgegangen sind:

• Sie haben die fertiggestellten Product-Backlog-Einträge bereits im laufenden Sprint validiert. Durch frühzeitige Releases im Sprint und Sprints, die länger als 2 Wochen waren, wurde dies möglich. „Done” bedeutet dann auch „validiert”.
• Die Validierungsarbeiten wurden von UX-Experten und Product Owner übernommen, nachdem die Software in Produktion war. „Done” bedeutet hier „auslieferbar”.

Am Ende sollten wir nie vergessen: Als Professional Scrum Master wollen wir Brücken zu UX-Professionals bauen, da sowohl Scrum als auch UX das gleiche Ziel verfolgen:

Empirisches Lernen über die Nutzung und den Wert des Produkts ermöglichen.

Frage #3: Was soll ich machen, wenn es keinen dedizierten Designer für unser Team gibt?

Du musst drei Einsichten haben, um diese Frage zu beantworten:

1. Weder Scrum noch Lean UX werden dieses Problem lösen können. Kein Prozess kann das. Nur das Einstellen von mehr UX-Experten wird dieses Problem lösen.
2. Mit oder ohne Designer, das Team wird designen.

   Ich habe mit einem Scrum Team gearbeitet, was Services für andere Teams im Unternehmen entwickelt und bereitgestellt hat. Das Produkt waren also APIs und die Dokumentation dieser Schnittstellen. Die Anwender dieses Produkts waren andere Softwareentwickler. Und diese Schnittstellen mussten so designt werden, dass sie für diese Entwickler einfach und intuitiv nutzbar waren. Um eine gute User Experience zu bieten, wurden Umfragen und Interviews mit Entwicklern der anderen Teams gemacht, wie sie aktuell andere Services einbinden. Es wurden Sketches erstellt, welche Attribute die Interfaces benötigen. Die Entwickler wurden geschult, wie sie die APIs am einfachsten verwenden können. Alles Dinge, die ich auch bei UX-Designern in Teams beobachten konnten, die etwa ein Online-Portal für Arbeitssuchende oder eine Versicherungsplattform für Makler designt haben.

3. Die Designer-Rolle wird sich ändern.

   Laut Josh Seiden, Co-Autor von Lean UX, wurde vor 10 Jahren von keinem UX-Generalisten erwartet, dass er Frontend-Entwicklung beherrscht. Heute findet man das in jeder Stellenbeschreibung. Wir dürfen nicht vergessen, dass sich die Erwartung an den Service und die Bedienbarkeit, die Produkte bieten müssen, sich immer schneller wandelt. Leider ist Perfektion häufig das Gegenteil von Fortschritt. Gewiss ist User Research weit mehr als mit Leuten zu sprechen. Allerdings genügt es anfänglich eben genau diese Fähigkeit in Teams zu entwickeln, damit sie wieder Fortschritte erzielen. Natürlich hat dieses Vorgehen seine Grenzen. Es ist und bleibt ein Unterschied, ob wir eine Shopping Card für einen Online-Store designen oder Bedienelemente im Cockpit eines Flugzeugs.

   Der springende Punkt ist: Dein Team wird designen und wenn keine dedizierten Designer zur Verfügung stehen, dann sollte der erste Schritt sein, Scrum Teams zu helfen, grundlegende UX-Fähigkeiten zu erlangen, um weiterhin ihre Kunden mit nützlicher Software zu begeistern.

Frage #4: Sind reine „Lern-Sprint” in Scrum erlaubt?

Jeff Gothelf, Co-Autor von Lean UX, sagt, dass agile Teams reine Lern-Sprints haben können.

Mit Lern-Sprint meint er Sprints, in denen keine neue Version des Produkts bereitgestellt wird, die die Definition of Done erfüllt. Ich widerspreche Jeff hier. Für Scrum Teams ist jegliche Form von Architektur-Sprints, Sprint 0 oder Design-Sprints ein Risiko, welches sie nicht eingehen wollen.

Warum ist Scrum in den letzten Jahren so populär geworden?

Weil es funktioniert. Was meine ich damit? Scrum funktioniert, da es die beste Möglichkeit ist, die ich kenne, bei komplexen Projektvorhaben oder Produktentwicklungen das Risiko zu minimieren. Mit Risiko meine ich: Ist die Lösung technisch machbar, das Produkt verwendbar, erweist es sich als wertvoll für die Nutzer und als rentabel für das Unternehmen? Dieses Risiko kann nur dadurch eliminiert werden, wenn das Scrum Team am Ende des Sprints etwas ausliefert. Nur das Inkrement stellt die wahre Transparenz her, die nötig ist, um empirische Entscheidungen zu treffen, die den Wert maximieren. Und darum geht es doch im Produktmanagement.  

Ist das nicht auch dogmatisch?

Nein. Ich behauptet nicht, dass Scrum Teams ihre ganze Kapazität verwenden müssen, um ein möglichst umfangreiches Inkrement zu liefern. Ich meine, dass mindestens etwas Auslieferbares am Ende des Sprints bereitstehen muss, aber durchaus ein großer Teil der Arbeitszeit in Lernen investiert werden kann.

Ich bezeichne dieses Vorgehen als emergentes UX.

Ein Team balanciert Entdeckungs- und Lieferarbeit innerhalb eines Sprints. Beide Arten von Arbeiten befinden sich in einem Product Backlog, werden von einem interdisziplinären Team erledigt und ein Product Owner priorisiert lernen und liefern.

Scrum Teams, die so agieren, legen damit die Grundlage für lernende Organisation.