Erfaringer som Scrum Master

Smidighet handler egentlig om at man skal være smidig i forhold til sine omgivelser. Og disse varierer fra prosjekt til prosjekt, og fra ett team til det neste. Av alle forfatterne av det smidige manifest er det nok hytte-eieren selv, Alistair Cockburn, som har skjønt dette best. Han sa aldri at én måte å gjøre ting på var den beste. Tvert imot designet han et fler-dimensjonalt sett av metoder som et forslag for å kunne håndtere ulike kontekster (Crystal-familien). Mulig hans norske opphold gjorde ham mer ydmyk enn resten av gjengen, som ironisk nok kan være ganske rigide i sine overbevisninger.

Det er mange som har, eller får tildelt, rollen som Scrum Master i et it-utviklings-team. Jeg har deltatt i mange prosjekter og team som har praktisert dette, og har selv vært Scrum Master. Både i individuelle team, men også som ansvarlig for flere parallelle team. Her er mine erfaringer, praktiske råd, og konkrete tips for en Scrum Master (eller tilsvarende prosessstøtte-funksjon). Jeg forutsetter forøvrig grunnleggende kjennskap til Scrum og smidig utvikling.

Bakgrunnslitteratur

• Kjøp Henrik Kniberg’s tre fantastiske bøker: «Kanban and Scrum – making the most of both», «Scrum and XP from the Trenches», og «Lean from the Trenches». Les dem før du starter. Det er fort gjort.
• Prøv å bygge opp en tilstrekkelig verktøykasse med teknikker for spesifikke behov. Som eksempel var det en periode teamet vårt hadde behov for beskyttelse fra såkalte tids-tyver. Ved å introduserte teknikken Waste Snake fikk vi håndtert dette på en god måte. Har du for eksempel en teknikk eller to som gjør at også introverte mennesker deltar aktivt i gruppe-diskusjoner?

Grunnleggende

• Det skal aldri være tvil om hvem som er med i teamet. Deltids-medlemmer er ikke medlemmer. Hvis du eller noen av de andre på teamet ikke er 100% sikre på hvilke andre som er med, så starter jobben din her!
• Trenger dere tidsavgrensede iterasjoner (les sprinter)? Eller er hver oppgave en iterasjon? Scrum vs. Kanban. Min anbefaling heller mot Kanban hvis mulig, men det avhenger av indre og ytre faktorer.
• Smidig utvikling handler i bunn og grunn om å forkorte feedback-loopen. Prøv alltid å gjøre denne så kort som mulig. Er det for eksempel nødvendig å vente helt til retrospektive før man får feedback fra teamet på hva som fungerer bra og ikke fullt så bra? En hverdagsirritasjon fra starten av en iterasjon blir fortere glemt enn en som dukker opp nærmere slutten. Jeg klistret derfor opp et skjema på veggen ved hver ny iterasjon, hvor hver enkelt kunne poste lapper umiddelbart når tanken slo dem. Dette gjorde ideene synlig for alle, hele tiden. Det bidro til at man var bedre forberedt til å diskutere sakene når retrospektiven kom. Selv team-medlemmer som var forhindret fra å kunne delta på selve retrospektiven, bidro allikevel med ideer gjennom sine tidligere postede lapper.

Kommunikasjon

• Dokumenter hvordan dere gjør ting – hvordan prosessen deres er, men ikke gjem det i et digitalt system, slik som Confluence. Print det ut og få det opp på veggen. All grunnleggende informasjon må være synlig og direkte tilgjengelig. Hvis en er nødt til å slå det opp på nettet, er det alt annet enn synlig.
• For å forenkle kommunikasjonen mellom ulike interessenter har jeg sett fordelen med å benytte to nivåer av kanban-tavler. En detaljert kanban-tavle for temaet, og et annet for aggregert informasjon beregnet for utenforstående.
• Det er mye enklere å endre prosessene hvis en benytter manuelle hjelpemidler. Benytt derfor tavler og informasjonsvegger som master. Bruk gjerne en digital kopi i tillegg hvis det trengs (f.eks. Jira), men ikke bruk tid på å konfigurere denne. Gjør den heller så enkel som mulig, slik at den ikke behøver å endres hver gang en gjør en mindre endring på den manuelle prosessen. Dette fører til hyppigere, mindre endringer og eksperimenter, som igjen bidrar til kontinuerlig læring og forbedrede prosesser.
• Heng opp oppsummeringene fra tidligere retrospektiver på veggen. Slik blir de en påminnelse om teamets utvikling, og dets siste diskusjoner. Marker oppgaver som utført etthvert som de blir håndtert.
• Informer teamet om hva som skjer i verden utenfor. Husk at de andre ikke nødvendigvis vet hva som foregår, selv om du gjør det. La de få innsikt i det store bildet til enhver tid. Bedre å informere en gang for mye, enn en gang for lite.
• Prøv å holde all nødvendig rapportering (oppover) kort, konsist. Sleng det opp på veggen, som en pub-sub mekanisme istedenfor tradisjonell ineffektiv håndtering. Alle som vil kan se all rapportering, åpenhet er viktig. Men like viktig er å slippe å bruke tid på å rapportere til hver enkelt. Interessenter bør «pulle» informasjon ved behov (ved å oppsøke veggen), istedenfor å pushe ymse rapporteringsoppgaver til deg eller andre i teamet hver gang de føler behovet for det. Prøv å holde nødvendig rapportering til et minimum.
• Tidspunkt for standup? Ingen fasit her, men hvis alle spiser lunsj samtidig, så kan det anbefales 15 minutter før lunsj. Dermed slutter man alltid presis, og kan eventuelt fortsette samtalen under lunsjen. Kjører dere flere scrum teams, sørg for å ha daglig standups på ulike tider. Slik kan alle som vil delta på alle de ønsker.

Kvalitet

• Alle mann til pumpene, eller «stop the line» som man sier i industrien. Aldri la dårlig kvalitet få flyte nedover verdikjeden. For eksempel må ethvert bygg som brekker, test som feiler osv, være topp prioritet. Alle nødvendige ressurser må settes inn inntil situasjonen normaliseres.

Prosess-forbedringer

• Eksperimenter med formatet. Gjør en endring eller to hver iterasjon. Men aldri for mange, ellers vet man ikke hva som forårsaker resultatet av endringene. Stabilitet er viktig.
• Ikke la teknologien og verktøyene diktere hvordan dere arbeider. La temaet først designe sin egen prosess, deretter finn eller lag de riktige verktøy som hjelper dere å komme dit. Tekniske verktøy kommer ofte i veien, isåfall la være å bruke dem.
• Sørg alltid for at de øverst prioriterte aksjonspunktene fra retrospektive blir håndtert og utført. Hvis ikke vil teamet fort miste troen på at de kan påvirke sin egen hverdag, på kontinuerlig forbedring, og de tar ikke lengre ansvar for teamets suksess.
• Lag deres eget vokabulær. Alle nye prosesser starter typisk med å «følge boka». Sakte men sikkert begynner man å tvike på reglene, og tilslutt kaster man hele boka og lager istedet sin egen unike kontekst-avhengige prosess. Bra. De konseptene dere kommer opp med bør således ha sine egne navn. Hvis ikke vil mennesker feilaktig assosiere deler av prosessen med vanlige definisjoner på lignende konsepter. Egne navn gjør kommunikasjonen lettere, og misforståelser mindre. For eksempel hadde mine tidligere Scrum-mastere omdøpt konseptet «sprint» fra Scrum til sin egen «dash». Slik kunne de selv definere nytt innhold til hva dette betydde. Konseptet var ikke lengre identisk med sprinter i Scrum.
• Ide-myldringer. Det er vanlig å kjøre brainstorming-sesjoner fra tid til annen. Men ikke alle hjerner fungerer likt. Jeg selv, for eksempel, blir helt tom for ideer hvis jeg plutselig skal delta i en 5-10-15 minutters kreativ sesjon. Jeg trenger noe forberedelser. Hva med å kjøre brainstorming sesjoner som varer over flere dager istedet? Det kan gjerne starte tradisjonelt, men la den så være åpen for nye innspill i f.eks. et par-tre dager før man igjen møtes for å avslutte og foredle tankegodset. Et tips for å la «oppgaven» være i folks bevissthet/underbevissthet er å henge opp påminnelse om dette der folk ferdes – ved kaffemaskinen, på do, osv.

Læring

• Ved større eller flere parallelle team: tilrettelegg for regelmessige lyntaler på faglige tema som en form for informasjonsdeling.
• Lag deres helt eget sett med metrics. Hva som skal måles må dere selv finne og ha et aktivt forhold til. Sørg for at prosessen er data-drevet (fakta-basert).
• Root-cause analysis workshop er nyttig for enkelte større hendelser av negativ art.

Arbeidoppgaver

• Prøv å dele opp oppgavene i nogenlunde samme størrelse, og så små som mulig. For spesielt interesserte kan jeg anbefale amerikanske E. Demings bøker (om variasjon). Mindre variasjoner skaper mer forutsigbarhet, og kan f.eks. eliminere behovet for estimater. Unngå å estimere hvis du kan. Det koster mye, en bedre metode er å bruke energien på å levere.
• Finn en absolutt maks lengde, og del opp hvis du må. Alltid del på funksjonalitet. Lær opp kunder, produkt-eiere og andre om nødvendigheten av små oppgaver og hvordan de kan lage krav som tilfredsstiller denne måten å strukturere arbeidet på.
• Mindre endringer bør håndteres som en del av det daglige arbeidet, og ikke som separate oppgaver. Speider-prinsippet f.eks. kan her være nyttig. Slack er nødvendig. Større endringer må håndteres som egne oppgaver. Begge varianter er nødvendig for å kunne holde jevn fart, og for å holde de totale kostnadene nede.
• Aktiver team-medlemmer i møter.. F.eks. bør de selv oppdatere tavla ved å fysisk flytte lappene etterhvert som de diskuterer dem. Ikke bare la de stå passive og snakke. I retrospektive, roter gjerne hvem som gjør hva. Engasjementet øker hvis folk rører på seg. Unngå at folk bare setter seg ned og lar ordstyrer prate.
• Ved daglige standups, fokuser på oppgavene, ikke menneskene. Relater all diskusjon i møtet til oppgaver. Blås i hva den enkelte gjorde i går. Det blir fort en typisk skryte-øvelse hvor de som har gjort minst har brukt mest tid på å finne på unnskyldninger. Det er teamets fremgang som teller. At en enkelt ikke fikk gjort alt det vedkommende trodde, skjer hele tiden – oftest fordi man må hjelpe andre. Uansett, poenget er ikke å henge ut folk, eller å ha et press på den enkelte. Poenget er å informere og ha god kommunikasjon innad i teamet.
• Konseptet med Episoder (epics) fungerer veldig dårlig innad i et utviklingsteam. Hvis du må, bruk det som en form for gruppering av funksjonalitet på et administrativt nivå. Det vil si for produkteier eller andre interessenter.

Prosess-steg

• Bruk sjekk-lister for hva som skal være utført før en oppgave kan flyttes til neste steg i prosessen.
• Skill mellom aktive og passive steg i prosessen. Det er nyttig å kunne ta tiden på disse. Aktive steg er når arbeid blir utført på en oppgave, passive er når de venter på å bli utført. Visualiser også vente-køer bør på kanban-tavla, ikke bare arbeidsstegene.
• Hvis du kan, unngå å køe opp ferdige utviklingsoppgaver til test. Dette er misbruk av tid og ressurser. Test en story umiddelbart etter den er ferdig utviklet. Unngå kontekst-bytte ved at utviklere starter på nye oppgaver, før feil må rettes på den forrige. Sitt sammen; fiks og verifiser feilen sammen. Unngå unødig administrasjon, kontekst-bytte, og passering av oppgave frem og tilbake i det uendelige. Feil som blir rapportert men indirekte godkjent blir aldri fikset. Fiks det umiddelbart, ellers blir det aldri gjort.
• Feil hører ikke hjemme på en kø. Aldri putt feil på backloggen, eller enda værre – en egen backlog for feil. Enten fikser man dem umiddelbart, eller så forkaster man dem. Ikke skap falske forhåpninger. Feil som ikke umiddelbart blir løst, blir aldri løst. Får du for mange kritiske feil, så må du forbedre kvaliteten i de tidligere prosess-stegene.

Scrum Master rollen

• Å kombinere rollen som Scrum Master med en utvikler-rolle er vanskelig. Av natur er de ikke forenelige. Scrum Master er en avbrudds-drevet fasiliterings-rolle. Programmering er en flow-basert aktivitet som bør skjermes for stadige avbrytelser. Gjør heller en ting, og gjør den bra.
• Det finnes aldri lediggang for en Scrum Master. Når man ikke blir avbrutt, fokuser på oppgaver knyttet til kontinuerlig forbedring.
• Lag både kortsiktige og langsiktige mål, basert på initiell observasjon og hva du og teamet ønsker å oppnå. Et langsiktig mål kan for eksempel være knyttet til forutsigbare leveranser.
• Vær bevisst på din egen rolle i teamet. Enheten man opererer på er alltid teamet. Ikke en enkel deltager. Deg selv inkludert. Din rolle er hverken å lede teamet eller team-medlemmer. Et tegn på dette er f.eks. hvis team-medlemmer alltid ser på deg når de snakker om hva de har gjort og skal gjøre under standups. Likeså hvis det kun blir arrangert standups hvis du selv er tilstedet. Da har du virkelig en jobb å gjøre. Husk, din rolle er å tilrettelegge, og bare det.
• Noe jeg ofte har observert tidligere er enkelte deltagere i et team som hopper over sin tur i standup-møter, fordi man tror det kun er for utviklere. Dvs. team-ledere, prosjekt-ledere, scrum-mastere, produkteiere, arkitekter, og tilsvarende. Alle i et team skal delta på lik linje. Informasjonsdeling er viktig. Likeverdighet likeså. Du er altså intet unntak, følg reglene som gjelder for resten av teamet. Aktivitetene til en Scrum Master bør også deles opp i oppgaver og opp på kanban-tavla sammen med alle andres. Hvis du gjennomfører en scrum-of-scrums, benytt en scrum-of-scrums tavle.
• Husk at din rolle som scrum-master er å gjøre deg selv overflødig 😉