To måneder etter at jeg started i IXD i September 2008 (uff… det kjennes ut som jeg har vært sammen med alle disse flinke gutta i årevis…) og etter jeg fikk en forståelse og oversikt over hvordan prosjektene ble kjørt før min tid, satt jeg igang en spennende intern diskusjon hos oss om “scrum“: Var dette noe for oss? Er det noen som har erfaringer fra før om hvordan “scrum” brukes med kreative prosesser? Kunne dette fungere? Har vi lyst til å prøve?
Eks-kollega Anders Fagerhus tok utfordringen på strak arm og skrev et strålende blogginlegg om scrum og kreative prosesser. Takk Anders 
Nå, etter to vellykkede prosjekter og verdifull erfaring, ønsker jeg å ta opp igjen tråden fra Anders og fortelle først og frem om hvordan vi klarte å innføre “scrum” i IXD – og senere i andre blogginlegg om hvordan vi gjennomførte smidige prosjekter (prosessen, krav, erfaringer…)
Kreative folk liker ikke tvangstrøye-begrep som “scrum” – IKKE BRUK ORDET SCRUM, LAG DINE EGNE BEGREPER!
“Scrum” er en smidig prosjektmetodikk som springer fra og som benyttes innenfor programvareutvikling. I “UX og design”-avdeling ble dette veldig derfor dårlig mottatt: ” vi er annerledes”, ” vi trenger rom for kreativitet”, “vi er ikke systemutviklere”… og dette gikk og gikk…
Scrum er kun en av de forskjellige iterative og inkrementelle utviklingsmetoder som blant annet Extrem Programming (XP), Unified Process (UP), Evolutionary Project Managemnet ( EVO) osv.
Alle disse metoder har en del ting i felles:
- Risikodrevet og kundedrevet iterativ planlegging
- “Timeboxed” iterativ utvikling
- Tar imot endringer, men IKKE iløpet av selve iteraksjonen
- Tilpasnigsdyktig iterative planlegging og utvikling
- Inkrementelle leveranser (fungerende delleveranser)
Løsning var å fokusere på alle disse felles prinsipper som er grunnpilareren i smidig utvikling og Agile Manifesto – uten å sette noen etikett på det.
For å gjøre en lang historie kort, vi så på alle disse forskjellige smidige metoder og deres verktøykasser, slik at vi kunne velge det vi mente kunne fungere hos oss. Vi prøvde og testet litt av hvert og gjorde tilpasninger underveis:
- “Funket dette?”
- “Ja”
- “Da forstetter vi med det”
- “Funket dette?”
- “Nei”
- “Da dropper vi det. Forslag om noe annet vi kunne bruke som kan fungere bedre?”
Per dags dato jobber vi forstsatt med “hva skal babyen hete”, men alt tyder på at det blir “IXD smidig prosess” 
6 kommentarer til "Erfaringer fra smidige prosjekter: innføre "scrum" i et kreativt miljø"
Kreative mennesker liker som du sier ikke tvangstrøyer, men de aller fleste er opptatt av å kunne være mest mulig effektiv og kreativ. Å jobbe med prosjektmetodikk også i en kreativ bedrift bør være selvsagt, men krever kanskje at man tar “alle” med på diskusjoner og arbeidet med å gjennomføre en slik metodikk.
Scrum kan være både en morsomt og utviklende måte å jobbe på, men er selvsagt lagt opp mer for programvareutvikling.
De aller fleste elementene er dog svært spiselige, og jeg synes det er viktig å være litt pragmatisk når man setter rammene, ta bare i bruk det som er hensiktsmessig.
Som en kreativ sjel som har jobbet mye i større prosjekter med mange ulike mennesker over flere år merker jeg meg stadig hvor flinke utviklere er til å jobbe sammen. Parprogrammering fungerer vitterlig veldig bra, men kjennes litt unaturlig til å begynne med (er ikke helt over kneika ennå). De stedene jeg har jobbet har dette vært området hvor jeg føler det har vært mest å hente; folk ser ut til å lengte tilbake til plassen sin og produsere i vei, og glemmer dermed den mest spennende delen av en kreativ prosess. Nemlig det å jobbe frem konsepter og helhetlige idéer SAMMEN. Det blir garantert et bedre resultat!
Hvordan funker det hos IXD?
I våre prosjekter er hele team sammen fra starten: en interaksjonsdesigner, en grafisk designer og en frontend utvikler og har et eget “scrum” rom.
Vi fant ut at det ikke var hensiktsmnessig at alle skulle starte med samtidig. Som regel interaksjonsdesign starter en uke før grafisk design og front-end utvikling enten samtidig som grafisk design eller en uke etterpå. Uavhengig av når de begynner, er alle med på alle møter fra starten (sprint 0, alle scrum møter, alle sprint reviews, alle sprint retrospectives…) og kommer med innspill.
Kunden (Product Owner) sitter sammen hos oss i løpet av hele prosjektet. Dette hjelper utrolig mye: kjapp kommunikasjon og tilbakemeldinger, og ikke minst at beslutninger tas forløpende.
Noe som vi vurderer nå for tiden er å teste par-design. Noen erfaringer der ute om dette?
Hei José, og takk for spennende innlegg.
Jeg gleder meg til å høre mer om dette.
Jeg må selv si at jeg for første gang er i et prosjekt hvor jeg føler at Scrum, design og utvikling fungerer fint – og det er en lettelse.
Her her mine tanker om hvorfor Scrum fungerer denne gangen (i alle fall denne sprinten…hehe):
1. Vi har nok design resurser til å ligge i forkant av utvikling (både interaksjonsdesign og grafisk design). Dersom det er dette du mener med par-design så kan jeg anbefale dette på sterkeste. Vi har nå kommet så langt på design at vi kan dedikere en egen resurs kun til “future-features” (hva, og hvordan, ting skal se ut og oppføre seg i fremtidige versjoner av nettsiden).
2. Vi har svært god kommunikasjon med en detalje – og design orientert front-end utvikler.
Vi sitter mye ute hos kunden, og fører en muntlig dialog framfor “millioner” av e-post og beskjeder i basecamp…
3. Vi har et sterkt back-end team som tilrettelegger for funksjonalitet, og bistår front-end utviklingen.
4. Designerne har også et eierforhold til backlog og sprint tasks.
Og for første gang syntes jeg å oppleve at vi har klart å bryte design oppgaver ned i fornuftige mindre oppgaver. Estimering og task-breakdown ble gjort sammen med front-end teamet, og ble i stor grad prioritert av dem.
Jeg er som sagt veldig spent på å høre hva dere kommer fram til, for jeg begynner å innse at det er godt mulig å få til en smidig og god prosess rundt kreative prosesser og utvikling. Hadde du spurt meg for et halvt år siden hadde jeg vært langt mer negativ
Lykke til
Interessant å lese om en vellykket tilnærming til en agil utviklingsmetodikk fra et kreativt ståsted, Jose. Det er flere ting i innlegget ditt og kommentarene jeg kunne tenke meg å kommentere, men jeg skal ta det viktigste:
Som oppdragsgiver har jeg en del reservasjoner mot modellen der interaksjonsdesign/grafisk design gjøres klart før back end utviklerne involveres ordentlig. Grunnen til dette er todelt.
For det første går man da glipp av den kreativiteten som de fleste utviklere er utstyrt med, men som sjelden benyttes.
For det andre kan man risikere å forelske seg i grafiske/interaksjonsmessige løsniger som er veldig teknisk kompliserte å få til (det jeg som oppdragsgiver tenker på som “dyre løsninger”). Det ønskede resultatet er jo det som gir et riktig forhold mellom innsats og verdi for oppdragsgiver.
Er det andre som har tanker om dette?
Du har rett, Arve. I et stort, lang og kompleks prosjekt, bør back end utviklerne involveres fra starten av, på samme nivå som det vi gjør nå med våres front end utviklere.
Vi ser for oss følgende tids/involveringsrekkefølge og del leveranser
1) interaksjonsdesign
2) grafisk design
3) front og back end utvikling i paralell.
Det er et spørsmål om størrelse og kompleksitet.
Som sagt tidligere, uavhengig av når hver enkel begynner, bør alle bli med på alle møter fra starten (sprint 0, alle scrum møter, alle sprint reviews, alle sprint retrospectives…) og kommer med innspill slik at disse tilfeller du nevner (utløse kreativiteten og gjør løsning teknisk enklere.. og billigere) blir ivaretatt.
Allerede fra første sprinten, hvor kun interaksjonsdesignere er involverte, da kan både front og back end utviklere synligjøre enklere grep og tiltakk som fører til en teknisk enklere, smidigere og mer kostnadseffektiv løsning.
Foreløpig, har vi ikke hatt så mye innspill og involvering fra back end utviklere, fordi vi har kun valgt å kjøre smidig med teknisk enkle og relative små prosjekter (4 ukers prosjekter): websider med publiseringsløsning og uten mye integrasjon med andre systemer.
Vi holder på med å lære dette og tar gjerne baby steps
[...] Scrum på Kuttisme: Scrum og kreative prosesser Erfaringer fra smidig prosjekter – innføring av scrum i et kreativt miljø: [...]