Scrum og kreative prosesser
Av
,
7. november 2008
Med fare for å kaste en mengde brannfakler, velger jeg allikevel å skrive litt om min erfaring (dårlige sådann) med bruk av Scrum som prosjektstyringsverktøy i kreative prosesser.
Dette innlegget krever at du har enkel kjennskap til Scrum. Vær også klar over at jeg skriver mye om Javautviklere uten at dette er et angrep på Javautviklere som sådan (det var Javautviklere jeg jobbet sammen med).
Bakgrunn:
Fra en tidligere arbeidsplass var Scrum det nye “store” og mange (de fleste) prosjektledere ble fort sertifiserte ScrumMasters – og dette gjorde dem veldige glade. Det var tidvis en liten “Halleluja”-stemning rundt det hele. Og denne stemningen ble ikke mindre i ledelsen da dette viste seg Ã¥ fungere helt utmerket – rundt rene utviklingsoppgaver.
Men her stoppet det også opp.
I alle fall for alle som var involvert i kreative prosesser, enten det var Produktuvtikling (idéprosess), Interaksjonsdesign eller Grafisk design. La meg liste opp noe av problemene vi som “kreative” opplevde nÃ¥r Scrum kom og “ødela alt”…
Â
- Total mangel på ressurser: Det mikroskopiske fagmiljøet vi hadde rundt kreative prosesser førte til at det var alt for få design (både interaksjonsdesign og grafisk design) ressurser til antall prosjekter firmaet holdt på med. I beste fall kunne satsningsprosjektene få 0.5 design ressurser i en sprint. Og det var ingen automatikk at den samme ressursen ville bli tilgjengeliggjort i en eventuell påfølgende sprint. Vi var 5 personer fordelt på rundt 70-80 tunge Javautviklere og ca 10 store prosjekter, og vi manglet spisskompetanse på front-end utvikling.
- Splitting av fagmiljøe: I følge Scrum skal teamet skjermes i sÃ¥ stor grad som mulig, og ettersom vi var 0.5 ressurs pÃ¥ hvert prosjekt, og siden teamene skulle sitte skjermet, ble det slik at fagmiljøet ble splittet. Vi hadde dermed ingen andre designere Ã¥ “spille ball med”. Og naturlig nok ble man sittende litt her, og litt der, avhengi av hvilke prosjkter man var innvolvert i. Dette pÃ¥ sin side førte igjen til at man mistet flyten i hvert prosjekt…
- Estimeringspoker: Det fungerte utrolig dårlig at 7 Javautviklere skulle estimere hvor lang tid 1 Interaksjonsdesigner skulle bruke på Wireframes og Grafisk design av en gitt side. Samtidig skulle jeg som Interaksjonsdesigner være med å påvirke hvor lang tid en Javautvikler skulle bruke på å gjøre en bestemt oppgave (uten at jeg hadde forutsetninger for i det hele tatt å uttale meg om dette).
Resultatet ble at alle kreative oppgaver ble sterkt feilestimert – og at utviklingen startet i forkant av Interaksjonsdesign og Grafisk design (”The Inmates are running the Asylum“) - Leveranser og roller: Scrum sier ogsÃ¥ at det ikke spiller noen rolle hvem som gjør hva, sÃ¥ lenge teamet leverer i henhold til plan i slutten av hver sprint. Dette førte til at jeg (som har enkel web design kunnskap) ble satt til, fordi flertallet i teamet bestemte dette, Ã¥ levere XHTML / CSS, JavaScript, jQuery funksjonalitet og Flash filer . I starten havnet i store diskursjoner av typen: “Ã…h, Anders. Kan ikke du ogsÃ¥ ta i et tak for felleskapet? Ikke bare sitte der Ã¥ tegne og fargelegge og forklare og være femi.”).
- Forståelse: Teamet (inkludert meg) manglet forståelse for hva de andre i teamet var spesialister i. Spesielt trengte utviklerne en bedre forståelse av hva Interaksjonsdesign er for noe, og viktigheten av det arbeidet Interaksjonsdesignere gjør.
Jeg opplevde noe i retning av: “han tegner litt, ogsÃ¥ har han noen femenine tusjer og en alt for stor tegnebok. Hvor vanskelig kan det egentlig være?”  ÂOg nÃ¥r jeg prøvde Ã¥ forklare, og skape forstÃ¥else og akspet, fikk jeg “denne” (se illustrasjonen under for meg informasjon)
 - Meninger om design: Alle har meninger om design, og noen av “stunt”-utviklerne mente derfor svært mye om designbeslutninger som de ikke var kvalifisert til Ã¥ ta.Jeg tør pÃ¥stÃ¥ at en Javautvikler ikke tenker som “andre” mennesker! (Brannfakkel…hehe).
- Møter: Hver dag sÃ¥ man pÃ¥ antall timer hver ressurs hadde brukt pÃ¥ en gitt task, og sÃ¥ snakket man om hva man hadde gjort dagen i forveien og hva som skal gjøres i dag. Dermed ble jeg stÃ¥ende og si “I gÃ¥r tegnet jeg litt. Og i dag skal jeg forsette med det…” (Jeg gikk selvsagt i mer detalj enn det, men det var slik jeg følte at Javautviklerne hørte hva jeg sa.
Det var for øverig lite poeng for meg Ã¥ høre om Refactoring av “Housekeeper”-klienten, eller om de ytterst interessante tabellene og relasjonene i en Sybase database.
Generelt kan man si at samtlige møter i stor grad var bortkastet for min del! - Front-End: Uten spesialkompetanse pÃ¥ Front-end utvikling ble resultatet ikke helt optimalt, og designet led under kulturen “Det ser likt nok ut (i forhold til designskissene). Ikke helt likt, men greit nok”
I min perfekte lille verden:
Dersom jeg kunne fått alt på min måte (på med Interaksjonsdesigner-hatten) tror jeg Scrum og kreative prosesser kunne blitt svært så fint. Men da ville jeg helt sett følgende:
- En grundig analysefase må være på plass i forkant av oppstart (Personas, målsetninger, hva skal lages, innhold, brukergrupper, nødvendige brukertester, kravspesifikasjon, retningslinjer, teknologi etc)
- Beslutningstaker hos kunden må sitte i teamet, og være tilgjengelig for raske avklaringer/beslutninger
- Minst 2 (aller helst flere) designressurser i hvert team.
- Dedikerte Front-end utviklere
- Dedikerte Back-end utviklere (disse mÃ¥ selvsagt være med, men bør i aller høyeste grad “glemmes” nÃ¥r man skal lage et ordentelig bra Interaksjonsdesign. Sorry…men dere fÃ¥r ikke legge føringer pÃ¥ hva som er en god brukeropplevelse basert pÃ¥ hva dere syntes er vanskelig Ã¥ utvikle.)
- En god forståelse av tverrfaglig kompetanse
- “Rett man pÃ¥ rett sted”. La Interaksjonsdesigneren gjøre det han kan best, og Javautvikleren gjøre det han kan best. Det blir feil hvis en Grafisk designer skal mene noe om “code indents”,  “valg av variabelnavn” eller om man skal bruke jQuery istedenfor Scriptaculous
Jeg ser for meg at det er ulike faser av et slikt prosjekt ogsÃ¥. F.eks syntes jeg ikke Front-End utviklerne behøver Ã¥ være like tidlig innvolvert i sprinten som et analyseteam og designere (for det mÃ¥ jo avklares hva som faktisk skal lages før det lages…makes sense, no?).
Det er selvsagt viktig at de er med i oppstartsmøter, og har mulighet til å komme med innspill til tekniske løsninger og funksjonalitet, men inntill man vet hva man skal lage, og hvordan man vil at ting skal fungere, så vil de stort sett sitte å tvinne tommeltotter.
Jeg tror et godt egnet tidspunkt for disse til Ã¥ bli dypt involvert i prosjektet vil være nÃ¥r Wireframe med innhold er klart (det er viktig at de er tilgjengelige for avklaringer pÃ¥ hva som er teknisk mulig under utviklingen av disse). NÃ¥r grafisk design er ferdigstilt, er det Interaksjonsdesignerne og de Grafiske designerne som mÃ¥ kvalitetssikre det arbeidet som gjøres pÃ¥ Font-end siden – slik at man fÃ¥r nøyaktig det som har blitt bestemt.
Altså:
- Analyse
Hvem, hva, hvor, når, hvordan, hvorfor osv. Må være klart i forkant av oppstart Sprint.
 - Interaksjonsdesign / Grafisk design
Hvordan skal det oppleves, hvordan skal det se ut? Trenger en veldig grundig briefing av Analyse-teamet. NÃ¥r dette er overlevert kan selve Sprint’en starte (analyse teamet er ferdig for denne gang)
 - Front-end utvikling
Involveringsraten varier i forhold til hva som faktisk skal lages. Kanskje 30% holder?. Interaksjonsdesignere / grafisk designere må kvalitetssikre
Nå har kommet med noen innspill til hva jeg tror kan fungere, og jeg hører gjerne på hva dere har å si om saken. Husk på at jeg ikke er noen ScrumMaster, og at jeg bare kan reletere min kunnskap til Scrum på (dårlige) erfaringer. Jeg regner med at min neste opplevelse med Scrum blir utelukkende positiv 
Innlegget ble skrevet 7. november 2008, 12:30 under
Du kan følge med på tilbakemeldingene til dette innlegget gjennom RSS 2.0-feeden. Legg igjen en kommentar, eller trackback fra din egen side.
14 Kommentarer til "Scrum og kreative prosesser"
Interessante tanker, Anders! Selv har jeg gått fra initiell skepsis til å være veldig positiv. Men jeg sitter jo som utvikler da.
Jeg tror mange av problemene du har opplevd ikke nødvendigvis er metodikkens feil, men de som implementerer metodikken. Uten at jeg heller er noen Scrum-ekspert er jeg heller ikke overbevist om at å putte en designer på et Scrum-team og ha dem med på planning poker osv er en veldig god idé. Litt heterogenitet i teamet er bra, for mye er kanskje ikke så bra.
Ellers kan jeg tilføye at jeg selv har jobbet i Scrum-prosjekter der analyse, interaksjonsdesign og grafisk design har vært holdt litt på siden, men at de alikevel har fulgt opplegget, og prøvd å ligge en eller flere sprinter foran. På denne måten får alle (frontend-utviklere, utviklere) komme igang med sine sprintoppgaver umiddelbart, fordi de ikke trenger å vente på at design skal bli klart osv.
Jeg er usikker pÃ¥ hvordan man best kjører Scrum med “kreative ressurser”, men jeg mÃ¥ ihvertfall som utvikler si meg svært fornøyd med metodikken.
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.
Hvordan kreative disipliner passer inn i smidige metoder er en klassisk problemstilling. En vanlig løsning er at interaksjons- og visuell design kjører sitt eget iterasjonsløp paralellt med utvikling, hvor de ligger en iterasjon i forkant. Dette had jeg vært med på selv og det fungerte veldig bra.
Når det gjelder planning poker, så er det lov å bruke sunn fornuft. Alle skjønner at det er meningsløst for vaskedama å estimere java utvikling, akkurat som en java utvikler ikke kan estimere en oppgave om visuell formgivning. Uansett hva lærebøkene måtte si om dette, så funker det ikke som du sier:)
Nøkkelen til å lykkes med smidige metoder ligger ikke i å følge boka mest mulig, men å tilpasse metoden for hvert enkelt projsket/team.
En bra artikkel som peker på utfordringene man har med kreative disipliner i smidige metoder
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?
Scrum og smidig, nye ord for meg. Er det det er snakk om agile development, med iterasjoner, iterasjoner og iterasjoner – slik de har drevet med over atlanteren i et år (ting pleier å bruke et år over hit)? Virket bare litt ukjent med nye, og norske ord
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.
Veldig interessant post og diskusjon! Jeg kjenner igjen en del av problemstillingene som blir tatt opp. Fortsett med slike poster
@Morten: Kjempeviktig poeng å spikre grafisk design, innholdsbeskrivelse og funksjonalitet i forkant av utvikling. Utfordringen ligger vel i å kommunisere dette klart til prosjektleder og utviklere
@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.
Hei, og takk for stor interesse og mange gode innspill og meninger.
@Morten:
Jeg er helt enig i at jeg burde vært tøffere i starten av prosjektet og satt ned foten en gang for alle. I etterpåklokskapens ånd kan jeg si at jeg faktisk lærte noe av hele dette prosjektet. Dette kommer ikke til å gjenta seg for min del
Ellers spurte jeg min mellomleder det samme spørsmÃ¥let du stiller meg “hva gjorde du pÃ¥ et slikt prosjekt?!” Den avgjørelsen lÃ¥ utenfor min kontroll, og baserte seg pÃ¥ en mellomleder som mente at “en Interaksjonsdesigner / Grafisk designer sikkert er fint Ã¥ ha med pÃ¥ laget”…
At Interaksjonsdesign og innhold etc bør være 100% ferdig i forkant av utvikling sier seg pÃ¥ mange mÃ¥ter selv – men vi vet alle at det dessverre ikke alltid er slik i den virkelige verden slik som Christian nevner i kommentaren over.
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.
Først og fremst:
Morsomt skrevet!
Etter min erfaring så kunne dette hjulpet deg her:
1. User story mapping i forkant av sprint
2. Front end utviklere på teamet (som kunne tatt CSS, HTML osv)
3. Aktiv kunde- eller prosjekteier involvering
Noen java-utviklere med mindre negativ holdning til interaksjonsdesign ville nok også hjulpet. Ellers er jo scrum en veldig fin arbeidsmetodikk synes jeg. Det funker bra for oss!
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.
[...] Anders Fagerhus tok utfordringen på strak arm og skrev et strålende blogginlegg om scrum og kreative prosesser. Takk [...]
[...] pÃ¥ Kuttisme: Scrum og kreative prosesser Erfaringer fra smidig prosjekter – innføring av scrum i et kreativt [...]
Legg igjen en kommentar