Enkelte arbeidsoppgaver innen produktutvikling skaper verdi direkte. Å rette en feil i prod er for eksempel noe som ofte kan observeres og som åpenbart har verdi. Det å lage synlig funksjonalitet som gir målbar forretningsverdi likeså. Enkelte ganger lager vi systemer som synliggjør arbeidet, selv om det ikke skaper verdi direkte. Eksempler på dette er å fullføre et dokument, en plan eller kanskje det å nå en milepæl på veien ut i prod. Felles for slikt arbeid er at det blir verdsatt høyt.
Andre arbeidsoppgaver er mer indirekte i sin verdiskapning. Dette er tekniske, organisatoriske eller menneskelige investeringer vi gjør for å forhåpentligvis kunne høste fruktene av i framtiden. Det er viktig å ta med forhåpentligvis her siden slike ting som regel er befestet med stor usikkerhet og kan være veldig vanskelig å måle effekten av. Slikt havner i stor grad i Complex domenet i Cynefin, der det ikke finnes løsninger av typen “beste praksis”.
Scrum Master jobben består nesten utelukkende av arbeid som skaper effekter indirekte, en gang i fremtiden. Disse effektene vil alltid være vanskelig å måle med stor grad av kausalitet.
Så la oss se litt nærmere på hva en Scrum Master faktisk gjør.
En Scrum Masters oppgaver
I starten, når man innfører Scrum eller skal i gang med et nytt Scrum team, vil en Scrum Master være svært aktivt engasjert i teamet. Da gjelder det å lære opp alle i Scrum (og agile/smidig) og å sørge for at vi lager velfungerende spilleregler (avtaler, “working agreements”) for teamet. I denne fasen vil Scrum Master aktivt fasilitere Scrum Eventene og være pådriver for å innarbeide Scrum. Alt dette kan oppleves som ganske direkte verdiskapende siden de fleste team opplever mestring og at ting “faller på plass”. Men denne fasen er snart over og det er da den virkelige jobben begynner. Da dreier alt seg om prosessforbedring — og skape fart og flyt i arbeidet. Dette betyr i Scrum
– å fjerne hindringer for teamet og
– å sørge for at teamet utnytter iterasjonene til å lære av erfaring.
Fjerne hindringer? Hva er egentlig dette?
Hindringer er alt som forstyrrer flyten i arbeidet til teamet. Et team (eller et gruppe med teams) skal ideelt sett kunne fullføre det de har startet på, uten å bli hindret. Hindringene deles gjerne i to kategorier; indre (innad i teamet) og ytre (i teamets omgivelser).
Hindringer i teamet
Enkelte hindringer kommer fra teamet selv og kan også potensielt løses av teamet selv.
Eksempler:
Mangel på kompetanse, eller feil kompetansesammensetning. Dette er ofte en ganske stor hindring i ferske team, siden folk ofte ikke har den nødvendige overlapp i kompetanse (“T-profil”). Men det kan også dreie seg om at teamet rett og slett mangler nødvendig kompetanse for å lage gode produktinkrementer.
Mangelfull teknisk metodikk. Mangelfull kontinuerlig integrasjon, byggesystem som ikke fungerer godt, deployment utfordringer, avleggs utviklingsmiljø etc kan utgjøre store hinder for flyt.
Mellommenneskelige problemer. Vanskelige, uhåndterte konflikter kan nærmest paralysere et team. Mangel på konflikt kan også være hindring, siden dette ofte er et symptom på konfliktskyhet og mangel på eierskap og/eller trygghet. Meningsbrytninger er en forutsetning for å komme fram til gode beslutninger som alle står inne for.
Produktleder/PO og utviklerne kommuniserer ikke godt. Det er dessverre ofte en “kløft” mellom forretningssiden og utviklerne, hvilket kan bety at kommunikasjonen fungerer dårlig og at tilliten er lav.
Lite “alignment” i teamet. I mange team jobber utviklerne nærmest hver for seg, selv om vi kaller dem et team. Folk har sine egne mål og preferanser som i for stor grad preger det de prioriterer. Her må PO evne å sette klar retning slik at betingelsene for samhandling bedres.
Mangel på eierskap. Det er fremdeles vanlig at organisasjonen krever at utviklerne følger spesielle prosesser med verktøystøtte, at man fører timer detaljert og at tekniske beslutninger stadig må godkjennes. Slikt vil undergrave teamets følelse av eierskap, noe som gjerne fører til lav motivasjon.
Lite trygghet. Det er helt avgjørende at team er i kontinuerlig utvikling, at de stadig forbedrer seg basert på erfaringslæring. Slik læring fordrer at man kan snakke om det som går skeis og gi hverandre feedback, selv om det er ubehagelig. Ikke alle team har den nødvendige tryggheten slik adferd krever.
Teknisk gjeld. For å oppnå god flyt i arbeidet må den tekniske standarden teamet jobber på være av en viss kvalitet. Hvis endringer stadig fører til overraskelser, bieffekter og at man må bruke lang tid på å verifisere at ting fungerer, blir det veldig krevende å oppnå god flyt.
Hindringer i omgivelsene
Når et Scrum team kommer opp i fart vil de oppleve at de ikke helt klarer å fullføre det de har startet uten å måtte vente på noe eller noen de ikke har kontroll over. Eller kanskje de opplever at de ikke klarer å utnytte det de lærer underveis på grunn av at de allerede er fastlåst i forpliktelser.
Eksempler:
Behov for ekspertise. Teamet blokkeres siden de er avhengig av kompetansen til en person (eller et team) som ikke nødvendigvis prioriterer dem høyt nok.
Mangel på utstyr. Når teamet stadig opplever å bli blokkert av at tilgangen på nødvendig verktøy og utstyr ikke er på plass, kan dette skape både frustrasjon, oppgitthet og ødelegge både flyt og motivasjon.
Mangel på fullmakter. Teamet stoppes fordi de ikke har lov til å gjøre noe på egen hånd. Dette skjer ofte når andre “eier” en kodemodul og man baserer seg på at bare en person eller ett team har lov til å gjøre endringer i denne. Eller det kan være regler som krever at noen med autoritet (arkitekt, sjefsdesigner, Q/A eller lignende) skal godkjenne.
Behov for avklaringer. Teamet mangler oversikt eller myndighet til å ta en beslutning og må vente på dette.
Uklare prioriteringer. Hvis teamet opplever vingling, eller rett og slett manglende prioritering (“alt er viktig”) blir det svært vanskelig å fokusere sammen på felles mål.
Mangel på tilganger. Når teamet trenger tilgang på spesielle verktøy, eller på data uten å ha direkte aksess til dette, vil det kunne hindre flyten.
Vanskelig å utnytte lærdom. Hvis omfanget / backloggen i for stor grad allerede er låst vil det bli vanskelig å utnytte nyvunnen innsikt. Teamet blir da tvunget til å implementere noe de ikke tror er det beste eller de blir tvunget inn i en forsinkende endringsbehandling.
Tungt å drive forbedringsarbeid. Når teamet (gjerne i forbindelse med retrospective) kommer opp med en god ide til forbedring, opplever de at man er fastlåst på grunn av policy eller prosess med verktøystøtte.
Svakt samarbeid med interessenter. Det er en forutsetning at teamet har jevnlig kontakt med de viktigste interessentene. Dette er de menneskene som til syvende og sist avgjør om vi lykkes eller ikke. Disse må teamet lære å kjenne, og kunne teste ut nyvinninger sammen med. Møter vi representative brukere, og har vi den beste formen for kontakt med disse?
Overbelastning. Mange team opplever at organisasjonen stadig forplikter teamet i en grad det er veldig vanskelig å levere på. Utviklerne føler seg tvunget til å “kutte hjørner” og får ikke tid til å etterlate seg et produkt de kan være stolte av og som er laget for fremtidig utvikling.
Dette her er selvsagt ingen uttømmende liste. Det er bare en opplisting av typiske hindringer jeg selv har opplevd etter mer enn 20 år tett på Scrum team.
Verdien av å fjerne hindringer
En tradisjonell prosjektleder vil fokusere på å finne veier rundt hindringer. En Scrum Master vil derimot forsøke å fjerne hindringen permanent, slik at vi slipper å stadig stange i de samme problemene.
Hvordan det lønner seg å gå fram for å fjerne en hindring er det vanskelig å svare generelt på, men jeg vil advare mot bulldozer-metoden. Det kan jo være fristende å utstyre Scrum Master med vide fullmakter til å fjerne en hindring med makt. Det kan være kortsiktig effektivt, men vil sjelden føre til varig, god endring. I stedet må vi betrakte Scrum Master som en coach med innflytelse, men uten formell makt. De som blir berørt av endringen må selv få være med på å finne løsningen, det er den eneste farbare veien for å oppnå varig endring.
Anbefalt generisk prosess for å fjerne hindring:
- Skap bevissthet. Få tak i fakta, og hvis mulig kvantifiser problemet. Hvor ofte skjer dette og hvor vondt gjør det?
- Diskuter mulige endringer med de berørte
- Bli enige om konkrete endringer — men vær forberedt på å måtte justere etter en tid.
På denne måten vil Scrum kunne fungere som en slags “debugger” for organisasjoner som ønsker å gradvis oppnå bedre og bedre flyt i arbeidet. Scrum Master vil være garantisten for at team ikke stagnerer og blir stående med stadig gjentagende hindringer i arbeidet.
Det bør være åpenbart at dette er en del arbeid, typisk vil være en 50% stilling for ett Scrum Team. Kostnadssiden vil altså være lett å måle.
Men hvor mye er dette arbeidet verdt? Kan vi være sikre på at vi går i pluss? Dette er det veldig vanskelig å svare skråsikkert på. Men for en organisasjon som er opptatt av å ikke stagnere og å bli en lærende organisasjon, tror jeg ikke man har noe valg. Kontinuerlig forbedring skjer sjelden naturlig av seg selv. Når det er sagt — et virkelig sterkt team med stor indre motivasjon vil nok kunne drive forbedringsarbeid “på egenhånd”. En stund. Men det vil være sårbart og lett stoppe opp når teamet kanskje mister den ene personen som har tatt pådriverrollen. Mye tyder på at varig, robust opprettholdelse av en forbedringskultur fordrer at noen har dette som hovedoppgave.