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 · Permalink

    En øvelse jeg har gjort med et par grupper som sier at Scrum ikke er tingen for dem:

    * Føler dere at de utenfor prosjektet er komfortable med det dere gjør og gir tilbakemeldinger? Nei? Når viste dere sist fram det dere lager?
    * Vet alle hvilke oppgaver de skal jobbe med? Nei? Det er i en blanding av emails, muntlig, word dokumenter og issue-tracker? Har dere vurdert å lage en prioritert liste?
    * Føler dere at teamet er enige om hva som skal til for å bli bedre? Har dere snakket om det nylig?
    * Vet du hva de andre driver med? Når delte dere sist fremdrift mellom dere muntlig?
    * Hvem har siste ordet om hva som er viktigst? Ingen?

    Cirka her ser de jeg snakker med at vi har vært gjennom halvparten av Scrum og at de har problemene Scrum skulle løse. (Så tar vi med dedikert kryssfunksjonelt team, planlegging og scrum master, og så snakker jeg ikke så høyt om grooming og sprint backlog og så er vi der…)

    Scrum er ikke riktig for alle, men alle burde sjekke om de har problemene Scrum adresserer. De 10 grunnelementene er en fabelaktig sjekkliste.

  2. Written by gamsjo
    on 08/09/2015 at 8:24 pm
    Reply · Permalink

    Herlig Johannes! Takk.

    Jeg hadde folk på kurs i dag som har brukt Scrum i mange år, men fullstendig uten disiplin. De har ikke hatt fast sprintlengde, eller Definition of Done, de har hatt en Scrum Master som sitter med eierskapet hele teamet kunne hah hatt, en usynlig PO, og ingen grooming. Halvhjertede retroer. De fikk en rad med a-ha-opplevelser på kurset og uttaler omtrent det du sier om at problemene og frustrasjonen de har opplevd i flere år lett kan relateres til manglende Scrum forståelse og -disiplin.

    Jeg kommer stadig tilbake til at det er lurt å ta hele kuren i starten. Når man så behersker Scrum godt, kan man begynne å eksperimentere og se om man virkelig trenger alt sammen.

Subscribe to comments via RSS

Leave a Reply