Alle som jobber i et utviklingsprosjekt hvor kunden har et krav til at løsningen skal være brukervennlig mener eller opplever det samme; brukskvalitet passer ikke helt inn i sprinten.  Det er egentlig et paradoks for saken er den at brukersentrert designprosess  er som født til å passe inn i scrum-metoden. Brukersentrert design eller det å ta seg tid til å gjøre” ting” brukervennlig har i alle prosjekter, uansett metode, vært et problem. Det er en hemsko. Alle vil ha det, men få vil bruke tid eller rettere sagt betale for det. Akkurat som at alle vil ha et system som funker men å bruke tid på å teste (om utviklerne har gjort jobben sin?) er noe ofte blir nedprioritert. (Jeg forstår fremdeles ikke hvorfor utvikling og test ikke blir sett under ett. Jeg vil gjerne høre andres synspunkter på dette.)

Inkrementelt eller iterativt?

Harald påpeker helt korrekt at user storyene som står skrevet i produkt backloggen blir utviklet inkrementelt. Fordi man misoppfatter scrum sitt uttrykk med å levere ferdige deler eller user stories  for hver sprint fordi det står at i sprint reviewen skal produkteieren få: “Potentially shippable product increment”. Men hvis du har tenkt å kjøre et iterativt  utviklingsløp så kan det ikke være ferdig pakket og klart etter en sprint, eller hva?

Scrum deler inn scope i et x antall user stories. Deretter bestemmes det at x antall user stories skal være ferdig i en sprint. Det er her vi trår feil, etter min mening. En user story må brytes opp og utvikles bit for bit, hvor bitene er det som leveres “ferdig” i en sprint. En user story vil dermed leve over flere sprinter inntil kunden er fornøyd nok med resultatet.

Eksempel: Nytt intranet.  En user story i løsningen er: Jeg skal kunne skrive forskjellige typer saker og publisere dette på vårt intranett. Når er denne user storyen ferdig? Er det en user story eller kan denne brytes ned til to, tre, mer?

La oss si at det er en user story. Hva er da biten som skal ferdigstilles i sprint 1? Første bit er at det faktisk er mulig for kunden å opprette en side, skrive tekst, legge til et bilde og sende den ut på det fortsatt ikke-eksisterende intranettet.  Er ikke dette også å forvente som out-of-the-box? De resterende bitene før denne user storyen er ferdig vil være å legge på grafisk design, designe sidemalen med nødvendige metadata, definere content typen og etterhvert lage en struktur for hvor denne typen artikler skal “bo”. Muligheten for å publisere på flere språk og til målrette informasjon til brukergrupper kan være ekstra features som kan legges til senere i sprintløpene.  I mellomtiden får kunden mulighet til å teste ut hvordan dette fungerer og gi tilbakemelding på hva han savner i den påbegynte user storyen.

Brukersentrert design handler om å ha rom til å forbedre brukergrensesnittet i takt med brukers tilbakemeldinger.

Scrum ivaretar ikke helheten

“Vi må ha tid til å tenke på helheten! Få se hele bildet for å kunne lage et godt grafisk design og en god innholdsstruktur”, ropes det fra kanter som jeg kommer fra. “Dette går ikke på et sprintløp”, “Vi får aldri tid til å gå tilbake!” Det er ikke bare vi designere som roper her. Løsningsarkitektene er også en gruppe som roper. Men den som bør rope høyest er kunden. Hvorfor skal kunden sette i gang et sprintløp hvis han ikke vet hvor han skal løpe, eller hvorfor han skal løpe? Det er så typisk. Kunden er livredd for å kaste bort tid og penger og tenker at jo fortere jeg kommer i gang med løpingen, jo fortere blir jeg ferdig. Men ferdig med hva da? spør jeg da.

Det er ikke en regel eller et mantra i scrum som sier at kunden ikke skal ta seg tid til å få en oversikt over hva som skal lages og hvorfor det skal lages. Et hvert prosjekt er et tiltak som settes i gang for å støtte opp under forretningsvirksomheten. Derfor må det et forporsjekt til eller en sprint 0, for å kartlegge og analysere forretningsbehov (dersom det ennå ikke er utført før vi kommer inn), brukerbehov, lage ny designprofil, designe arkitekturen, lage et konsept.  Vi må skaffe oss en oversikt over hvilken retning vi bør begynne å løpe før vi setter i gang.

Gode user stories er alfa omega

Definisjonen av “ferdig” like så. Alle er enige om det, men hvordan få det til? Her er tre strategier:

1. John Sjef har fokus på hva som gir forretningsverdi. Definer forretningsmål. Han sier “Følg pengene!” Færre mål mindre utvikling.
2. Paul Sjef ønsker ikke å velge løsning for fort. Han ønsker å ha fokus på brukerne, og hva de ønsker å oppnå. “Følg brukerne. Ikke velg løsning for tidlig! ”Paul prioriterer etter hva som er viktigst for brukerne.
3. Roger Sjef har et problem. Det han trenger koster mer enn hva han har. Kan jeg ikke få alt på en gang får jeg starte på minste multiplum. Han trenger alle featurene på en gang, men er det nødvendig at alle har den kvaliteten han ønsker med en gang.  “Iterativ utvikling gir meg råd til å bygge kvalitet over tid.” Roger prioriterer på følgende måte:
   1. Hva er en nødvendighet?
   2. Kan featuren være nyttig i flere situasjoner (fleksibilitet)?
   3. Hva vil gjøre denne featuren sikrere i sin bruk (sikkerhet)?
   4. Hva vil gjøre denne featuren mer foretrukket å bruke (komfort, luksus og ytelse)?

Rigide strukturer og stand-up meetings

Jeg har fått prøve ut scrum i flere år nå og gjort en del erfaringer. Første gangen kjørte vi scrum etter boka med de teknikkene som scrum tilbyr, utviklingsløpet var som før, et prosjekt som var ment å være iterativt men som egentlig var tilnærmet fossefall. Det var en vond opplevelse. Spesielt fordi det var så vanskelig å forstå hvordan disse teknikkene skulle få oss raskere til målet og jobbe bedre sammen. De føltes mer som hindere, og skapte bekymringer. Vi hadde blant annet stand-up hver morgen med opptil 20 mennesker. Når dialogen var ferdig hadde vi brukt 45 min og hadde egentlig ikke fått kommunisert sammen. Vi hadde bare fått fram hvor gode vi var på å gjøre oppgavene våre, eller hvor tregt det gikk, og hvor vanskelig det var å si hvor mange timer som faktisk gjenstod.

Første gang jeg var med på en stand-up hadde jeg aldri hørt om scrum, og det er nok mange med meg som har gjort dette før scrum-tiden. Jeg jobbet i et lite selskap, som hadde få ansatte, men med mange forskjellige prosjekter. Vi hadde stand-up for å koordinere ressursinnsats og gi mulighet til å hjelpe hverandre. Hvem trengte bistand til hva og når, eller problemstillinger som hadde dukket opp og som det var ønskelig å drøfte med en eller flere for å finne en løsning. Vi hadde ingen oppgavelapper som ble flyttet på. Men vi skrev opp på en tavle når vi hadde nådd et mål for å synliggjøre for hverandre hvor flinke vi hadde vært. Og det er bra.

Scrum i utviklingsprosjekter vil føre til et resultat som vil matche kundens forretningsmål bedre enn ved en annen metode

Jeg kan ikke være den eneste som mener dette i dag. Scrum er blitt kjempepopulært, og har kastet tradisjonell iterativ utvikling på båten. Hvorfor? Fordi det er åpenbart en gevinst. Alle som har vært på scrum master- eller produkteierkurs har lært at man kommer raskere til målet ved hjelp av scrum.

En av grunnene til det er det tette samarbeidet teamet har underveis med å løse en oppgave i en begrenset periode. Kundens forpliktelser i å være tilstede i sprinten, være tydelig på hva han ønsker seg og gjøre prioritereringer. Løsningens kravspesifikasjon er også ny. Istedetfor detaljerte krav er det nå behov som er beskrevet.

Alle teamdeltagere jobber på de samme user storiene samtidig

En user story skal leve over flere sprinter og bygges sammen lag på lag til kunden er fornøyd med resultatet. Det er derfor man velger iterativ utvikling og ikke inkrementelt fordi man vet hvor man skal gå men ikke helt nøyaktig hvilken løsning som vil være den beste når man starter.

I inkrementel utvikling bygger vi en og en bit ferdig av gangen. Kilde: Jeff Patton.

I iterativ utvikling lager vi først rammeverket, eller en førsteutgave, validerer den og utvikler og legger til flere og flere features eller krav lag på lag. For hvert lag gjøres det en ny validering. Kilde: Jeff Patton.

Tilbake til eksempelet om intranettet. Når noen teammedlemmer setter opp og utvikler minimum av standardoppsettet for å kunne publisere en side, kan andre teammedlemmer begynne å detaljere design. I sprint reviewen er første lag av user storyen ferdig slik at kunden kan teste ut standardutgaven. I tillegg vil han ha skisser på ideer som han kan presentere og korrigere for teamet etter sine ønsker. Neste sprint vil da være å utvikle dette laget. “Men da jobber man jo et hestehode foran?” Ja, men fokuset må være på den samme user storyen. Jeg brukte også begrepet teammedlemmer bevisst fordi utviklere som venter på at noe skal skje skal inkluderes i workshopene hvor skissene blir tegnet. Om utvikleren er med vil det holde om skissene er på papir, utvikleren trenger ikke vente på (elektronisk) dokumentasjonen av detaljert design. Det kan være nødvendig for å kjøre brukertest på papir og avstemme med kundens behov. Man utvikler ikke mer enn det som er bestemt og akkurat nødvendig.

En sprint kan variere i tid fra 2, 3 eller 4 uker. Teamet vil rekke å begynne på flere user stories når sprinten varer i 4 uker fremfor 2. Men et viktig poeng her er at ved 4 uker må man ikke la seg forlede til å tro at da rekker vi å levere et tjukkere lag av user storyen, ja rett og slett bli fullstendig ferdig. Hvor blir det av den iterative utviklingen da?

Er brukskvalitet i scrum vanskelig? Nei, det er ikke det . Det er ikke brukskvalitets sine oppgaver som forsinker prosessen, det er å gjennomføre utviklingen iterativt som er vanskelig, fordi kunden er forledet til å tro at han får løsningen fullstendig ferdig bit for bit, og ikke en løsning som starter på minste nødvendighet og utvikles lag på lag til han mener det nå er så godt som nødvendig til det han trenger.

Kilder: Jeff Patton, http://www.agileproductdesign.com/presentations/user_story_mapping/index.html