Det er oppe i tiden at diskutere skalering af Scrum og andre agile metoder til helt store virksomheder (f.eks. skal Tony Grout tale om det til GOTO København). Det var nemt for mig at relatere til da jeg var Scrum Master hos LEGO, men mindre nemt at relatere til nu hvor jeg er en del af en lille gruppe på 2 mand i en startup-virksomhed. Nu er spørgsmålet for mig snarere hvordan man plukker og gentænker Scrums gode elementer, så det virker, når man ikke er helt mange nok til et traditionelt Scrum-Team.
Baggrundshistorien: Min bedre halvdel og jeg arbejder på et lille værktøj til at holde styr på ens favorit-links. Nu er det ikke fordi der er mangel på bookmarking-sites og værktøjer, hvor bookmark-organisering er indbygget (din browser er et fint eksempel), men vi har ikke fundet et værktøj som kan lige det vi gerne vil have, så derfor bygger vi vores eget med fokus på at kunne dele bookmarks med andre, god søgning og en UI som ikke ligner noget fra 2010.
Hvordan får vi så Scrum til at fungere for vores lille “team”? Nogle elementer ligger lige for – hver dag snakker vi om hvad vi skal lave den dag, hvad vi har lavet dagen før og hvilke problemer vi har. Det sker mindst en gang i starten af dagen, men fordi vi kun er to, gør vi det langt oftere. Lige så snart en af os render ind i et problem, snakker vi sammen for at løse det. Daily standups funktion er altså dækket.
Vores product backlog er et Trello board. Vi startede ud med at diskutere visionen for produktet hele tiden (det gør man jo ofte i et nyt projekt), men nu hvor vi har været i gang i nogle måneder, så har vi fundet ud af at vi er nød til at gøre det fast, hvor ofte vi (mindst) skal have en visions-snak.
Som det er nu har vi kun lukket 20 brugere ind i vores lukkede beta, men feedback fra disse brugere er med til at trigge sådan en visions-snak. Hvis ikke vi har haft en visions-snak i en uges tid, så tager vi den på eget initiativ. Visions-snakken betyder ofte en revidering af vores product backlog og den kan være med til at gentænde vores passion for produktet (så den ikke mistes mens man sidder og nørkler for længe med en lille detalje). Denne visions-snak er vores backlog refinement (grooming) og feedback loop. Vi har endnu ikke meget data om vores brugeres opførsel at kigge på, men med tiden og flere brugere, skulle vi også gerne blive data-drevne i vores visions-justeringer.
Vi bruger lang tid på brugerfeedback og ikke mindst på at diskutere, hvor og om vores brugeres feedback passer med vores vision og i tilfælde hvor der er forskel, så diskuterer vi om det er vores vision der skal justeres eller om det er bruger-feedbacken, som vi skal afvise høfligt. Vi er så taknemmelige for alle som gider at komme med feedback at det er noget hårdt at afvise den samme værdifulde feedback med henvisning til at det ikke er det produkt vi gerne vil lave.
Vi har som sådan ikke fast-længde sprints, da vi betragter hver færdig opgave som en anledning til potentielt at holde demo, planlægning og retrospective. Vi releaser, når en feature er færdig eller når en bug er fikset.
Demo har vi delt op i to. Selvfølgelig demoer man for den anden, men vi har også bestemt at vi for de fleste større features laver GIF’er af funktionaliteten, og dermed demoer til hele verden gennem et tweet af denne GIF på vores produkts twitter-konto. Det hjælper os med at få fuldstændigt afsluttet en feature for man kan ikke lave en GIF af en halvfærdig feature og det giver en naturlig opdeling af opgaver, da vi sådan sikrer at en opgave rent faktisk giver brugerne værdi – ellers ville det være pinligt at tweete om det.
Planlægning er ikke kompliceret, når man kun er to, product backloggen er ofte opdateret og man ikke skal fylde en masse opgaver ned i et sprint. Det er den simple opgave at tage et kig på product backloggen og tage en hurtig snak om hvorvidt den opgave der står øverst stadig er den vi synes det giver mest mening at gå i gang med eller om der er nogle bugs som er vigtigere. Det gør vi så hver gang vi starter på en ny opgave.
Retrospectives bliver nødvendigvis mere uformelle, når man kun er to. Vi har fundet ud af at der er to ting der er rigtigt vigtige for os. Allerførst den praktiske vinkel i dagligdagen, hvor man mens man løser en opgave, tænker hurtigt over om der er noget at lære fra den. Den samtale har vi ofte løbende, men også når opgaven er helt færdig. Evigt fokus på ikke at begå den samme fejl igen og igen. Det andet fokus som er vigtigt for os er den mere langsigtede. Er vi glade for den måde vi arbejder på? Skulle vi lige stoppe midlertidigt med at lægge features ud for at fokusere på at forbedre en arbejdsgang? Hvordan forbedrer vi vores samarbejde? Er vi glade? Hvorfor/hvorfor ikke? Er der noget særligt som skal roses eller fejres? Vi tager ofte den langsigtede snak over en frokost ude i byen, så vi ikke kan komme til at sidde og kigge i computeren.
Rollerne i Scrum er mindre nødvendige i et to-mands-team. Det er simpelthen nødvendigt at samarbejde om alt. Product Owner, Scrum Master, tester, UX’er og almindelig udvikler er os begge to, og vi har ikke fundet nogen fordel i at fordele hattene. Der er måske en der tager lead på en bestemt rolle i en bestemt situation, men vi hjælpes ad med det hele.
Vores omstændigheder gør at vi ikke har brug for burn-down charts og deadlines og det er heldigt for vi har helt droppet estimering udover den hurtige gut-feel-vurdering af om det er en stor eller en lille opgave, som hjælper os med at prioritere. Det er ellers ikke aktiviteter som vi synes giver os nogen værdi i vores lille projekt.
Det er såmænd sådan vi skalerer Scrum – altså nedskalerer.