Scrum og kreative prosesser

For et lite, norsk selskap ligger det ingen automatikk i at Scrum blir en suksess. Er man små og har et sett godt fungerende prosesser, er man sannsynligvis ganske smidig i utgangspunktet.

Når det er sagt ligger det mye godt i Scrum, og for de tidligere omtalte selskapene ligger utfordringen i å plukke de beste elementene. Det fine ved Scrum er at man ikke trenger å innføre hele konseptet, men kan innføre de elementene man selv ser som hensiktsmessige. Vi gjorde dette hos min forrige arbeidsgiver, og det opplevdes som positivt.

Det blir litt rart å skylde på scrum når man bryter bortimot alle de rådene scrum kommer med. Poenget med planning poker er at de som skal utføre en oppgave får mest innflytelse over estimatet, så det var en ganske tullete måte de brukte den på. Poenget med et scrum team er at teamet skal inneholde alle som skal ha ansvar på teamet. Da må designeren enten være helt med, eller ikke ha ansvar. (Tror begge alternativer er gode). Poenget med teamansvar er ikke at andre skal bestemme hva du skal gjøre, men at du selv skal velge oppgaver.

Det er mange årsaker til at Scrum prosjekter kan gå dårlige (som alle andre prosjekter). Men dersom man bryter mot grunnprinsippene i scrum, er det knapt scrums skyld, synes jeg.

Ellers er jeg som Java-utvikler enig i ditt poeng at utviklere ikke er representative brukere og knapt er mennesker. Dette gjelder dobbelt for såkalte backend-utviklere, som er folk som bare vil leke seg med teknologi uten å forstå verdien av systemet.

PS: Når du sier “grundig analysefase” merker jeg at jeg blir veldig skeptisk. Mye arbeid i analyse betyr investering i ting som kanskje burde kuttes og oppfordrer til overproduksjon og “lagerhold” av arbeidsoppgaver. Hva legger du i dette når det gjelder tidsforbruk?

Det viktigste med scrum slik jeg ser det er at det er et forsøk på å gi overarbeidede ansatte mer kontroll over sin egen tid, med det mål for øyet at alle i bedriften over tid får litt feelgood stemning, i stedet for å bli drevet fra skanse til skanse og levere halvdårlig arbeid.

Så det at ett prosjekt går i dass, eller det andre, eller det tredje, er egentlig bare positivt, for det gjør deltakerne mer bevisste, og flinkere til å estimere. Det gjør feks at du som grafisk designer på et morramøte, på det tredje scrumprosjektet du er med på, kan gå opp til veggen, røske ned postitlappen der det står at Anders skal levere flash, og si “nope, ekke mitt bord”. Forhåpentligvis hadde du hatt baller til å gjøre det på det FØRSTE prosjektet da, men vi er jo mennesker, og det tar lang tid før vi tør å gjøre det vi burde i nye settinger.

Ellers er det min erfaring, etter å ha jobba med webdesign siden 1993, at den grafiske designet, innholdsbeskrive og delvis funksjonalitet bør være ferdig (og da mener jeg gjennomdiskutert med kunden og godkjent, gjennom flere runder, og spikra) før utviklingsarbeidet starter. Dernest må alle ønsker om store endringer til funksjonalitet og design fra kunden, fra prosjektledere, eller fra teamet selv, føre til at prosjektet stoppes, slik at man kan gå tilbake til tegnebrettet og igjen bli enige.

Dermed slipper du som grafiker å bli frusterert.

Men en annen ting, jeg skjønner ikke helt hva du gjør på et slikt team i det hele tatt hvis du IKKE har erfaring med frontenddesign, i det tilfellet burde du jo bare holdt kjeft og lært av de mest erfarne utviklerne du jobba med, som helt sikkert kan ekstremt mye om brukergrensesnitt. Og så kunne de på sin side lært noe om estetikk av deg.

@Morten: Veldig enig at grensesnittet langt på vei burde være definert før man begynner å utvikle. Desverre er det snarere omvendt: kunden har ofte hatt en 10-12 utviklere i sving noen måneder allerede før de trekker inn noen til å spekke hva systemet faktisk skal by brukeren på :)

Litt overdrevet selvfølgelig, men jeg syns utforming og design ofte skjer i feil rekkefølge.

Kjernen i smidig systemutvikling er, slik jeg ser det, å bruke hodet. Virker ikke som verken du eller de andre i dette prosjektet gjorde det. Det er viktig at de tingene man gjør har verdi – og det er lov å stille seg spørsmål eller stoppe opp og reflektere litt dersom man føler at man holder på med meningsløse ting.

Et poeng som ikke er berørt ennå, og som også er viktig, er at man må finne en arbeidsmåte som lar teammedlemmene jobbe delvis i parallell.

Konkret i dette tilfellet betyr det å finne en arbeidsform som gjør det mulig for en programmerer å begynne jobben før interaksjonsdesigneren er helt ferdig, og så ta justeringer etter hvert som interaksjonsdesigneren bli ferdig. Se ikke bort fra at det da også kommer nyttige innspill tilbake til interaksjonsdesigneren fra programmereren.

“100% ferdig i forkant” og “overlevering” (innad i teamet) er ord som skurrer når man kjører smidig.