Er Scrum kompleks?

Scrum
 
Når jeg holder kurs åpner jeg ofte med å si at Scrum er et enkelt rammeverk som tilbyr “minst mulig struktur” for å organisere kunnskapsarbeid på en effektiv måte. Det er noen få regler, 5 verdier, 5 møter, 3 roller og 3 artefakter. Det baserer seg på agilemanifesto.org, støtter seg på Lean-tankegangen og baserer seg på empirisk prosesskontroll i iterasjoner på 1-4 uker.

Jeg sier også at det lønner seg å “ta hele kuren” og implementere Scrum etter boka og vinne erfaring, deretter å eksperimentere med egen prosess slik at arbeidsformen gradvis blir mer og mer optimal. Om man klarer å gjennomføre Sprint planlegging på 30 minutter så er det selvsagt greit (selv om angitt timeboks er 2 timer). Om man klarer seg med en halv time i uka til Produktkøraffinering er det også i orden. Scrum pålegger deg selvsagt ikke “overhead”, for i bunn og grunn er dette en prosessforbedringsprosess. Hvis noe ikke gir verdi er det “waste” og skal bekjempes. Jeg støtter meg her på Core Scrum fra Scrumalliance, men Scrumguiden fra Scrum.org forteller det samme.

(For ordens skyld: Det er ikke noe i veien for å levere mange ganger i løpet av en iterasjon, eller å kombinere Scrum med Lean Startup sin “Build-Measure-Learn” eller DevOps)

Men alt er selvsagt relativt, og vi som steller med Scrum er vant til at de som sverger til Kanban forteller at Scrum er rigorøs og kompleks og medfører overhead. I BEKK sin ferske “teknologiradar” kan vi for eksempel se at de anbefaler å avstå fra Scrum, men heller vurdere gammeldags prosjektstyring..

Jeg har hørt Kanban-faderen selv, David J Anderson, presentere Kanban ved flere anledninger, og det slår meg at han ikke evner å forklare Kanban uten å sammenligne det med Scrum (der alt ved Scrum får negativt fortegn). Kanban er opplagt enklere og mindre rigorøst enn Scrum, siden det ikke definerer hverken roller eller aktiviteter. Samtidig er Scrum langt enklere enn Rational Unified Process og f.eks ITIL. Eller Prince2 for den saks skyld. Figuren under (laget av Henrik Kniberg) forteller en del.

Personlig synes jeg Kanban er genialt enkel og når jeg gir råd til organisasjoner sier jeg alltid at det viktigste er at de forstår sin egen kontekst, sine egne forretningsmålsetninger og setter seg godt inn i konseptet Agile (hvis dette passer med målene da – hvilket det gjør for de fleste moderne selskaper). Deretter kan de velge rammeverk. Jeg anbefaler å starte med Scrum for det gir konkret støtte til snuoperasjonen. Det tydeliggjør en nødvendig endring, og gir “umodne” organisasjoner en trygghet. For eldre vannfallsorganisasjoner gir Scrum et visuelt bilde og på samme måte et tydelig målbilde. Så kan man etter hvert vurdere å bevege seg i retning av Kanban. Men om de foretrekker å gå rett på Kanban er det også greit. Da starter vi alltid med en verdistrømsanalyse, finner flaskehalser og køer, forenkler og så visualiserer vi ende-til-ende prosessen i et Kanban board.

Spotify er som mange lesere vil vite en svært smidig organisasjon som styres etter noen enkle prinsipper og verdier. De har 80-90 team som lager dette produktet, og alle teamene har frihet til å velge prosessmodell. Interessant nok har dette ført til at de har en salig blanding av Scrum, Kanban og “hjemmebrygg”. Noen team foretrekker de ganske stramme rammene og iterasjonene som Scrum gir, andre vil ha mer frihet og flyten til Kanban. Det samme ser vi i de fleste rutinerte, “modne” smidigselskapene.

BEKK forteller i radaren sin at Scrum er for kompleks for de uerfarne og at “det blir mye nytt å lære seg på en gang”. Seriøst? Jeg har jobbet på heltid med Scrum i over 10 år og sett utallige organisasjoner fomle og feile med Scrum i starten –men det har aldri vært på grunn av at rammeverket er vanskelig å forstå. Selv i norske, uerfarne småfirmaer finner vi faktisk veldig smarte folk. Det de fleste sliter med er heller knyttet til endring av tankesett (mindset), firmakultur og at kunden eller ledelsen fremdeles henger igjen i gamle rutiner. Og Agile er langt vanskeligere å forstå godt nok enn det Scrum er.

Jeg møter fra tid til annen svært erfarne, dyktige software-utviklere som fnyser av Scrum. De nyter stor respekt i egen organisasjon og har klart seg utmerket i tiår uten disse seremoniene og strenge iterasjonene. De ser ikke verdien av tett, tverrfaglig teamarbeid og føler ubehag av å stå og snakke i detalj om hva de skal gjøre og hva de har av problemer hver dag. Jeg kan skjønne dette. Jeg kan skjønne at disse foretrekker Kanban, som (i hvert fall tilsynelatende) gir rom for å fortsette som før.

Argumentet om at Scrum medfører overhead er underlig. Det er alltid rom for eksperimentering, optimalisering og å utfordre Status Quo så lenge man gjør dette som team og i lys av en strukturert prosessforbedringsprosess (Scrum retrospective). “Medfører” egentlig et rammeverk noe som helst? Må man ikke uansett selv ta ansvaret for egen prosess?

 

Posted on September 6, 2015 at 3:42 pm by gamsjo · Permalink
In: Scrum · Tagged with: ,

2 Responses

Subscribe to comments via RSS

  1. Written by Johannes Brodwall
    on 07/09/2015 at 7:40 pm
    Reply · WordPress › Error