Hva er nytt i Scrum?

Jeg har tidligere proklamert “Det kommer ingen Scrum 2.0” og det er fremdeles slik jeg tolker herrene Jeff Sutherland og Ken Schwaber. Men det forhindrer ikke at Scrum guiden på Scrum.org nylig fikk en oppdatering. Ingen stor dramatikk i endringen, men enkelte presiseringer og endringer kan være verd og merke seg.

Endringene forklares av Ken selv i denne podcasten. En kortversjon av endringene finner du her.

Jeg synes enkelte endringer er ubetydelige, noen er gledelige og andre kan være mer problematiske. Her følger noen synspunkter.

Gledelig endring

Det er gledelig at Release Planning meeting og Release Burndown nå ikke lenger er en del av Scrum. Dette er gledelig siden det har vært en tendens til at “gammeldagse” prosjektledere har brukt dette som en slags unnskyldning for å ikke release oftere og oftere. En eller annen form for langsiktig planlegging er selvsagt fornuftig, men dette tones altså ned i Scrum Guiden. Teknikker som Road Maps, Minimal Marketable Features, Story Mapping osv kan passe å bruke her, men Scrum skal som kjent ikke inneholde teknikker.

Problematisk

Jeg liker ikke at ordet commitment er erstattet av forecast for Sprint planleggingen. Bakgrunnen er at mange opplever at commitment er et litt for sterkt ord og at en del ledere vil opplever dette som et løfte. I komplekse IT-satsninger er det selvsagt umulig å love noe. Men vi kan love å gjøre vårt beste! Og vi kan jobbe hardt for å rydde unna avhengigheter og usikkerhet slik at vi får tro på Sprinten. Jeg liker å knytte forpliktelse til Sprinten for å være tydelige på at Product Backlog i motsetning til Sprinten ikke kan være en forpliktelse. Enkelt sagt tydeliggjør dette forskjellen mellom Product Backlog og Sprint Backlog. Forecast er jo som i en værmelding en slags prognose over hva vi sannsynligvis vil klare å levere. Helt greit det og, men vi mister da verktøyet for å nyenasere forskjellen på Product Backlog og Sprinten.

Ubetydelige presiseringer

Jeg synes det er en grei presisering at Scrum Teamet nå omfatter produkteier, Scrum Master og utviklingsteamet – the Development Team. Viktig å få fram at PO, SM og utviklerne må fungere som et team.

Helt OK også at burndown chart ikke lenger er mandatory. Andre teknikker kan fungere like fint når det gjelder å holde rede på gjenstående arbeid og hvordan man ligger an.

Bruken av Sprint Backlog er åpnet litt opp. Ikke lenger nødvendig å lage tasks – man kan jo for eksempel velge å bryte ned Sprinten Broduct Backlog Items på en annen måte. Eller ikke bryte ned i det hele tatt.

Product Backloggen er nå ordnet (ordered) i stedet for prioritert (prioritized). Poenget er at den til enhver tid skal ligge i en bestemt rekkefølge som PO har bestemt. Jeg synes denne endringen er ganske ubetydelig og de som vil kan lese Jim Copliens begrunnelse her.

 

 

 

Posted on August 5, 2011 at 5:40 pm by gamsjo · Permalink
In: Scrum · Tagged with: 

7 Responses

Subscribe to comments via RSS

  1. Written by Stein Inge Morisbak
    on 05/08/2011 at 8:29 pm
    Reply · Permalink

    Kult å se at Scrum har evnen til fornyelse, og ikke minst; kult at du blogger om det! Endringene er etter mitt syn vesentlige og i tråd med erfaringer mange (ihvertfall jeg) har hatt med smidig programvareutvikling.

    Jeg er imidlertid litt uenig i måten du kategoriserer endringene i “problematisk” og “ubetydelige”.

    Først “commitment” (forpliktelse). Å bryte en forpliktelse er for de fleste mennesker (håper jeg) et stort nederlag. Samtlige systemutviklere jeg har møtt i min tid er mennesker som ønsker å gjøre en best mulig jobb for sine oppdragsgivere og for sin egen integritets skyld. Har jeg vært heldig? Det er uansett uheldig å utsette mennesker for å bryte forpliktelser de ikke fullt ut er herre over. Å be utviklere om å estimere ca. hvor lang tid noe tar er uproblematisk, men er i beste fall et “forecast”. Å forholde seg til tidsfrister (at noe _må_ være ferdig) er også uproblematisk så lenge man kan justere scope underveis.

    Jeg mener videre at de “ubetydelige” endringene tvert imot er essensielle og viktige å kommunisere til de som sliter med Scrum. Kanskje tydeliggjør det noe de ikke var klar over, men som er ekstremt viktig for å få smidig til å fungere. I prioritert rekkefølge:

    1. Prioritet misforstås ofte som viktighet, noe som vanskeliggjør “ordering” (rekkefølge) . Rekkefølge er udiskutabelt. Denne løses (helt ferdig) før den andre fordi den ligger foran den andre. Ikke av noen annen grunn.
    2. Burndown henger sammen med commitment og skaper bare dårlig stemning fordi scope er bevegelig og estimering sjeldent treffsikkert. Burndown treffer med andre ord sjeldent målpunktet, noe som er demotiverende uavhengig av om det treffer før eller etter. Et task board “kanban style” kan f. eks. funke mye bedre da det viser “work in progress” mye mer eksplisitt og gir en fin følelse av hvilken fremdrift prosjektet har og hva som ligger i pipe-line’en.
    3. Nedbryting er kun viktig hvis man ikke vet eksakt hva man skal gjøre. Bryt eventuelt ned underveis i oppgaven dersom scope øker eller noe er mer komplekst enn hva man trodde. Når dette skjer på et task board oppdages det av alle som kikker på det.
    4. Whole team! Trodde dette allerede var adoptert av Scrum?

    Det er mulig du mener at disse endringene er tydeliggjøringer av ting som allerede praktiseres av Scrum team og derfor kun er nødvendige presiseringer for å gjøre “manualen” komplett og derfor ikke er så viktige. Som nevnt ovenfor har jeg møtt stort sett svært dedikerte og ansvarsfulle utviklere i min tid, men jeg har også møtt en rekke SM’er som skal kjøre Scrum “etter boka”. For disse er dette essensielle presiseringer. Men viktigst selvfølgelig; de må lære seg å lytte til feedback og tilpasse seg endringer i forutsetninger. Presiseringene er imidlertid etter mitt syn basert på dyrkjøpt erfaring fra mange smidigprosjekter og viktige å formidle til de som ikke har så mye prosjekterfaring.

  2. Written by gamsjo
    on 06/08/2011 at 10:18 am
    Reply · Permalink

    Så fint at du er (litt) uenig Stein Inge. Blir kjedelige diskusjoner uten 🙂
    Ord er viktige og bruk av forcast i stedet for commitment har fått eldgamle fronter blant Certified Scrum Trainers til å blusse opp igjen. Veldig mange mener mye forskjellig om dette og det er naturlig. Min posisjon er som sagt at jeg liker commitment bedre enn forecast. Begrunnelsen er først og fremst pedagogisk (jeg holder mye kurs i Scrum).

    For å forklare smidig fokuserer jeg på at Product Backloggen ikke må sees på som en forpliktelse. Det er i denne dynamikken i prosjektet tas opp. Det er her de nye ideene kommer inn. Og den er estimert veldig grovt og gjerne relativt. Når vi starter en Sprint derimot, skal de fleste usikkerhetsmomentene være ryddet unna. Vi kjører Spikes for å være sikre på at vi har forstått. Vi begrenser avhengigheter. Vi kjører jevnlige Product Backlog Grooming møter. Teamet har nå god tro på at de vil klare å realisere det aller meste innen timeboksen. Jeg opplever at de fleste synes dette er motiverende. “Deilig å jobbe etter realistiske planer”. Men så er det selvsagt også viktig å være realistisk (og pragmatisk) i forhold til denne forpliktelsen. Alle vet at det er sjelden en sprint går 100% etter planen. Men 90-95% er kanskje mer normalt for modne team. Jeg har ikke opplevd at team (eller PO) blir synlig skuffet om de blir ferdige med 95%. Husk også at vi også skal ha et sprint mål – og det aller viktigste er å nå dette.

    Jeg synes forecast passer veldig godt på Product Backlog og commitment er helt OK for Sprint backlog. Og jeg er litt bekymret for at dette kan være starten på at selve timeboxen står for fall. Jeg vet jo at mange gjerne vil slippe denne estimeringen og commitmenten og da er ikke veien lang over til Kanban. Kanban er opplagt vellykket for en del, men for nyutviklng har jeg stor tro på timeboxene i Scrum.

    Når det gjelder de andre endringene så kan jeg være enig i at ubetydelige er et for sterkt ord. Men jeg opplever dem som presiseringer av ting som jeg allerede har innarbeidet. Kanskje fordi jeg har oppfattet at det bærer den veien for en stund siden.

  3. Written by Christian Stensholt
    on 19/08/2011 at 10:02 am
    Reply · Permalink

    Har du tenkt noe på norske begreper? Jeg oppfatter at første del av planleggingsmøtet er at scrum teamet forecaster en ordna produktkø fra produkteier. Hva gjør de da på norsk? De lager en prognose – prognostiserer. Noen bedre forslag?

    Etter å ha tenkt litt over endringene synes jeg de er ok. Det jeg har mest problemer med er at resultatet av et planleggingsmøte ikke er et commitment.

  4. Written by gamsjo
    on 19/08/2011 at 4:26 pm
    Reply · Permalink

    Christian, jeg synes også forecast er vrient å oversette direkte. Men dette dreier seg egentlig om estimering og en “kvalifisert gjetning” på hva de vil klare å realisere i sprinten. Eller kanskje det er så enkelt at vi kan bruke ordet “tro”?. “Teamet har tror på at et visst omfang vil bli realisert i sprinten”. En del svakere utsagn enn at teamet forplikter seg..

  5. Written by Ethelyn
    on 04/10/2011 at 12:09 am
    Reply · Permalink

    For å forklare smidig fokuserer jeg på at Product Backloggen ikke må sees på som en forpliktelse. Det er i denne dynamikken i prosjektet tas opp. Det er her de nye ideene kommer inn. Og den er estimert veldig grovt og gjerne relativt. Når vi starter en Sprint derimot, skal de fleste usikkerhetsmomentene være ryddet unna. Vi kjører Spikes for å være sikre på at vi har forstått. Vi begrenser avhengigheter. Vi kjører jevnlige Product Backlog Grooming møter. Teamet har nå god tro på at de vil klare å realisere det aller meste innen timeboksen. Jeg opplever at de fleste synes dette er motiverende. “Deilig å jobbe etter realistiske planer”. Men så er det selvsagt også viktig å være realistisk (og pragmatisk) i forhold til denne forpliktelsen. Alle vet at det er sjelden en sprint går 100% etter planen. Men 90-95% er kanskje mer normalt for modne team. Jeg har ikke opplevd at team (eller PO) blir synlig skuffet om de blir ferdige med 95%. Husk også at vi også skal ha et sprint mål – og det aller viktigste er å nå dette.
    +1

  6. Written by Johannes Brodwall
    on 01/12/2011 at 12:51 am
    Reply · Permalink

    Jo mer jeg tenker på det og ser team i action, desto bedre føler jeg at endringen fra “commitment” til “forecast” er. “Commitment” er, som Stein Inge er inne på, et ord som forplikter. Man vil ikke committe seg dersom man ikke er sikker.

    Men dette kravet om sikkerhet skaper frykt for å feile. Det skaper et ønske om å planlegge for å være sikker på å nå forpliktelsen, framfor å planlegge for å kunne utføre arbeidet. Jeg har også sett at det har ført til en enorm trang til å tvinge produkteier til å gi svar på masse detaljer ved oppstarten av en sprint.

    Dersom vi tenker på det som en forecast og tar dette seriøst, skjer en interessant ting: De utenfor teamet vil ikke lenger kreve sprint-nivå estimater fra teamet. Dersom teamet ønsker å estimere gjør de det for å møte eget behov.

    Teamet klarer så mye som de klarer, uansett hvor mye tid man bruker på å bekymre seg. Når en sprint bare er på 2-3 uker, kan vi heller vente til den er ferdig med å få svaret, framfor å kreve informasjon som ikke har verdi, men som kan skape frykt fra de som skal gi den.

  7. Written by gamsjo
    on 01/12/2011 at 6:23 pm
    Reply · Permalink

    Nei, jeg synes du snur det på hodet her, Johannes. Frykt for å feile er anti-smidig tankegang og dette er noe som må betraktes som en hindring. Om man jobber med komplekse problemstillinger og/eller ønsker å være innovativ så er det maktpåliggende å akseptere at man innimellom vil feile. Dette snakker jeg mye om når jeg holder kurs og når jeg coacher firmaer. Og dette er på en måte tema i all moderne ledelsesfilosofi.

    Men du har selvsagt et viktig poeng når ledelsen tenker “gammeldags” og det ikke er etablert noen slik kultur. Da er det lett å se at det kan være ubehagelig og kanskje til og med demotiverende å stadig bli stilt til veggs med “dere sa jo at dere skulle være ferdig…”.

    Tanken var jo at Scrum og Agile skulle utfordre den rådende tankegangen, men det vil selvsagt ta tid før endring kommer.

    Jeg har fremdeles tro på denne følelsen av forpliktelse, der teamet vil kjempe sammen for å oppnå det de trodde på i starten av sprinten. Det er jo den kollektive interne følelsen av forpliktelse i teamet vi er ute etter – ikke lovnader til omgivelsene!

Subscribe to comments via RSS

Leave a Reply