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

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 grund­sätz­lich zu spät dazu geholt,

konnte mir nie­mand Fragen zur Zielgruppe und Produktvision beant­wor­ten,

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

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 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 ein­ge­plant.

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 auto­ma­ti­sie­ren …

… 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 digi­tal Innovation Model – Software pla­nen, die Nutzer lie­ben

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 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 ein­zu­bin­den:

Wir sind fest im SCRUM-Team ver­an­kert:

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 per­ma­nent
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
teil­nimmt.

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üs­sen.

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 schrei­ben.

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 kon­struk­tiv.
  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ön­nen.

<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 getes­tet.
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 wer­den.
  • 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 ste­hen.

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 lie­ben!

 

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