Introduktion

Jeff Sutherland er en af ophavsmændene til Scrum-metoden, som der arbejdes efter mange steder, hvor man arbejder med især digital udvikling og software. Dette er min anmeldelse af hans bog om emnet (‘Scrum: The Art of Doing Twice the Work in Half the Time’ fra 2014).

Hvis du allerede ved, hvad Scrum går ud på og kender dets metodik, rytmer og ophav, kan du hoppe direkte til selve anmeldelsen herunder. Hvis ikke, følger her en intro til Scrum-universet: ?

Don’t Go Chasing Waterfalls

Scrum er det, man kalder en agil metode. Det betyder, at man løbende forsøger at tilpasse produkt og proces til omstændighederne. Den agile disciplin er i meget høj grad opstået som en reaktion på den klassiske projektledelse, hvor man først beskriver noget, herefter designer det for derefter at bygge og lancere det.

Den model kaldes “vandfaldsmodellen”, fordi man passere flere lag i vandfaldet, så at sige. Men den metode fungerer ikke – af flere årsager. Blandt andet fordi man aldrig kan forudsige, hvad der er behov for, lige meget hvor mange stakke af A4-papirer, man fylder med kravspecifikationer og lignende. Der vil altid være forandringer – og det vil påvirke både pris og leveringstidspunkt. Det er blandt andet derfor, så mange store IT-projekter ender galt (du kender sikkert en masse eksempler).

Et andet problem er, at processen aldrig løber én vej. Der vil altid dukke et eller andet op, som skal løses i de tidligere “lag”. Ofte kan det være en udvikler/programmør, der opdager at noget i designet ikke kan bygges, eller at det kan gøres smartere på en anden måde. Så skal der en opgave tilbage til designeren, og det tager hverken vandfaldsmodeller eller klassiske projektprocesser højde for. Her er man nødt til at være agil.

“Don’t Go Chasing Waterfalls”, som TLC sang i midt-1990erne.

Scrum og de andre agile discipliner henter deres ophav i Toyotas produktionssystem, beskrevet i ‘The Toyota Production System’ af Taiichi Ohno fra 1988, der blev til ‘Lean Manufacturing’ i USA.

Han udviklede systemet (ifølge Wikipedia) sammen med Eiji Toyoda i årene 1948 til 1975. Jeff Sutherland beskriver i sin bog, ‘Scrum’, hvordan japanerne udviklede deres tilgang på baggrund af (sjovt nok) en amerikansk tilgang, som blev præsenteret for dem i 1950 af W. Edwards Deming. Han arbejdede for general Douglas MacArthur under den amerikanske besættelse af Japan efter Anden Verdenskrig.

Deming præsenterede blandt andet japanerne for den såkaldte ‘PDCA-cyklus’. Det står for Plan, Do, Check, Act – og det er grundlæggende den cyklus, man konstant løber igennem, når man arbejder agilt. Derved sikrer man, at man konstant er på rette spor – og at det man bygger, både er efterspurgt og fungerer.

Hvad er Scrum?

I 1993 definerede Sutherland således, sammen med Ken Schwaber, det vi i dag kender som Scrum. I hovedtræk:

Sprints

Scrum handler primært om teams, der arbejder i “sprints”: Et sprint er et kort tidsinterval (typisk to uger), hvor holdet arbejder på en del af produktet. Arbejder man i software-branchen, handler det om at bygge brugbart software i hvert eneste sprint. Hver dag i et sprint holder man et stående møde på maksimalt 15 minutter, hvor de enkelte teammedlemmer taler om, hvordan det går. Det byggede bliver vist frem ved en åben demo ved sprintets afslutning, og herefter reflekterer teamet og sætter gang i det næste sprint.

Demoen er med til at sikre, at A) der bliver bygget noget, der virker og B) det er håndgribeligt for produktejere/bestillere og andre, hvad der er blevet lavet.

Scrum Master

Et team består, udover teammedlemmerne (der udfører arbejdet) af en ‘Scrum Master’. Det er denne person, der blandt andet står for de daglige møder og sørger for, at eventuelle forhindringer, som teamet måtte opleve, bliver fjernet.

Ved hvert eneste daglige møde spørger Scrum Masteren de enkelte teammedlemmer (direkte oversat fra Sutherlands bog):

1. Hvad lavede du i går for at hjælpe teamet med at færdiggøre sprintet?
2. Hvad vil du lave i dag for at hjælpe teamet med at færdiggøre sprintet?
3. Er der noget, der forhindrer dig eller teamet i at nå sprintmålet?

Product Owner og backlog

Den eneste rolle, der derudover har en definition, er ‘Product Owner’. Som titlen afslører, er det den person, der ejer produktet. Det vil sige, at han/hun kender til markedet, forretningen – og kan sætte sig ind i situationen for den/de personer, I bygger produktet for. Sutherland skriver:

“When you’re picking a Product Owner, get someone who can put themselves in the mind of whoever is getting value from what you’re doing. As a friend of mine says, ‘My wife is the perfect Product Owner; she knows exactly what she wants. I just Implement it’.”

Det er også Product Owner’en, der ejer “backloggen”. Det er den (prioriterede) liste af ting, der skal laves i forbindelse med et givent produkt eller projekt. Når et nyt sprint sættes i gang, finder teamet sammen med Scrum Master og Product Owner ud af, hvad der er realistisk at nå.

Product Owner’en skal udforme det, Sutherland kalder en vision for produktet (‘Product Vision’), der er kombinationen af

• det, der kan implementeres,
• det, der kan sælges og
• det, man kan have passion for.

“[A] vision with a real possibility of becoming something great”, som han skriver.

Hele backloggen for et produkt/projekt behøver dog ikke være lavet for, at arbejdet er færdigt. Det er hele pointen ved, at man arbejder oppefra og ned igennem den prioriterede liste.

En vigtig pointe omkring Product Owner-rollen er, at når et sprint starter og arbejder mod det aftalte sprintmål, så har vedkommende ikke mere indflydelse. De næste to uger (eller hvor lang tid, man nu sætter af til sine sprints) er det med andre ord teamet, der bestemmer, hvordan opgaven skal løses. Product Owner står for hvad og hvorfor.

User Stories

Backloggen kan være sammensat af ‘User Stories’. Det er (som navner siger) små historier, der beskriver en given ting, som en bruger skal kunne gøre i/med produktet. De følger en fast formel:

Som [A] vil jeg være i stand til at kunne [B], så jeg kan [C].

Sutherland giver et eksempel med et firma, der bygger teknologi til styring af hjemmet:

“As a home owner, I want to be able to see who is at my door, so that I can open the door only for those people I want to come in.”

Brug points i stedet for timer

Her udvælges opgaverne fra backloggen, hvor de kan være beskrevet i forskellige grad og med et estimat. Sutherland anbefaler, at man ikke estimerer i timer (“people are absolutely terrible at that”). Han anbefaler i stedet, at man arbejder efter Fibonacci-skalaen, når man skal vurdere en opgaves størrelse. Talrækken ser således ud: 1, 2, 3, 5, 8, 13, 21 og så videre. Det særlige ved den skala er, at et givent tal er summen af de to foregående tal (for eksempel 5+8=13).

Formålet ved at bruge Fibonacci-skalaen er, at man ikke står og diskuterer om en given opgave nu er en 8’er eller en 9’er. I stedet er det en 8’er eller en 13’er, og Sutherlands argument er, at det spring gør det lidt lettere at skelne de forskellige størrelser fra hinanden. Jeg har hørt om nogle, der bruger T-shirtstørrelser (small, medium, large, extra-large og så videre), og hvis det fungerer, er det det, man gør.

Det har dog en klar fordel at bruge Fibonacci-tallene. De omsættes nemlig til points, som man så bruger, når man skal udregne teamets “velocity” efter hvert sprint. Herved finder man ud af, hvor meget arbejde, teamet kan udføre per sprint – og det kan man bruge i sin planlægning.

Her er det så Scrum Master’ens opgave at sørge for, at det tal stiger. Scrum arbejder (naturligvis) også med ‘Continuous Improvement’ (altså løbende forbedring), og her er det vigtigt at man ved slutningen af hvert sprint får kigget tilbage i et ‘Retrospective’-møde og får fundet ud af, hvor der er plads til forbedring. Det handler om processen og ikke menneskerne i teamet.

Åbenhed

En anden vigtig ting ved Scrum er, at der lægges vægt på at gøre arbejdet synligt og gennemsigtigt. Det mest iøjnefaldende ved dette er formentlig Scrum-board’et, som teamet opdaterer igennem sprintet. Mange steder bruger man software, og det kan hurtigt blive en religionskrig, om man skal bruge software eller have et fysisk board.

Jeg vil mene, at der ligger en klar styrke i det sidste.

Åbenheden er også det, der gør, at demonstrationen ved slutningen af et sprint er åben.

Anmeldelse af bogen

Op af skyttegravene

Allerede i starten af bogen gør Sutherland det klart, hvad det er, han vil gøre op med: Udviklingsarbejde i vandfald, som det kendes fra den klassiske projektlederdisciplin.

I den forbindelse serverer han en ret fantastisk formulering, som jeg overvejer at få trykt som en plakat (i traditionel projektledelse arbejder man nemlig typisk med de såkaldte ‘Gantt-skemaer’, opkaldt efter manden, der opfandt dem):

“Henry Gantt invented his famous charts around 1910. They were first used in World War I by General William Crozier, who was the Chief of Ordnance for the US Army. Anyone who has studied that war knows that efficient organizational capability was not exactly a salient feature. Why a World War I artifact has become the de facto tool used in twenty-first-century project management has never been quite clear to me. We gave up on trench warfare, but somehow the ideas that organized it are still popular.”

Der er faktisk et andet eksempel fra den krig, som Sutherland dog ikke bruger. Tyskerne arbejdede nemlig efter den berømte/berygtede Schlieffen-plan. Kort fortalt gik den ud på, at for at undgå en tofrontskrig med både Frankrig og Rusland skulle de tyske tropper forholdsvis hurtigt eliminere franskmændene og derefter koncentrere sine styrker ved grænsen mod Rusland.

Schlieffen-planen afhang dog af en række faktorer, hvilket betød at de tyske tropper i tiden umiddelbart efter krigsudbruddet i 1914 nærmest arbejdede efter en timetabel, der dikterede hvornår hvad skulle være klaret. Og derfor blev det et problem med mere vidtrækkende konsekvenser, da belgierne viste sig at gøre modstand og ikke blot lod sig tromle over.

Det er måske et lidt stretched eksempel, men det er den samme trang til at planlægge alt på forhånd, de agile tilgange som Scrum søger at gøre op med. Og det ville på ingen måde være et eksempel, der stak af fra de eksempler, Sutherland ellers har taget med i sin bog. Mere om det senere.

Sutherland gør meget ud af at fortælle om ophavet til Scrum. Det sætter jeg enormt stor pris på, for det giver mig som læsere en mulighed for at sætte mig ind i hans tanker og perspektiver. Det betyder også, at man kan gå et par trin tilbage i “fødekæden”, hvis man har lyst til det. Jeg har for eksempel ikke fået mindre lyst til at læse ‘The Toyota Production System’ efter at have læst ‘Scrum’.

Herefter tager han fat på teams og fortæller lidt om, hvorfor det er så vigtigt at arbejde i teams – samt sætter nogle regler for størrelsen (3-9 personer i et team, lyder anbefalingen). Han fortæller også, at teams selvfølgelig skal være sammensat, så de kan løse opgaven fra start til slut. Det vil sige, at hvis man har designere og udviklere ansat, så er de repræsenteret i hvert team. Det nedsætter antallet af afhængigheder og betyder, at teamet lettere kan nå i mål.

Vi kommer også forbi “waste” (spild), som både Toyota-systemet og senere Lean-bevægelsen bekæmper med næb og kløer.

Jeg nød dog især kapitlerne om planlægning og prioriteter.

Jeg tror ikke, der findes nogen, der elsker at estimere hvor mange timer, de skal bruge på en opgave, for derefter at registrere hvor meget tid, de har brugt på den pågældende opgave. Her anbefaler Sutherland, at man i stedet arbejder med points efter Fibonacci-skalaen (læs mere om at bruge points i stedet for timer herover ☝️), som skal gøre det lettere at estimere opgaverne i mere grove træk. Det betyder, at man samtidig kan måle sin hastighed (“velocity”) i disse points i stedet for i timer, som dels er en voldsom usikker enhed og dels kan virke ikke så lidt stressende.

Det var også interessant at læse om ‘Planning Poker’, hvor teamet sammen estimerer opgaverne ved at spille kort og derved blive enige om, hvilke opgaver, der kræver hvor meget arbejde – igen i nogenlunde grove estimater.

Brugeroplevelse?

En ting, der dog fylder meget lidt i Sutherlands bog (faktisk nærmest intet) er arbejdet med brugeroplevelsen, ‘UX’. Det er lidt ærgerligt, for det er netop kombinationen af UX-arbejdet med agile discipliner, der volder folk en del hovedpiner.

Nogle vælger at lade UX-folkene arbejde et sprint foran (det der kaldes ‘Parallel UX’, som du kan læse mere om hos IT-Universitetet) for at kunne være på forkant med bruger-interviews, research etc. Andre er fortalere for en hyppig (nærmest konstant) dialog imellem Scrum-teamet og dem, der arbejder med UX.

Kvalitetssikring?

En anden problemstilling, som nok er for specifik til at få en plads i Sutherlands mere generelle bog, er den udfordring som en tilgang som ‘Continuous Integration’ medfører. Som Jeff Gothelf skriver i sin (korte) bog, ‘Lean vs. Agile vs. Design Thinking’:

“Perhaps nothing has had more of an impact on how code is written and delivered in the last five years than the DevOps movement. Without getting too technical (I’m not, after all, a software developer), DevOps allows companies to ship code to customeres in a continuous state. Launching a new piece of code becomes a non-event. It is something that happens every day and, in a growing number of companies, many times per day. As easily as an organization can launch new code, it can roll it back, tweak it and launch it again.”

Dette kan have enorm betydning, når man arbejder med udgivelser hver anden uge. Igen; det er for specifikt til at have med i bogen i uddybet form, men det kunne have været berørt som noget, man skal være opmærksom på.

Der står heller ikke meget direkte om kvalitetssikring (Quality Assurance, QA), som er noget, der fylder meget, når man bygger software. Det handler kort fortalt om at sikre, at man er sikker på, at det man lancerer fungerer.

Sutherland adresserer det ved, at han understreger, at det er enormt vigtigt, man har en “Definition of Done”. Altså, det vil sige: Hvordan kan vi teste/verificere dette, så vi ved, at det fungerer, som det skal, og at opgaven reelt er færdig?

Alligevel er der dog flere, der vælger at sætte personer til at arbejde direkte med QA. Som du kan læse i Wikipedia-artiklen om Scrum:

While the Scrum Guide prescribes the essential elements of Scrum, it seems that many companies deviate significantly from it. The least variation is in the sprints and sprint length, events, team size and requirements engineering. The most variation can be found in the roles, effort estimation and quality assurance.

Og en hurtig Googling førte mig til denne InfoQ-artikel, hvor en person deler sine erfaringer efter at have arbejdet med QA i Scrum i to år:

After working for nearly two years as a quality assurance (QA) analyst on a Scrum team, I have learned that the role of QA in Scrum is much more than just writing test cases and reporting bugs to the team.

I det første afsnit af ‘Agile Toolkit Podcast’ (som er fra 2005), kan du høre Bob Martin [Wikipedia] tale om de grundlæggende krav for at arbejde agilt – og her er test centralt, blandt andet for at sikre kvaliteten (netop “Definition of Done”). Han taler om, at QA-folkene bliver ‘specifiers’ i stedet for ‘verifiers’.

Dette er ikke for at afvige for meget fra min boganmeldelse. Det er for at sige, at dette er noget, som mange har arbejdet og eksperimenteret med i mange år – og som Sutherland ikke adresserer i sin bog.

Let læselig… med “interessante” eksempler

Bogen er let at læse, både hvad angår sprog og længde. Sutherland skriver godt, og der er en hyppig inddeling i underafsnit, der gør, at du ikke behøver sætte hele aftenen af til at læse et helt kapitel for ikke at holde pause midt i noget interessant.

Min største anke mod bogen er nok de eksempler, han bruger. Det hører med til historien, at Sutherland er en ældre herre, der har fløjet missioner over Vietnam, og hans baggrund og historie er medvirkende til, at der er mange militære eksempler. Det er egentlig okay, for et lands hær er et af de steder, hvor det er allervigtigst, at organisationen og dens arbejde bare fungerer.

Men… man kunne måske have fundet bedre eksempler på at mangle fokus end tyskernes svar af hele den franske kystlinje op til den allierede landgang i Normandiet.

En anden ting (sådan er det nok med denne slags bøger) er, at der kun er solskinseksempler med. Du hører om alle dem, der skiftede til Scrum og nærmest reddede forretningen, måske hele verden på sigt. Jeg savner lidt at høre om de eksempler, hvor Scrum måske ikke lige var den oplagte løsning, men hvor man med små tweaks (eller et bedre implementeringsarbejde) fik det løst.

Der må også være eksempler og steder, hvor Scrum bare ikke er den meste oplagte måde at gøre tingene på. Hvis man for eksempel arbejder på en ren bestilling eller lignende. Det hade været rart med de eksempler, så man ikke sidder med en bog, der forsøger at overbevist en om, at Scrum kan bruges til alt.

Det var dog spændende at høre om ‘eduScrum’ i slutningen af bogen, som de bruger i Holland. Eksemplet i bogen er et kemihold i et gymnasium, der lærer og arbejder efter principperne fra Scrum. Det fik mig til at tænke på mine kemitimer (som kun var spændende, når noget røg), og at Scrum faktisk har nogle rigtig gode muligheder, hvad angår uddannelse. Det lyder meget interessant.

Kort fortalt

Denne bog er en god introduktion til Scrum – så start med at læse den, hvis du ikke ved, hvad Scrum går ud på, eller du ved noget (eller måske er i tvivl om, at du ved det rigtige). Her er den virkelig god.

Bogen lander dog lidt imellem to stole, hvis du køber den for at få en “hardcore” introduktion til Scrum, og i det tilfælde kan du faktisk overveje at starte med Sutherlands appendiks bagerst i bogen (som egentlig mere er en ‘to do’-liste til dem, der vil i gang med Scrum).

Hvis du vil et spadestik dybere og i gang med at skrue på roller, processer etc. i Scrum, er der formentlig andet litteratur, der hjælper dig bedre.

Tilmeld dig mit nyhedsbrev, så får du flere artikler som denne – og et solidt overblik over nye medier og digital udvikling:

↓

Links

# Læs mere om Scrum på Wikipedia

# Læs mere om Taiichi Ohno på Wikipedia

# Læs mere om Toyota Production System på Wikipedia

# Læs om Parallel UX hos IT-Universitetet

# Læs om en QA’ers erfaring med Scrum [InfoQ / 17. juli 2012]

# Lyt til første afsnit af ‘Agile Toolkit Podcast’ [fra august 2005]