Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden

SCRUM ist nicht rosa Glitzer?

In einer rosa Glitzer-UX-Welt ent­ste­hen die Anforderungen an das spä­tere System oder Produkt nicht allein durch den Productowner, son­dern kom­men von tat­säch­li­chen Benutzern. In die­ser rosa Glitzer-UX-Welt ent­ste­hen Mockups, Skribbles, Klickdummies und Papier-Prototypen, die eine gemein­same Produktvision schaf­fen, ohne auch nur eine Codezeile dafür pro­gram­mie­ren zu müssen.
In unse­rer rosa Glitzer-UX-Welt dreht sich alles um den Nutzer.
Aus UX-Sicht zeige ich, wie wir UX-Experten unse­ren Platz in der grauen Entwickler-geprägten SCRUM-Welt zurück­er­obern und wel­che gehei­men Werkzeuge SCRUM dafür schon bereit­hält – wir müs­sen sie nur nutzen!
Lassen wir es glitzern!

Wenn ich mit SCRUM zu tun hatte, dann

UX Experte ist traurigwurde ich grund­sätz­lich zu spät dazu geholt,

konnte mir nie­mand Fragen zur Zielgruppe und Produktvision beantworten,

war das Produkt schon soweit fer­tig, funk­tio­nal alles super, nur bedie­nen konnte es keiner,

sollte ich es im Grunde nur bunt machen.

Warum? Weil WIR nicht im SCRUM vor­han­den sind. Oder doch?

Design ist nicht im SCRUM verankertUsabilitytests sind nicht im SCRUM verankert

Usability und Design sind im SCRUM, so wie es die meis­ten Firmen leben, nicht ver­an­kert. Soll zum Beispiel eine über Jahre hin­weg ent­stan­dene Software grund­sätz­lich neu gestal­tet wer­den (Designrefacturing), weiß kei­ner so rich­tig wie er im SCRUM-Prozess damit umge­hen soll. Auch Usabilitytests, idea­ler­weise mit ech­ten Nutzern, sind im SCRUM nicht eingeplant.

Bisher läuft es so ab:

bisher-läuft-scrum-so-ab

Der Productowner (PO) denkt sich viel­leicht unter der Dusche eine Userstory aus, die den Nutzer ver­meint­lich wei­ter­bringt. Diese kippt er ins Backlog, irgend­wann wird sie ent­wi­ckelt und der Kunde ist mäßig begeis­tert, weil er sich das irgend­wie anders vor­ge­stellt hatte.

Stell Dir vor … bild im kopf

Lesen wir eine Userstory, hat jeder sofort seine eigene Vorstellung davon, wie es aus­se­hen und funk­tio­nie­ren soll. Mehr oder weni­ger prag­ma­tisch und eher fan­ta­sie­los. Dass sich diese Vorstellung nicht glei­chen merkt man meist erst, wenn die Story umge­setzt ist und im Review vor­ge­stellt wird.

verschiedene-Ziele

Auch ver­folgt jeder seine eige­nen Ziele. Der Productowner ver­folgt seine Technikziele, der Kunde seine Businessziele. Aber wo bleibt der Mensch? Der spä­tere Nutzer des Ganzen? Wer küm­mert sich um seine Ziele?

Es ist also kein Wunder, dass

deut­sche Unternehmen jedes Jahr 15 Millionen Euro in die Realisierung ihrer Softwareideen ste­cken um ihr Unternehmen vor­an­zu­brin­gen, neue Zielgruppen zu errei­chen und Arbeitsprozesse zu erleich­tern bzw. zu automatisieren …

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

weil die Projekte kei­nen kla­ren Focus haben und der kon­krete Nutzen nie for­mu­liert wurde.

Quelle: BITKOM, 2014: http://www.bitkom.org/de/themen/54926_55506.aspx
Buchempfehlung: The digi­tal Innovation Model – Software pla­nen, die Nutzer lieben

Dabei bedarf es nur 2er Fragen:

Was sind die Businessziele?

Was sind die Interessen der Nutzer?

Und hier kom­men wir ins Spiel.

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

Es braucht ein­fach UX Experten um Software oder Produkte zu ent­wi­ckeln, die Nutzer lie­ben. Wir küm­mern uns um den Menschen und stel­len ihn in den Mittelpunkt unse­rer Bemühungen.

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

Wir sind fest im SCRUM-Team verankert:

minusWir haben manch­mal wenig oder gar nichts zu tun, je nach dem wel­che Userstory
gerade umge­setzt wird.

plusWir sind immer auf dem Laufenden, kön­nen jeder­zeit befragt wer­den und decken einen wich­ti­gen Teil in der Evaluierung und Gestaltung ab.

Wir wer­den bei Bedarf dazu geholt:

minusWir müs­sen zum Thema stän­dig auf­ge­schlaut wer­den 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 auf­merk­sam machen, weil er nicht an den Dailys zum Beispiel
teilnimmt.

plusWir wer­den nur geholt, wenn auch wirk­lich Bedarf besteht (auch um die Businessziele zu errei­chen ;o)

Sprint 0

Bevor nun das "Hamsterrad" für die Entwickler anläuft, lau­fen wir los und befra­gen echte Nutzer!

Wir hin­ter­fra­gen: Wer sind die ech­ten Nutzer? Wo ste­hen sie jetzt? Was machen sie täg­lich? In wel­chem Umfeld arbei­ten Sie? Was behin­dert sie bei ihren Aufgaben? Was unter­stützt sie dabei? Was sind ihre Bedürfnisse? Was möch­ten sie eigent­lich tun?

Die Menschen dabei zu beob­ach­ten, wie sie täg­lich ihre Aufgaben erfül­len ist unheim­lich span­nend. Begleiten wir sie ein Stück durch ihren Alltag, stel­len offene Fragen warum sie das ein oder andere machen, was für sie an der Stelle ange­neh­mer wäre und wel­ches Ziel sie damit ver­fol­gen. Kommen wir zurück mit einem bun­ten Strauß an Eindrücken ech­ter Nutzer und schauen, wel­che Probleme, Bedürfnisse und Ziele sich häu­fen. So fin­den wir her­aus, wer unsere Hauptzielgruppe ist, wen wir also als ers­tes glück­lich machen müssen.

Aus der Nutzungskontextanalyse wird eine Primärpersona gebo­ren – also einen Vertreter der Hauptzielgruppe.

Hallo Paul!

Paul ist jetzt unser wich­tigs­ter Mann im Team. Unsere Primärpersona.
Alle schauen durch seine Brille auf das zu ent­wi­ckelnde Produkt. Durch Paul, mit all sei­nen Eigenschaften, Bedürfnissen, Problemen und Zielen, lernt der Productowner und auch das ganze Team die Zielgruppe, für die ent­wi­ckelt wird, viel bes­ser ken­nen. Sie kön­nen sich leicht in Pauls Lage hin­ein­ver­set­zen, neh­men ihn als Teammitglied auf und hin­ter­fra­gen immer wie­der: Versteht Paul das Feature? Kommt Paul damit zurecht? Benötigt Paul die­ses und jenes?

us_kreislauf

Die gesam­mel­ten Nutzungsanforderungen von Paul kon­so­li­die­ren wir und gie­ßen sie in Sätze wie: Paul soll vom System dabei unter­stützt wer­den, seine Profildaten zu ändern. Unsere gesamm­lel­ten Anforderungen erzäh­len wir dem Productowner und unter­stüt­zen ihn so dabei, Paul-zentrierte Userstories zu schreiben.

Dabei ist unsere Aufgabe unter ande­rem auf die Diaglogprinzipien zu ach­ten!

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

Als schnel­len Abgleich, ob wir eine nut­zer­zen­trierte Lösung geschaf­fen haben, eig­nen sich gerade auch für Entwickler diese 10 Heuristiken:

  1. Liefere Feedback!
  2. Sprich die Sprache der Benutzer!
  3. Stelle klar mar­kierte Ausgänge zur Verfügung!
  4. Sei kon­sis­tent!
  5. Verhüte Fehler!
  6. Minimiere die „Gedächtnislast“ der Benutzer!
  7. Stelle Abkürzungen zur Verfügung!
  8. Stelle einen ein­fa­chen und natür­li­chen 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, brau­chen wir ein ein­heit­li­ches Bild im Kopf. Im SCRUM-Prozess bedeu­tet dies, wir erstel­len zu jeder Userstory ein Mockup oder Clickdummy, je nach­dem wie umfang­reich diese ist. Anhand von Mockups, also ver­bild­lich­ten Sätzen, lässt sich nun viel bes­ser dar­über dis­ku­tie­ren und schät­zen, wie und in wel­chem Ausmaß die Umsetzung erfol­gen wird. Hier wird die Machbarkeit geprüft und Ideen gespon­nen, wie wir Paul mit unse­rer Lösung noch glück­li­cher machen können.

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

Da wir erst zufrie­den sind, wenn Paul es ist, machen wir anhand unse­rer Mockups oder Klickdummys Usabilitytests. Das ist effi­zi­ent, effek­tiv und ein­fach – ohne Code.
Nehmt hier gern die Stakeholder und Entwickler dazu. Als stumme, und für Paul unsicht­bare Zuschauer, erfah­ren sie wie Paul tickt, wo er sich Fragen stellt, wie er mit der Software oder dem Produkt umgeht und wo er viel­leicht ver­zwei­felt. Echte Nutzer bei der Nutzung zu Beobachten ist Gold wert! Nutzt also die Möglichkeit und bin­det Euer Team in die Evaluierung mit ein!

Guck an, der User Centered Design Prozess

ucd

Wir haben also erfolg­reich den User Center Design Prozess durch­lau­fen. Wir haben geschaut wer unsere Zielgruppe am bes­ten ver­tritt, wes­sen Bedürfnisse wir als ers­tes befrie­di­gen müs­sen, damit das Produkt oder die Software vom Nutzer akzep­tiert wird.
Wir haben die Nutzungsanforderungen in Userstories gegos­sen und dar­aus Mockups erstellt, damit alle im Team das glei­che Bild vor Augen haben. Die Mockups wur­den getes­tet und ver­bes­sert, bis Paul damit zufrie­den war. Und dies alles fand VOR dem ers­ten Entwicklungssprint statt!ucd_im_sprint
Genau das­selbe fin­det nun auch inner­halb der Sprints statt. Jeder eva­lu­ier­bare Teil der Software wird nun mit Paul unter die Lupe genom­men, sein Feedback dazu ein­ge­holt, als Anforderung an den PO gege­ben, die­ser erstellt dazu Userstories, wir visua­li­sie­ren diese als Mockup oder gleich am System selbst und es wird wie­der getestet.
Damit ist Paul glück­lich und unser Kunde auch.

Zeitlich läuft es also so ab:

  • Es wird ein vor­ge­la­ger­ter Sprint ein­ge­plant. Auch Investigation Sprint oder Discovery Sprint genannt, in dem kon­krete Nutzeranforderungen ein­ge­holt wer­den, Mockups erstellt und diese getes­tet werden.
  • Wir UX-Experten arbei­tet vor­aus und par­al­lel zu den eigent­li­chen Sprints
  • Es gibt Quality-Gates, in denen eine Evaluierung mit den Nutzern statt­ge­fun­den haben muss! Nach einer bestimm­ten Zeit, wo schon die spä­tere Software als sol­che erkenn­bar und rudi­men­tär bedien­bar ist, müs­sen Nutzer dazu­ge­holt wer­den, 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 pro­gram­miert wird
  • Es wer­den Sprintpausen ein­ge­legt, in denen die Entwickler mit an einer Idee fei­len kön­nen, ohne dass sie in der Zeit pro­gram­mie­ren. Sie wer­den schon beim SCRUM-Poker durch weni­ger Story-Points ein­ge­plant, dass sie für andere eva­lu­ie­rende Aufgaben zur Verfügung stehen.

Und das Beste ist …

All diese Dinge gibt es bereits im SCRUM-Prozess. Sie wer­den nur von den wenigs­ten Firmen genutzt.

Wenn ihr also zukünf­tig nicht zu DER HÄLFTE der deut­schen Unternehmen zäh­len wollt, wel­che die geplan­ten Ziele neuer Software nicht erreicht, dann

1.nehmt euch UX-Experten per­ma­nent mit ins Team
2.investiert Zeit und Geld in einen vor­ge­la­ger­ten Sprint
3.entwickelt nut­zer­zen­triert für Paul.

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

 

Tipps zum Schluss:

Sehr lesens­wer­ter 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 zeich­nen" ist jetzt keine Ausrede mehr! Bei echtpraktisch.ch gibt es tolle Workshops wie man seine Bilder im Kopf zu Papier bringt.

Kreative Visualisierung + Prozessvisualisierung ler­nen im Workshop – bei Stift & Seil in Berlin

 

 

Related Posts

Pin It on Pinterest