Jeg vet hvorfor du ikke lykkes med Scrum (eller noen annen metode for den del)

I artikkelserien “jeg vet hvorfor” skal jeg nå ta for meg Scrum, men jeg tror dette gjelder alle metoder. Den absolutt mest utbredte av de smidige metodene er Scrum og den benyttes på så mange ulike måte og tolkes i så mange retninger at den naturlig nok begynner å miste litt av den sølvfargede glansen metoden hadde da den først kom. Årsakene til hvorfor mange føler de ikke lykkes med Scrum er like mange som årsakene til at andre føler de får mye igjen for å benytte metoden. Jeg har vært i kontakt med mange som hevder å benytte Scrum og det er selvsagt en enorm forskjell i hvordan metoden brukes rundt omkring. Likevel vil jeg påstå at det er en fellesnevner for alle de som ikke får Scrum til å fungere.

Lille speil på veggen der…

Jeg hadde gleden av å delta på Mike Cohn’s Scrum Master “Sertifisering” i fjor og en av tingene jeg sitter igjen med er det Mike sa om at:

“Scrum løser ingen problemer, den bare viser deg problemene dine”

Dette er selvsagt ikke noe som du nevner når du selger inn metoden, ettersom ingen vil ha noe som bare viser deg problemene uten noen løsning. Følgelig blir veldig mange skuffet når det viser seg at Scrum kun visualiserer og bringer for dagen alle problemer du tidligere har forsøkt å feie under teppet. Du titter i speilet og alt du ser er utfordringene du har slitt med tidligere og dette fra noe som alle mener er så bra. Naturlig nok sitter en ofte skuffet tilbake og begynner å se etter neste ting som lover å løse dine problemer uten noe jobb. Det er også en del andre ting som Scrum lover og dette snakker Geir Amsjø om i Hva oppnår du med Scrum?.

Arbeit macht frei

Arbeidet skal sette deg fri, og slik også når det gjelder metodearbeid. Hvis du skal lykkes med å implementere en metode må du være beredt på at det krever endringer. Gjerne store endringer som vil gå langt utover f.eks et prosjekt. Scrum vil i stor grad vise deg hvor problemene er og hvorvidt du skal få ønsket effekt ved å bruke Scrum avhenger 100% av din evne til å endre omgivelsene. Uten store endringer i både prosjekt og i omgivelsene vil du aldri lykkes særlig bra med Scrum.

Klarer du ikke å ha hyppige leveranser fordi du har en driftsorganisasjon som evner å ta i mot mer enn 1 gang i året? Vel, da må du ta tak i det. Hvis du ikke har noen som kan fungere som produkteier eller være kravstiller, ja så må du ta tak i dette å stable noe på beina.

Når Scrum ikke er nok..

Dette med endringer rører ved noe av det som mange snakker om i disse dager, nemlig at Scrum er en metode for prosjekt gjennomføring. Et prosjekt er noe flyktig som har en start og en slutt, mens organisasjonen som betalte for prosjektet består. Mangelen på helhets fokus er hva jeg mener er Scrum’s akilleshæl. Metodikken gir deg kun hjelp til å belyse mangler og gjennomføre et prosjekt. Utover dette er du på egenhånd og får liten hjelp. Organisasjoner trenger et helhets fokus og en måte å tenke på som hjelper i mer enn bare praktisk prosjektgjennomføring.

Lean, the “new” kid on the block

Veldig mange har begynte å snakke om Lean som et svar på manglene vi har erfart med Scrum. Mytologien rundt Lean har mange ingredienser som gjør at det er en sikker hit blant IT-folk: et ekskluderende vokabular av Japanske ord, har sitt opphav i østlige tanker og er noe nytt. Tiltross for all hypen som vi har sett, og som vi kommer til å se enda mer av i årene som kommer, så tror jeg faktisk at helhets fokuset i Lean er hva Scrum mangler for større organisasjoner.

Har du en jobb eller en karriere?

Hvis man til enhver tid har øyne og ører åpne vil man kunne lære noe nytt i de mest pussige situasjoner. Dette gjelder også når du ser TV på en lørdag kveld. Jeg så Chris Rock sitt Kill The Messenger show på SVT2 denne helga. Ikke bare var showet hysterisk morsomt, men det inneholdt også jobb relaterte råd! Hvem hadde trodd at en av de mest reflekterte uttalelsene jeg har hørt siste året om jobb kommer fra Chris Rock?

Spørsmålet han stiller publikum var: har du en jobb eller har du en karriere? Chris var kjempefornøyd med at han ikke lengre måtte ha en jobb nå som han hadde en karriere. En jobb er noe du gjør 9-17 og du får lønn (i Rock’s tilfelle var det å skrape reker på en rekerestaurant i Brooklyn). En karriere derimot er noe du har når du virkelig tjener penger.

Du skaper din egen karriere

Jeg har sett mange kolleger og andre i bransjen som alltid har veldig mange årsaker til hvorfor de ikke gjøre ulike ting. “Jeg kan ikke jobbe test drevet fordi prosjekt lederen gir meg ikke tid”. “Prosjektet suger fordi vi bruker utdatert teknologi og arkitekten er en dust”. Denne typen uttalelser kommer oftest fra de som har en jobb og som ser på det de gjør som en jobb.
Hvis du derimot ser på det du gjør som en karriere lar du ikke detaljer som lite tid og inkompetente arkitekter hindre deg i å gå videre i din karriere. Du finner måter å komme deg rundt hindringene på slik at du kan komme videre.

Hvis alt du kommer opp med er unnskyldninger til hvorfor du ikke gjør ulike ting, så er det heller ikke rart du ikke får nye arbeidsoppgaver eller at du aldri får gjøre noe du synes er spennende. Muligheten til å gjøre spennende ting skaper du selv og du kan ikke vente på at de lander i fanget ditt. Du må ta det du gjør som en karriere og ikke en jobb du får betalt for. Hvis du er en utvikler som ser på det du gjør som en jobb og er fornøyd med det, så må du heller ikke forvente å gjøre spennende ting. Du må jobbe for å komme i riktig posisjon, du må ta sjanser, du må stille spørsmål.

Så still deg selv spørsmålet: Har jeg en jobb eller har jeg en karriere?

Elegante løsninger?

Det Chris sier her sammenfaller veldig med ideène som Mathew E. May skriver om i The Elegant Solution: Toyota’s Formula for Mastering Innovation. Boken handler om hvordan Toyota har skapt et system for kontinuerlig inovasjon og at dette er nøkkelen til at de er verdens beste bil produsent. Arbeidsgivere må i følge boken få sine ansatte til å føle at de har en karriere, langt mer enn at de har en jobb.

Desverre kunne ikke YouTube finne akkurat sekvensen jeg refererer til, likevel så legger jeg med en godbit fra showet Kill The Messenger:

Gro applikasjonen din som en åker

Jeg har vokst opp på en gård i fjellbygda Folldal og er dermed veldig mottagelig for analogier og eksempler som tar utgangspunkt i gårdsdrift. Overraskelsen min var stor da jeg leste en artikkel av XP-guru Kent Beck som nettopp bruker bøndenes metode for å dyrke åkeren for å vise hvordan man kan gjøre det samme i applikasjons design.

Artikkelen First One, Then Many tar for seg et klassisk dilemma innen systemutvikling. Du skal lage et system som skal håndtere en transaksjon i første omgang, men man antar at det vil måtte håndtere mer enn en senere.  Klassisk systemutviklings litteratur sier da at du må ta høyde for dette i ditt design. Kent forklarer i sin artikkel hvorfor dette ikke er en god ide og han bruker bonden som utgangspunkt.

Bønder dyrker ikke åkeren sin for at den skal være komplett fra dag en, han dyrker den for at den skal være perfekt når det er tid for innhøsting. Derfor bruker bonden ikke bare en sort frø, han bruker gjerne flere sorter frø for å oppnå best resultat. Bonden bruker en frø type som gror raskt for å stabilisere jordsmonnet i tillegg til den egentlige sorten frø som gror litt saktere. På denne måten sørger han for at åkeren over tid blir utnyttet optimalt.

Jeg er veldig enig i Kent sin måte å tilnærme seg applikasjons design. Gjennom å gjøre “smarte” antagelser og å “ta høyde for” ting så skaper man problemer for den som kommer senere. Det er langt bedre å ha en kodebase som reflekterer det som systemet faktisk gjøre, enn en kodebase som inneholder halvveis implementert funksjonalitet. I Lean Software Development kalles dette søppel (eller waste (eller ennå mer trendy kalles det muda)). Søppel har en tendens til å skape ubehag dersom det opptrer i større mengder og blir liggende over tid. Derfor er jeg helt enig med Kent sine tanker om å la kodebasen reflektere hvordan virkeligheten faktisk er. Det gjør det enklere å både vedlikeholde og videreutvikle en løsning.

Hvis du tenker på Kent sin artikkel neste gang du sitter å forsøker være kreativ når du spesifiserer et grensesnitt så vil du, kunden og systemet nok takke deg til slutt.