Serum er ikke en forkortelse for noe slik mange kanskje tror, men er opprinnelig et begrep som kommer fra idrettens verden. Nærmere bestemt beskriver serum en rugbyformasjon som brukes for å få spillet i gang igjen etter en spillestopp. I prosjektsammenheng er det Ken Sehwaber og Jeff Sutherland som ble kreditert opphavet til metodikken og rammeverket. Det skjedde i 1995 på den årlige forsknings- og programvareorienterte OOPSLA-kongressen.
Interesseorganisasjonen Serum Allianee (SA) beskriver serum som en innovativ tilnærming til å få gjort unna arbeid. Selv om både opphav og utbredelse hele tiden har vært størst innen systemutviklingsmiljøer, hevder SA at serum-rammeverket også fint kan benyttes til helt andre typer prosjekter og arbeidsoppgaver. Dette skal være mulig fordi rammeverket er lite, lettfattelig og samtidig fundamentert på følgende fire verdier (oversatt fra Agile Manifesto );
"Personer og samspill fremfor prosesser og verktøy,
Programvare som virker fremfor omfattende dokumentasjon, Samarbeid med kunden fremfor kontraktsforhandlinger, Å reagere på endringer fremfor å følge en plan"
Sutherland og Sehwaber (2007) skriver at serum ble designet for å øke energi, fokus,
tydelighet og åpenhet til prosjektplanleggingen og implementeringen. Fordelene med serum hevder de er raskere utviklingstid, samkjøring av individuelle og virksomhetens mål og utvikling aven prestasjonsbasert kultur. Metoden støtter opp om interessentenes
verdiskapningsønsker, det er en stabil og konsistent måte å kommunisere prestasjon på tvers av virksomheten og den bidrar til personlig utvikling og økt livskvalitet.
Siden serum-teamene selv velger hvor mye og hvordan arbeidet best bør løses, mener Sutherland og Sehwaber (2007) at Serum-rammeverket først og fremst bidrar til høyere produktivitet, kvalitet og et bedre arbeidsmiljø. Serum fokuserer hele tiden på verdi for
virksomheten og kundene, og funksjonalitetsønsker og forbedringer prioriteres hele tiden utfra dette. Oppgaver som ikke bidrar med verdiskaping for kunden eller mottaker av produktet, nedprioriteres. Sutherland og Sehwaber (2007) kaller serum et "inspeet and
adapt"-rammeverk, med leveranser av kjørbar kode etter hver Sprint (timebox). Hver Sprint kjøres vanligvis som 30 dagers iterasjoner, noe som bidrar til at serum-rammeverket er veldig tilpasningsdyktig etter hvert som virksomheten og kundene endrer prioritering.
Selve serum-rammeverket består av 3 kjerneroller, 4 ulike møter og 3 dokumenter (Sutherland og Sehwaber (2007».
Produet owner (PO) representerer virksomheten og interessentene. PO er kundens stemme og er ansvarlig for at Serum Teamet leverer verdi tilbake til virksomheten. Vedkommende er også ansvarlig for å beskrive ønsket funksjonalitet og prioritere disse inn i dokumentet Produet Baeklog. PO sørger for å holde Produet Baeklogen
a
jour og prioritert foran enhver sprint. Alle serumteam skal være tilknyttet en PO, som har myndighet til å akseptere eller forkaste utført arbeid av Serum Teamet. Det er PO som arrangerer og fasilitererplanleggingsmøtene.
SerumMaster (SM) er en fasilitatorrolle. Vedkommende skal sørge for at Serum Teamet fungerer så optimalt som mulig. SM er et bindeledd mellom Serum Teamet, PO og andre aktører. Hovedoppgavene til SM er å fjerne hindringer for Serum Teamet, skjerme teamet for forstyrrelser og avbrudd utenfra, samt å påse at selve serum-prosessen følges. SM er ansvarlig for innkalling til daglige serummøter, sprint review og planleggingsmøter.
Serum Teamet (ST) bør bestå av 5-9 medlemmer. ST bestemmer hva som skal være mål for kommende Sprint og forplikter seg til å gjennomføre dette etter beste evne. ST har ansvar for å presentere utviklet løsning for PO før neste sprint. ST skal være så selvorganiserende som mulig da det ikke er noen teamlederrolle i serum. Innad i teamet velges oppgaver fritt. Siden arbeidsoppgavene i en Sprint ofte er mange og forskjellige (for eksempel analyse, design, utvikling, testing, kommunikasjon, markedsføring, ete), er ST av natur ofte tverrfaglige med representanter fra ulike avdelinger.
Daglig serummøte er, som navnet tilsier et daglig møte. Hensikten er å informere og bli informert om status innad i teamet. Hvert av teammedlemmene svarer i tur på følgende 3 spørsmål; Hva har du gjort siden i går? Hva planlegger du å gjøre i dag? Har du støtt på noen problem som er til hinder? Håndtering av eventuelle hinder fasiliteres av SM, og det gjøres utenfor de daglige serummøtene, ofte i etterkant. Møtet er åpent for alle, men bare
teammedlemmene har talerett. Møtet starter presis, skal ikke overstige 15 minutter, og avholdes fortrinnsvis til samme tid og på samme sted.
Sprint planleggingsmøte er et todelt heldagsmøte som arrangeres i begynnelsen av hver Sprint. Hensikten med første del er å velge ut funksjonalitet og eventuelle endringer fra den
prioriterte Product Backlogen som det skal arbeides med i kommende Sprint. En essensiell aktivitet her er å kommunisere planlagt fravær og tilgjengelig kapasitet til hverandre slik at både PO og ST har en felles forståelse seg imellom om hva som er realistisk å få gjort. Her deltar PO og ST.
I andre del av planleggingsmøtet er PO fristilt. Han kan delta ved behov, men har ikke talerett utover å skulle svare på eventuelle spørsmål og avklaringer som ST måtte ha. I denne delen brytes funksjonaliteten ned i konkrete arbeidsoppgaver som estimeres og danner en Sprint Backlog. Sprint Backlogen er det settet med arbeidsoppgaver som ST forplikter seg til å gjennomføre i løpet av kommende Sprint.
Sprint review avholdes helt mot slutten av Sprinten og skal ikke overstige fire timer. Målet med møtet er at ST går gjennom arbeidsoppgavene som ble fullført og eventuelt oppgaver som ikke ble fullført og derfor måtte skyves tilbake til en eventuell senere Sprint. ST presenterer deretter løsningen de har jobbet med inneværende Sprint og interessentene får komme med innspill og tilbakemeldinger.
Sprint retrospective er det siste møtet i en Sprint. Hensikten med dette møtet er å reflektere og lære av gjennomføringen av Sprinten som går mot slutten, hensikten er kontinuerlig
prosessforbedring. Hovedspørsmålene som møtet sentrerer rundt, og som alle
teammedlemmene svarer på er: Hva gikk bra i Sprinten? Hva kan vi forbedre i neste Sprint?
Resultatet av møtet er det opp til SM å ta videre og fasilitetere for bedre gjennomføring og produkti vitet.
Product backlogen er en liste med alt som interessentene ønsker seg av produktet.
Dokumentet lever så lenge prosjektet lever. Alle kan bidra, men PO har redaktøransvaret for listen og prioriterer den utfra hva han mener bringer mest verdi for kundene eller
virksomheten. Listen er grovt estimert av ST.
Sprint backlogen er ST sin arbeidsliste for neste Sprint. Den består av spesifiserte ønsker fra Product Backlog og er finestimert. For at detaljeringsgraden skal bevares, anbefales det at utgangsestimatene er mellom 1-16 timeverk. Oppgavene i Sprint backlogen plukkes fritt av medlemmene i ST, potensielt skal alle kunne gjøre alt, selv om det ofte vil være oppgaver som faller mer naturlig til noen enn andre. Selvorganisering og forpliktelse er suksessfaktorer for vellykket gjennomføring. Sprint Backlogen eies av ST.
Burndownchart er et enkelt dokument, ofte en graf, som visualiserer gjenstående arbeid i Sprint Backlogen. Den bør oppdateres hver dag og gir et raskt overblikk over fremdrift og status i Sprinten. Avvik på grafen er lett synlig og muliggjør raskere korrigerende tiltak for å komme i rute igjen.