Smidig metodikk er spennende og veldig i vinden om dagen. Spesielt Scrum er populært. Det er sannsynlig at interaktive designere før eller siden vil komme bort i metodikken og jobbe med utviklere som jobber smidig. Smidig-tankesettet er forlokkende fordi det er i tråd med det brukerorientert design ønsker: tett kommunikasjon, kundeinvolvering og mulighet til å ta hensyn til endringer (se Smidig-manifestet). Men det første spørsmålet designere lurer på er: Hvor i all verden passer jeg inn i denne metodikken?

Her presenterer jeg tre modeller på organiseringer vi har sett og jobbet etter. Jeg bruker Scrum som eksempel siden det er det jeg har erfaring med, men modellene kan også generaliseres og brukes på andre metodikker.

I figurene betyr “PO” Product Owner (produkteier) og UX betyr User eXperience (designer).

Modell 1: Designer i utviklingsteam

De fleste designere kommer inn i et IT-prosjekt samtidig som utviklerne og det er da lett å tenke at designeren også skal jobbe i teamet sammen med utviklerne.

Fordeler:

• Sitter nært til utviklerne

Det at designeren sitter nært utviklerne gjør det lettere å samarbeid og man kan få til arbeidsprosesser der utviklerne spør mens de jobber. Da klarer man opp misforståelser og man kan løse ting designeren ikke har tenkt på. Kvaliteten på det implementerte kan dermed øke og man får lettere godt samarbeidsklima siden man sitter i samme båt.

Ulemper:

• Scrum er laget for og av utviklere. Det finnes ingen naturlig plass for en designer
• Designoppgaver kan være vanskelig å bryte ned i oppgaver/gule lapper innenfor en sprint
• Svært ressurskrevende

Mange av seremoniene i Scrum egner seg kun for de som jobber med de tekniske delene av prosjektet. Er det hensiktsmessig for en designer å være med på planning poker og estimere story points?

Mange designoppgaver går over lenger tid enn en sprint (avhengig av hvor lang sprinten er). Det kan også være vanskelig å si når noen av oppgavene kan anses som ferdig. Hva er f.eks. definisjonen av “ferdig” for overordnet konsept eller for navigasjonsmodell?

Denne modellen er ressurskrevende. I følge Scrum skal alle som er med i scrum-teamet være 100% i prosjektet og skjermet fra andre forstyrrelser. Min erfaring tilsier at designere ofte er involvert i flere prosjekter samtidig. I tillegg er det ofte manko på designere i IT-prosjekter generelt.

Modell 2: Designer(e) i ressurs-pool

Designerne sitter sammen i et team og fungerer som rådgivere inn mot prosjektene. Designerne er her ikke en del av de faktiske prosjektene og gir kun råd og føringer, de er dermed ikke tett inne på problemstillingene.

Fordeler:

• Designere kan sitte i eget team
• Mer tilgjengelig for flere projekter
• Kan løse ressursproblemer (designere er gjerne i manko)

Det at designerne sitter i eget team gjør at det lettere for designerne ha gode sparringpartnere, noe som bør øke kvaliteten på design. Det er også en fordel dersom du prøver å innføre felles designpatterns på tvers av systemporteføljen din eller du ønsker å konsistens i design og brukergrensesnitt i flere prosjekter.

Ved å ha rådgivende designere kan du i teorien ha en mer fleksibel oppbygning som gjør det lettere å sette inn designressurser der de trengs. Dette gjør seg spesielt gjeldende dersom du har mange prosjekter som kjører og få tilgjengelige designere.

Ulemper:

• For langt unna prosjektet
• Blir rådført for lite og for sent
• Skaper lettere “oss” og “dem” følelse

Den klart største ulempen med denne modellen er at designerne ikke sitter i prosjektet, noe som gjør at de ikke kommer godt nok inn i problemstillingene. De kan dermed kun hjelpe til med enkle problemstillinger.

En annen konsekvens av å være utenfor prosjektet er at de ikke blir rådført like mye som de hadde blitt gjort om de var en del av prosjektet. Dette henger sammen med at det finnes færre naturlige arenaer for kommunikasjon. Når designerne først kommer inn blir det lett mye kritikk, og da kommer kritikken som oftest etter at sprinten er ferdig og deler allerede er implementert.

Modell 3: Designer utenfor team

Fordeler:

• Tilpasset Scrum
• Nære teamet
• Støtter primært produkteier (som virker mer naturlig?)

I denne modellen deltar designeren kun i de Scrum-seremoniene som er hensiktsmessige for han og der han kan bidra ut i fra rollen han har, dvs at modellen er tilpasset til Scrum.

Designeren sitter fortsatt nærme teamet, men fokus er på å støtte de med funksjonelt ansvar og fungere som brobygger mellom produkteier og teamet.

Ulemper:

• Ressurskrevende (men åpner for at designer kan delta i flere prosjekter)

Konklusjon

Så hvilken modell skal du velge? Det spørs på flere faktorer, blant annet hva du ønsker å løse og om du har tilgang til nok designressurser, eventuelt hva du har råd til å leie inn.

Dersom ressursene er knappe

Om du har få ressurser mener jeg at modell 2 er bedre enn ingenting. Men vær klar over at nytten er begrenset siden designeren får liten reell mulighet til å sette seg inn i problemstillingen eller lære sammen med resten av teamet. Designeren får også liten påvirkningskraft.

Dersom UX-personen også jobber med utvikling

Modell 1 egner seg godt dersom den som har ansvaret for brukeropplevelsen også jobber med utvikling (husk at den som har ansvaret for brukeropplevelsen ikke trenger å være en designer). Om du er så heldig å ha en dyktig front-end utvikler på teamet er det ingenting i veien for å be denne personen ta ansvar for brukeropplevelsen.

Dersom designer ikke er 100% tilgjenglig, men du ønsker maks påvirkningskraft

Personlig forerekker jeg modell 3 — designer utenfor teamet. Dette er den modellen som har fungert best for meg. Designeren kan jobbe svært tett med produkteier og de kan sammen spesifisere løsninger og presentere disse for teamet. Dette er også en modell som gjør det mulig for designeren å bruke tiden sin maksimalt ved kun å delta på de Scrum-seremoniene som er hensiktsmessige for hans rolle.

Uansett kommer du ikke unna at både vi som er designere og de som er utviklere må tilpasse Scrum-metodikken for at vi skal jobbe bedre sammen. Målet er det samme for begge grupper: Lage bedre løsninger for brukerne.

Har du noen erfaringer eller forslag til andre modeller? Kom med dem i kommentarene!

PS. 25. februar skal Dataforeningen ved faggruppene BITS og EPU holde et medlemsmøte om dette temaet. Tre erfarne designere og tre erfarne scrummasters/utviklere kommer og deler sine erfaringer. Målet er at alle skal kunne gå hjem med seks gode forslag til hvordan vi kan jobbe bedre sammen. Bli med!

(Oppdatert 3.2 etter tilbakemeldinger fra deltakere på XP meetup).

Fra Smidig 2008, UGDD av Daniel Brolund (Agical AB)

Bildet viser en fantastisk slide fra årets smidig2008 konferanse av Daniel Brolund fra Agical AB.

Denne problemstillingen sliter mange med. Det å lage kode med smidige metoder som Scrum, bruke teknikker som BDD, continuous integration og continous deployment er ikke på noen måte en garanti for at det du lager blir brukervennlig. Scrum er en meget god gjennomføringsmetode som takler noen av de største problemene med IT prosjekter som f.eks. kommunikasjon. Men metoden er beviselig mangelfull i å sikre at selve produktet, og ikke bare koden har en stor verdi for den som skal utføre faktiske oppgaver på systemet.

Bob Martin sier at det smidige manifest mangler en femte linje: Craftmanship over crap. Interaksjonsdesigner og forfatter Alan Cooper har et bedre forslag for et tillegg til manifestet, som går på produktkvalitet:
“Responsible craftsmanship over features and functions.”
- While there is value in the latter, we value the former more.

Det er ikke en dum tanke. Det å måle kvalitet i grønne lys, fungerende kode, storypoints levert osv vil aldri bli en garanti for kvalitet. Som jeg sa i min lyntale på smidig2008 så er det utviklerne som har størst påvirkning på brukeropplevelsen og det er på tide at disse kloke menneskene retter sine blikk mot brukskvalitet – Det burde ikke lyse grønt før brukertesten er en positiv opplevelse.

Følg diskusjonen på Alan Coopers blog:
http://www.cooper.com/journal/2008/09/uncle_bob.html

Dette og mye annet spennende kan du høre mer om på årets smidigkonferanse 9 og 10 oktober!

Når jeg jobbet i FINN.no var det ofte behov for avsjekk med brukere underveis. Vi måtte ha svar der og da. I smidige prosjekter har man sjelden tid til omfattende brukertester og denne metoden ble brukt en del etter at vi så nytten av å vise det vi laget til folk – hvem som helst – og observere.

Ordet Gonzo er stjålet fra journalist og forfatter Hunter S. Thompson som praktiserte det han kalte Gonzojournalistikk, at man selv måtte oppleve det man skrev om. Det er dårlig business å være sin egen testbruker, men siden man oppsøker brukerne der de er fremfor å kalle dem inn syntes jeg dette var et passende navn.