Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/8 33 82-0

SCRUM ist nicht rosa Glitzer?

In einer rosa Glitzer-UX-Welt entstehen die Anforderungen an das spätere System oder Produkt nicht allein durch den Productowner, sondern kommen von tatsächlichen Benutzern. In dieser rosa Glitzer-UX-Welt entstehen Mockups, Skribbles, Klickdummies und Papier-Prototypen, die eine gemeinsame Produktvision schaffen, ohne auch nur eine Codezeile dafür programmieren zu müssen.
In unserer rosa Glitzer-UX-Welt dreht sich alles um den Nutzer.
Aus UX-Sicht zeige ich, wie wir UX-Experten unseren Platz in der grauen Entwickler-geprägten SCRUM-Welt zurückerobern und welche geheimen Werkzeuge SCRUM dafür schon bereithält – wir müssen sie nur nutzen!
Lassen wir es glitzern!

Wenn ich mit SCRUM zu tun hatte, dann

UX Experte ist traurigwurde ich grundsätzlich zu spät dazu geholt,

konnte mir niemand Fragen zur Zielgruppe und Produktvision beantworten,

war das Produkt schon soweit fertig, funktional alles super, nur bedienen konnte es keiner,

sollte ich es im Grunde nur bunt machen.

Warum? Weil WIR nicht im SCRUM vorhanden sind. Oder doch?

Design ist nicht im SCRUM verankertUsabilitytests sind nicht im SCRUM verankert

Usability und Design sind im SCRUM, so wie es die meisten Firmen leben, nicht verankert. Soll zum Beispiel eine über Jahre hinweg entstandene Software grundsätzlich neu gestaltet werden (Designrefacturing), weiß keiner so richtig wie er im SCRUM-Prozess damit umgehen soll. Auch Usabilitytests, idealerweise mit echten Nutzern, sind im SCRUM nicht eingeplant.

Bisher läuft es so ab:

bisher-läuft-scrum-so-ab

Der Productowner (PO) denkt sich vielleicht unter der Dusche eine Userstory aus, die den Nutzer vermeintlich weiterbringt. Diese kippt er ins Backlog, irgendwann wird sie entwickelt und der Kunde ist mäßig begeistert, weil er sich das irgendwie anders vorgestellt hatte.

Stell Dir vor … bild im kopf

Lesen wir eine Userstory, hat jeder sofort seine eigene Vorstellung davon, wie es aussehen und funktionieren soll. Mehr oder weniger pragmatisch und eher fantasielos. Dass sich diese Vorstellung nicht gleichen merkt man meist erst, wenn die Story umgesetzt ist und im Review vorgestellt wird.

verschiedene-Ziele

Auch verfolgt jeder seine eigenen Ziele. Der Productowner verfolgt seine Technikziele, der Kunde seine Businessziele. Aber wo bleibt der Mensch? Der spätere Nutzer des Ganzen? Wer kümmert sich um seine Ziele?

Es ist also kein Wunder, dass

deutsche Unternehmen jedes Jahr 15 Millionen Euro in die Realisierung ihrer Softwareideen stecken um ihr Unternehmen voranzubringen, neue Zielgruppen zu erreichen und Arbeitsprozesse zu erleichtern bzw. zu automatisieren …

… dabei 45% der Unternehmen ihr Budget überschreiten,
… 56% ihre geplanten Ziele nicht erreichen,

weil die Projekte keinen klaren Focus haben und der konkrete Nutzen nie formuliert wurde.

Quelle: BITKOM, 2014: http://www.bitkom.org/de/themen/54926_55506.aspx
Buchempfehlung: The digital Innovation Model – Software planen, die Nutzer lieben

Dabei bedarf es nur 2er Fragen:

Was sind die Businessziele?

Was sind die Interessen der Nutzer?

Und hier kommen wir ins Spiel.

User Centered Design Prozess - Alle Stakeholder sind glücklich mit der Lösung

Es braucht einfach UX Experten um Software oder Produkte zu entwickeln, die Nutzer lieben. Wir kümmern uns um den Menschen und stellen ihn in den Mittelpunkt unserer Bemühungen.

Praktisch gibt es 2 Möglichkeiten uns ins SCRUM-Team einzubinden:

Wir sind fest im SCRUM-Team verankert:

minusWir haben manchmal wenig oder gar nichts zu tun, je nach dem welche Userstory
gerade umgesetzt wird.

plusWir sind immer auf dem Laufenden, können jederzeit befragt werden und decken einen wichtigen Teil in der Evaluierung und Gestaltung ab.

Wir werden bei Bedarf dazu geholt:

minusWir müssen zum Thema ständig aufgeschlaut werden und sind so nicht permanent
auf dem Stand des Teams

minusDer UX Bedarf wird vom PO / Kunden / Team nicht erkannt und der UXler selbst
kann nicht auf sich aufmerksam machen, weil er nicht an den Dailys zum Beispiel
teilnimmt.

plusWir werden nur geholt, wenn auch wirklich Bedarf besteht (auch um die Businessziele zu erreichen ;o)

Sprint 0

Bevor nun das „Hamsterrad“ für die Entwickler anläuft, laufen wir los und befragen echte Nutzer!

Wir hinterfragen: Wer sind die echten Nutzer? Wo stehen sie jetzt? Was machen sie täglich? In welchem Umfeld arbeiten Sie? Was behindert sie bei ihren Aufgaben? Was unterstützt sie dabei? Was sind ihre Bedürfnisse? Was möchten sie eigentlich tun?

Die Menschen dabei zu beobachten, wie sie täglich ihre Aufgaben erfüllen ist unheimlich spannend. Begleiten wir sie ein Stück durch ihren Alltag, stellen offene Fragen warum sie das ein oder andere machen, was für sie an der Stelle angenehmer wäre und welches Ziel sie damit verfolgen. Kommen wir zurück mit einem bunten Strauß an Eindrücken echter Nutzer und schauen, welche Probleme, Bedürfnisse und Ziele sich häufen. So finden wir heraus, wer unsere Hauptzielgruppe ist, wen wir also als erstes glücklich machen müssen.

Aus der Nutzungskontextanalyse wird eine Primärpersona geboren – also einen Vertreter der Hauptzielgruppe.

Hallo Paul!

Paul ist jetzt unser wichtigster Mann im Team. Unsere Primärpersona.
Alle schauen durch seine Brille auf das zu entwickelnde Produkt. Durch Paul, mit all seinen Eigenschaften, Bedürfnissen, Problemen und Zielen, lernt der Productowner und auch das ganze Team die Zielgruppe, für die entwickelt wird, viel besser kennen. Sie können sich leicht in Pauls Lage hineinversetzen, nehmen ihn als Teammitglied auf und hinterfragen immer wieder: Versteht Paul das Feature? Kommt Paul damit zurecht? Benötigt Paul dieses und jenes?

us_kreislauf

Die gesammelten Nutzungsanforderungen von Paul konsolidieren wir und gießen sie in Sätze wie: Paul soll vom System dabei unterstützt werden, seine Profildaten zu ändern. Unsere gesammlelten Anforderungen erzählen wir dem Productowner und unterstützen ihn so dabei, Paul-zentrierte Userstories zu schreiben.

Dabei ist unsere Aufgabe unter anderem auf die Diaglogprinzipien zu achten!

  • Aufgabenangemessenheit
  • Selbstbeschreibungsfähigkeit
  • Erwartungskonformität
  • Lernförderlichkeit
  • Individualisierbarkeit
  • Fehlertoleranz
  • Steuerbarkeit

Als schnellen Abgleich, ob wir eine nutzerzentrierte Lösung geschaffen haben, eignen sich gerade auch für Entwickler diese 10 Heuristiken:

  1. Liefere Feedback!
  2. Sprich die Sprache der Benutzer!
  3. Stelle klar markierte Ausgänge zur Verfügung!
  4. Sei konsistent!
  5. Verhüte Fehler!
  6. Minimiere die „Gedächtnislast“ der Benutzer!
  7. Stelle Abkürzungen zur Verfügung!
  8. Stelle einen einfachen und natürlichen Dialog her!
  9. Liefere gute Fehlermeldungen! Defensiv, präzise und konstruktiv.
  10. Liefere Hilfe und Dokumentationen!

Keine Userstory ohne Mockup, Schätzelein!

User Centered Design Prozess - Mockups entstehenWie oben schon erwähnt, brauchen wir ein einheitliches Bild im Kopf. Im SCRUM-Prozess bedeutet dies, wir erstellen zu jeder Userstory ein Mockup oder Clickdummy, je nachdem wie umfangreich diese ist. Anhand von Mockups, also verbildlichten Sätzen, lässt sich nun viel besser darüber diskutieren und schätzen, wie und in welchem Ausmaß die Umsetzung erfolgen wird. Hier wird die Machbarkeit geprüft und Ideen gesponnen, wie wir Paul mit unserer Lösung noch glücklicher machen können.

<b> Immer noch kein Code … </b>

Da wir erst zufrieden sind, wenn Paul es ist, machen wir anhand unserer Mockups oder Klickdummys Usabilitytests. Das ist effizient, effektiv und einfach – ohne Code.
Nehmt hier gern die Stakeholder und Entwickler dazu. Als stumme, und für Paul unsichtbare Zuschauer, erfahren sie wie Paul tickt, wo er sich Fragen stellt, wie er mit der Software oder dem Produkt umgeht und wo er vielleicht verzweifelt. Echte Nutzer bei der Nutzung zu Beobachten ist Gold wert! Nutzt also die Möglichkeit und bindet Euer Team in die Evaluierung mit ein!

Guck an, der User Centered Design Prozess

ucd

Wir haben also erfolgreich den User Center Design Prozess durchlaufen. Wir haben geschaut wer unsere Zielgruppe am besten vertritt, wessen Bedürfnisse wir als erstes befriedigen müssen, damit das Produkt oder die Software vom Nutzer akzeptiert wird.
Wir haben die Nutzungsanforderungen in Userstories gegossen und daraus Mockups erstellt, damit alle im Team das gleiche Bild vor Augen haben. Die Mockups wurden getestet und verbessert, bis Paul damit zufrieden war. Und dies alles fand VOR dem ersten Entwicklungssprint statt!ucd_im_sprint
Genau dasselbe findet nun auch innerhalb der Sprints statt. Jeder evaluierbare Teil der Software wird nun mit Paul unter die Lupe genommen, sein Feedback dazu eingeholt, als Anforderung an den PO gegeben, dieser erstellt dazu Userstories, wir visualisieren diese als Mockup oder gleich am System selbst und es wird wieder getestet.
Damit ist Paul glücklich und unser Kunde auch.

Zeitlich läuft es also so ab:

  • Es wird ein vorgelagerter Sprint eingeplant. Auch Investigation Sprint oder Discovery Sprint genannt, in dem konkrete Nutzeranforderungen eingeholt werden, Mockups erstellt und diese getestet werden.
  • Wir UX-Experten arbeitet voraus und parallel zu den eigentlichen Sprints
  • Es gibt Quality-Gates, in denen eine Evaluierung mit den Nutzern stattgefunden haben muss! Nach einer bestimmten Zeit, wo schon die spätere Software als solche erkennbar und rudimentär bedienbar ist, müssen Nutzer dazugeholt werden, deren Feedback in Form von Userstories ins Backlog fließt .
  • Der Productowner muss in der Lage sein bzw. holt sich UX-Experten ins Team, die Userstories auf Usability, Machbarkeit, Look&Feel, Nützlichkeit und Sinnhaftigkeit zu prüfen, bevor programmiert wird
  • Es werden Sprintpausen eingelegt, in denen die Entwickler mit an einer Idee feilen können, ohne dass sie in der Zeit programmieren. Sie werden schon beim SCRUM-Poker durch weniger Story-Points eingeplant, dass sie für andere evaluierende Aufgaben zur Verfügung stehen.

Und das Beste ist …

All diese Dinge gibt es bereits im SCRUM-Prozess. Sie werden nur von den wenigsten Firmen genutzt.

Wenn ihr also zukünftig nicht zu DER HÄLFTE der deutschen Unternehmen zählen wollt, welche die geplanten Ziele neuer Software nicht erreicht, dann

1.nehmt euch UX-Experten permanent mit ins Team
2.investiert Zeit und Geld in einen vorgelagerten Sprint
3.entwickelt nutzerzentriert für Paul.

Dann sehen wir auch das rosa Glitzern in den Augen der Kunden die unsere Software lieben!

 

Tipps zum Schluss:

Sehr lesenswerter Blogartikel von Jan Pohlmann zu Agile UX: Die Zusammenarbeit von UX-Agentur und Kunde muss sich ändern

Noch mehr Argumente von Mischa Korn für UXler im Unternehmen: Warum jedes Unternehmen einen UX-Experten benötigt

„Ich kann nicht zeichnen“ ist jetzt keine Ausrede mehr! Bei echtpraktisch.ch gibt es tolle Workshops wie man seine Bilder im Kopf zu Papier bringt.

Kreative Visualisierung + Prozessvisualisierung lernen im Workshop – bei Stift & Seil in Berlin

 

 

Related Posts

Kommentar hinterlassen


Pin It on Pinterest