(sorry, this article is in Swedish, because it is a response to a Swedish article. I won’t make this a habit.)
I en artikel i Computer Sweden den 3 feb står det ”siffror visar att nio av tio Scrumprojekt misslyckas”. Men de angivna siffrorna handlar i själva verket om något helt annat – att 9 av 10 personer som säger att de kör Scrum inte implementerar Scrum fullt ut. Detta säger ingenting om huruvida själva projektet lyckades eller inte (eftersom Scrum inte är ett självandamål). Denna typ av sensationsjournalistik gynnar ingen – utom möjligen tidningen som vill öka sina tittarsiffror, men på bekostnad av trovärdighet.
Låt oss därför titta på lite mer relevanta siffror istället (källhänvisning finns i slutet).
Scrum är den mest populära lättrörliga metoden (används i drygt 70% av alla lättrörliga projekt[1]). Att Scrum får kritik är en naturlig konsekvens av att Scrum har blivit mycket populärt på kort tid, vilket ibland leder till missförstånd och övertro.
Lättrörliga projekt lyckas i ungefär 75% av fallen[1][2], medan branchsnittet för IT projekt i allmänhet ligger på drygt 34%[3]. 80-90% av de organisationer som har gått över till Scrum rapporterar förbättringar i produktivitet, kvalitet, ledtid och kostnad – i de flesta fall dramatiska förbättringar[1]. Detta stämmer väl med min egen erfarenhet av att ha hjälpt många företag komma igång med Scrum.
Kort sagt, Scrum funkar bra enligt de flesta som använder det.
Scrum är dock ingen mirakelmedicin. Det är människor som får projekt att lyckas, Scrum kan bara öka oddsen.
Så vad är egentligen Scrum? Kort jargongsfri sammanfattning:
- Dela upp organisationen i små, självstyrande, tvärfunktionella team.
- Dela upp produkten i små konkreta delleverabler. Utse en ansvarig för att prioriterera mellan punkterna. Teamet ansvarar för att estimera punkterna.
- Dela upp tiden i korta iterationer, med leverans efter varje iteration.
- Optimera releaseplanen och prioritera om kraven i samråd med kund utifrån vad som levereras efter varje iteration.
- Optimera processen. Diskutera och förbättra processen efter varje iteration.
Det finns inte så mycket mer – Scrum är litet.
En del kritik mot Scrum är missriktad, kritiken handlar ofta om vad Scrum inte är snarare än vad Scrum är. Jämför med påståendet ”Hammaren är inget bra verktyg, den är ju svår att skruva med!”. Om verktygsköparen tror att hammaren löser allt så är det en kommunikationsmiss mellan säljaren och köparen, inte ett problem med själva hammaren. Ett projekt kan misslyckas trots att man använder hammare, men kommer sällan misslyckas på grund av att man använder hammare. Samma med Scrum.
Scrum är som schack. Enkla regler, svårt spel. Systemutveckling är ett svårt spel, det kan ingen process trolla bort. Huvudstyrkan med Scrum är att processen avslöjar befintliga problem tidigt, problem som ofta har funnits länge i organisationen men varit dolda. Men det är upp till människorna att lösa problemen, inte processen. Ibland är det frestande att skjuta budbäraren (Scrum) istället för att angripa det underliggande problemet.
Den vanligaste anledningen till att IT projekt misslyckas är dålig kommunikation och brist på kundengagemang[3] – Scrum skapades för att adressera just det problemet. Övriga viktiga områden (t.ex. kodkvalitet) adresseras av viktiga kompletterande metoder som XP (eXtreme Programming) och Lean. Många delar av XP är i stort sätt obligatoriska för att lyckas med Scrum i mjukvaruprojekt – precis som att man nästan säkert behöver komplettera sin hammare med en skruvmejsel.
När ska man inte använda Scrum då? Ett typiskt exempel är ett supportteam som arbetar mestadels reaktivt, vilket försvårar iterationer. En typisk lösning är i så fall att köra alla delar av Scrum utom iterationer, och istället komplettera med Kanban (en teknik från Lean). I strikt mening är detta inte Scrum längre (eftersom Scrum är iterativt), men Scrum var ju som sagt inget självändamål.
Så, är Scrum något för din verksamhet? Några tips inför det beslutet:
- Läs på om Scrum (de fem ovanstående punkterna är en bra startpunkt) och bedöm själv.
- Lyssna på företag som faktiskt kör Scrum, läs konkreta fallstudier. Var vaksam mot ”tyckare” som inte själva har kört Scrum. Ta positiv och negativ hype med en nypa salt.
- Pröva! Implementera Scrum ett steg i taget och se vad som händer.
Till din hjälp kan jag erbjuda en checklista och en bok – båda gratis online.
Källor
[1] State of agile development survey 2008. 3061 deltagare från 80 länder.
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
[2]Agile adoption rate survey 2008. 642 deltagare.
http://www.ambysoft.com/surveys/agileFebruary2008.html
[3] Standish Group CHAOS report 2004. Över 40,000 IT projekt.
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Lysande. Man begriper varför ditt företag heter Crisp när man läser dig. Nu ska jag sprida länken till den här artikeln på jobbet.
Mycket bra. IDG sätter verkligen trovärdigheten i dessa frågor på spel. Jag tror inte att det bara rör sig om en sensationsjournalistik utan också möjligen en okunskap. Vet faktiskt inte vad som är värst. 🙂
Bra respons! Vi är många som tycker det CS når nya lågvattenmärken med artiklar den senaste tiden. Denna var nog tyvärr den mest skruvade och mest dåligt förankrade av alla dessa lågvattenartiklar.
Jag börjar längta efter en svensk tidning som motsvarar Computer Sweden men som har en mer seriös inriktning. Dvs inte sensationsjournalistik. Det är ok att dissa projektmetodiker m.m. men man kan åtminstonde backa upp det med mer än lösryckta citat från olika person. Hur lågt skall en reporter på CS få dyka innan CS redaktionen reagerar? Eller är detta den nya inriktningen på CS? kvällsblaska…
Väldigt bra artikel (men vad annat kan man vänta)!
Panikrapporter säljer väl bra men Computer Sweden säljer sin trovärdighet när de skriver ensidiga artiklar med bristfällig faktakontroll. Det vore också intressant att se hur man valt sina experter. När jag tänker experter på agil systemutveckling och projektledning tänker jag Crisp, Citerus, Softhouse och Valtech. Men de som får tala från branchen är ett norskt bolag och Cap.
Min erfarenhet är just den du beskriver: när man börjar frångå principerna är det ett tecken på att man inte förstår dem och då är misslyckandet ett faktum. I ett tidigare projekt blev detta uppenbart när man lämnade scrum i princip (ingen backlog, produktägare utan domänkunskap, ingen beräkning velocity, icke stabila leveranser). då rasade allt samman. berodde det på scrum? Som Ken Schwaber uttrycker det:
Scrum does not bring excellence, it exposes incompetence.
Väldigt talande för artikeln är följande uttalande:
– Jag har sett utvecklare som kommer direkt från en Scrumkurs och kör hela projektet i botten, säger Thomas Almnes.
Hur kan en persons teammedlems deltagande i kurs kan köra ett helt projekt i botten är väl ett tecken på att något annat är fel i det projektet. Att detta är skrivet som om det var vanligt förekommande är anmärkningsvärt.
Men å andra sidan har Computer Sweden i frågan om scrum även tidigare citerat källor (läs Tobias Fors) på ett tvivelaktigt sätt.
Hallå Henrik. En liten detalj: "Dela upp organisationen i små, självstyrande, tvärfunktionella team." Jag håller förvisso med om att man bör göra detta, men som jag ser det är Scrum projektcentrerad och föreskriver snarare att projektorganisationen, som ofta är temporär, skall vara tvärfunktionell. Den tvärfunktionella organisationen – kontinuerlig och inte projektbaserad – härrör jag från Lean.
Jag slog i min svarta Scrumbok innan jag skrev detta
för att se om jag missat något, men jag tycker att den pratar mycket om projekt. Har jag fel?
Scrum är inte projektcentrerat, utan teamcentrerat. Teamen är små, självstyrande, och tvärfunktionella.
I Scrum skiljer man inte så mycket på Linjeorganisation och Projektorganisation. Man bygger upp en topologi av team och backlogs och produktägare (samt vissa stödfunktioner som linjechefer). Så försöker man odla fram hyperproduktiva team och behålla dessa (istället för att slå "projektet" tog slut och "resurserna" ska återgå till "linjeorganisation"). Scrum och Lean är parallella evolutionsspår som bygger på samma grundprinciper och funkar därför bra ihop. Så idén med den tvärfunktionella organisationen härör från både Lean och Scrum.
Ok, när jag läser ‘team’-delen av svarta boken så kan jag tolka den som du gör, men jag kan lika gärna se den som om den beskrev existerande projektkulturer – boken tar i mitt tycke ingen ståndpunkt i frågan.
Jag tror att detta är grunden till att en del glatt implementerar Scrum som ‘projektmetoden efter RUP’ utan att förändra sitt Command-and-Control och projektdrivna arbete. Den är lite otydlig i kanterna och kan tolkas olika beroende på hur man vill se det.
Jepp, det var därför certifieringsprocessen skapades. Ken och Jeff upptäckte att boken inte riktigt räckte till för många, det behövdes något mer interaktivt för få poletten att trilla ner. Två dagars kurs visade sig vara ett bra format.
Testing ÅÄÖ…
OK, ÅÄÖ sjukan löst :o)
Riktigt bra artikel. Mjukvaruutveckling är mycket riktigt svårt – med eller utan Scrum – så varför inte maximera ens chanser (höja oddsen) och göra livet så enkelt som möjligt för sig. Det är ju precis vad Scrum handlar om: att göra livet så enkelt som möjligt för alla inblandade (utom möjligen beställaren jmf med traditionella angreppssätt), och även om det fortfarande är svårt så är det åtminstone mindre svårt än det annars vore.
Scrum är ingen mirakelmedicin. Men bara för att det inte löser _alla_ problem så betyder det inte att Scrum inte fungerar alls.
Min erfarenhet är att det blir lättare även för beställaren. Beställaren behöver ju inte längre speca upp allt i förväg, och hon kan ändra kraven under projektets gång utan att projektet behöver bli senare och dyrare. Och vi slipper CCB:er…
I verkligheten så är scrum lite av slöseri med tid. Scrum funkar mest som gamla tiders husförhör….har man gjort sin hemläxa, och vad skall man göra idag. Scrum är inget forum för problemlösning, och vidare ger scrum en närsynt bild av projektets framåtskridande, där helikopterperspektivet saknas. Nej, fram för en bra klassisk projektplan, och följ upp projektet med milestones och planerade projektmöten. Risken med scrum är att man tänker kortsiktigt och tappar riktningen. Som om det inte skulle vara nog med nackdelar, så finns det alltid pratglada som utnyttjar scrummöten till att likt en gisslansituation tvinga kvar en publik, som kanske har annat för sig än att pladdra. Nä, ned med scrum…det funkade bra även innan scrumkonsulterna sålde in den här idén till HR.