Jeg vet hvorfor du ikke lykkes med Scrum (eller noen annen metode for den del)
Publisert February 16, 2010
I kategorien Diverse, smidig | 1 kommentar
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.
Kommentarer
Presisering rundt sosialdemokratiet
Publisert December 8, 2009
I kategorien smidig | Kommenter
Jeg var så heldig å få sjansen til å holde min lyntale på Oslo XP Meetup igår. Det var utrolig spennende fordi det var diskusjon umiddelbart etter lyntalen. I motsetning til på konferanser så måtte jeg her svare for mine tildels breibente påstander om det ene og det andre.
En ting jeg åpnebart formidlet uklart var dette rundt spesialistenes rolle i smidige prosjekter. Mange tolket mine utsagn til at man skulle ha spesialister som kun jobbet med sin spesialitet og at ingen andre på teamet gjorde det. Dette er like dumt som bare å ha generalister og mitt poeng er at du må sørge for å utnytte spesialisten slik at du hever kompetanse på resten av teamet. Spesialisten må selvsagt kunne gjøre mer enn sin spesialitet og det er viktig å sørge for at spesialistens kunnskap kommer resten av teamet tilgode.
Det var også nevnt i diskusjonene at spesialister som får jobbe i fred på sine egne ting er et kjempeproblem når denne personen ikke lengre er til stede, og igjen er jeg helt enig her. “Smarte” programmerere er et kjempe problem dersom de sitter alene å koker opp noe, så de må selvsagt tvinges til å jobbe med noe annet også.
Lyntaler er ofte slik at de fungerer best om man ikke tar med de grå nyansene, og jeg holder de som regel med Caps lock’en på. Slik at det er selvsagt mange nyanser rundt tingene jeg snakker om i Det Smidige Sosialdemokratiet, men det blir en kjedelig tale om jeg tar med det også.
Takk til alle som kom med spørsmål og feedback under Meetup’en, det var utrolig gøy å få snakke der og jeg gjør det gjerne igjen.
Kommentarer
Enkelhet, ikke så enkelt
Publisert November 16, 2009
I kategorien smidig, utvikling | Kommenter
Dette er en artikkel i kategorien refleksjon og det kommer som et resultat av det jeg har erfart i de siste årene hvor Smidig-bevegelsen virkelig har blitt allemannseie. Jeg har både vært team medlem, Scrum Master, arkitekt og delvis produkt eier i ulike sammenhenger. En ting har alltid ligget å ulmet i bakhodet mitt de siste årene og det har med begrepet enkelhet eller simplicity.
Begrepet brukes til veldig mye rart og har blitt en viktig ingrediens i alle dokumenter om visjoner og strategier. Alt skal være enkelt. En annen setting hvor enkelhet nevnes hyppig er i diskusjoner rundt konkrete løsninger. Her brukes begrepet ofte som hersketeknikk hvor den som kommer med “men det er jo ikke enkelt” eller “det er unødig komplisert” forsøker å parkere andre forslag. Det er i denne andre konteksten hvor det hele tiden har skurret i hodet mitt. Veldig ofte bruker man begrepet enkelt på en måte som tilsier at noe skal være banalt eller simpelt. Løsninger som involverer teknikker eller noen biblioteker blir ofte merket som kompliserte (ofte med unødvendig som prefix).
Enkelhetens lover
Enkelhet kan oppnås på mange måter, hvor en av de er å redusere og fjerne noe. Dette er grunntanken de fleste forbinder med enkelhet, men etter å ha lest John Maeda sin The Laws Of Simplicity ble jeg klar over at dette er bare en av veldig mange teknikker som kan brukes til å oppnå enkelhet.
Maeda oppsummerer enkelhet i ti lover som kan brukes i et arbeid med å oppnå enkelhet i løsninger. I det daglige hører jeg stortsett snakk om å oppnå enkelhet gjennom Lov 1: Reduser. Det er selvsagt en viktig teknikk for å oppnå enkelhet, men den er overvurdert særlig i forbindelse med å løse problemer som oppstår under systemutvikling. Dersom det er en problemstilling som ikke er triviell, så er det faktisk slik at det er en del andre lover som faktisk gir bedre resultat enn bare å redusere kompleksitet og å “dumb it down”. Organisering og kunnskap fører veldig ofte til enkelhet i løsningen, på tilsvarende måte som loven om å redusere.
Simplifisering mer enn bare å redusere
Hvis du må lage et rammeverk for å utøve f.eks mapping fra ett objekt til et annet, så kan det gjøres enkelt dersom du sørger for at rammeverket er godt organisert og hvis du sørger for å la de som skal bruke det få økt kunnskap gjennom eksempler og dokumentasjon. Veldig mange vil si at å lage et rammeverk strider imot det å gjøre noe enkelt, men det blir for enkelt mener jeg. Et godt skrevet rammeverk som er testet og skrevet brukervennlig vil jeg si er essensen i enkelhet. Du gjør en ofte utført operasjon enkel for flere. Hvorvidt det ligger avansert kode i rammeverket er egentlig uinteressant. Ingen stiller spørsmål rundt hvorvidt Spring rammeverket bruker noe avansert for å oppnå det de gjør. Hvorfor skal man i prosjekter måtte gå kanossagang om man ønsker å benytte seg av noe som av enkelte oppfattes som avansert?
Balanse
Enkelhet består ikke i å fokusere på reduksjon eller bare å se på tidsbesparelser. Evnen til å vurdere flere av lovene slik at de balanserer hverandre ut som er nøkkelen til å oppnå enkelhet.
Det viktigste er likevel å innse at for å oppnå enkelhet kreves mer enn reduksjon. Hvis du synes utvikling av web applikasjoner er vanskelig med Java verdens mange rammeverk, så blir det ikke bedre av å redusere alle slike å bare bruke servlet klassene. En slik drastisk reduksjon er ofte fundert på en tanke om enkelhet, trukket altfor langt. Ofte bunner slike på manglende kunnskap eller behov for å bevise noe, som begge er krefter som trekker i retning av “dumbing down”: ikke enkelhet.