TaskCtrl

og

Scrum

Mange som jobbar i team er nok kjende med konseptet Scrum og brukar dagleg fleire av verktøya som medfølger arbeidsmetodikken, slik som backlog, sprint og stand-up. Eg har jobba i ulike team både på studie og i jobb der me har tatt i bruk delar av Scrum, men det var ikkje før eg tok eit kurs i Scrum eg skjønte at det er muleg å få endå bedre utbytte av denne arbeidsmetodikken.

Teamet vårt i TaskCtrl har den siste tida tatt i bruk Scrum meir etter boka, og dette har vist seg å gi positive resultat. Dette synes eg er veldig motiverande og har derfor lyst å videreformidle litt “key takeaways” frå våre erfaringar.

Før du les resten så vil eg kome med ein disclamer; eg er ingen ekspert, men vil dele personlege erfaringar med utgangspunkt i det noverande teamet eg er i. Mitt første møte med Scrum var på universitetet og har brukt delar av Scrum i mange prosjekt, men det var ikkje før eg og andre på teamet i TaskCtrl tok eit Scrum-kurs eg såg det store bilde. Målet mitt er å få deg til å tenke gjennom korleis teamet ditt brukar smidige verktøy for å nå dykkar mål. Ein bonus er om du plukkar opp nokre nyttige tips!

Scrum-master rollen: fokus på teamet

Mange kjenner til at ein Scrum-master skal holde møter og fungere som ein fasilitator. Men rollen innebærer også eit større ansvar. Ein Scrum-master skal fokusere på teamet og skjerme dei frå støy frå utsida. Dette kan for eksempel vera støy frå produkteigar eller kunde. Det at Scrum-master har fokus på teamet betyr at denne personen skal bidra til psykologisk tryggheit og sørge for at team medlemmane har det dei trenger for å kunne trivast på jobb og dermed utføre jobben sin på best muleg måte.

I motsetning til ein prosjektledar der fokuset er på produktet (utover), så er fokuset til Scrum-master på teamet (innover). Det er derfor ein dårleg ide å mikse scrum-master-rollen med produkteigar eller prosjektledar då desse rollane fungerar som ei motvekt til kvarandre.

Scrum i TaskCtrl

Det siste halvåret har me i TaskCtrl anvendt Scrum meir etter boka som har vist seg å gi positive resultat. Eg kjem ikkje til å forklare alle møtene og begrepa i Scrum, då eg trur mange som les dette har ein viss kontroll. Derimot vil eg kort gå gjennom det eg trur mange gløymer vekk eller ikkje brukar nok tid på i sitt teamarbeid.

I figuren nedanfor ser de ein oversikt over korleis ein sprint ser ut hjå oss. Ein sprint varar i to veker, og me avsluttar ein sprint på ein mandag, før me startar ein ny sprint følgande tirsdag.

Sprint planning og backlog refinement

Noko av det første vårt team gjorde var å bruke meir tid på sprint planning og legge til eit møte kalla backlog refinement.

Før du rekker å bekymre deg; ja, det blir meir møter, men tenk deg kor mykje tid som blir kasta bort av at team-medlemmar har hatt ulik forståelse om kva ei oppgåve går ut på. Eller kor mykje tid som blir brukt på feilprioriterte oppgåver og oppgåver som ikkje har hatt ein tydeleg kontekst. Det er akkurat dette desse møtene skal hindre at skjer. I backlog refinement-møtet er dette agendaen:

• Teamet skal løfte blikket opp frå dei noverande oppgåvene i sprint-backloggen og og sjå gjennom nye oppgåver som har dukka opp i produkt-backloggen.
• Me fyller ut beskrivelse og finner ut kva som skal til for å løyse oppgåvene og estimerer basert på kompleksiteten til oppgåva.

Etter dette møtet kan det hende me finn ut at nokon oppgåver ikkje kan inngå i noko framtidig sprint av ulike grunnar som f.eks at ei oppgåve er for kompleks, at den ikkje er forståeleg eller at me finner ut at den ikkje er nødvendig alikevel. Dette møtet legg grunnlaget for produkteigar når ho skal prioritere oppgåvene seinare. Når produkteigar har gjort sin del så er temaet igjen klare for sprintplanlegging nokre dagar seinare.

I sprintplanleggingsmøtet som skjer like før sprintstart så ser me på oppgåvene igjen. Me estimerer på nytt om nødvendig, og bryter oppgåvene ned i mindre delar. Etter dette møtet så veit kvar enkelt på teamet nøyaktig kva oppgåvene går ut på og korleis dei skal løysast.

Etter desse to møtene har me fjerna mange rom for misforståingar og teammedlemmane er klare til å starte med effektiv jobbing utan mange forstyrringar.

Me brukar omtrent 1,5 time på sprint planning og 1 time på backlog refinement kvar sprint. Dette er ikkje mykje tid basert på kva me sparar på å få alle om bord på planen. Eit siste tips her, og som gjeld for alle møtene: Hold møtene korte og presise, kom tidsnok og hold dykk til agendaen.

Retrospektiv

Retrospektiv er rett og slett “the scrum-goat” av møtene. Kort og godt så går dette møtet ut på å gi teammedlemmane ein sjanse til å lufte tankane sine. Ein skal reflektere over kva som har gått bra i sprinten har kva som har forbedringspotensiale. Det som er viktig her, og som mange kanskje gløymer, er å ikkje prøve å forbedre alt på ein gong, men å velge seg eit par ting ein skal bli bedre på til neste sprint. Nøkkelen til eit bra retrospektiv er at heile teamet bidrar og at alle er trygge nok til å ta opp eventuelle problem. Det er Scrum-master sitt ansvar å følge opp og sørge for at tiltak frå retrospektiv blir gjort.

Ikkje dropp dette møtet, då eit av poenga med Scrum er kontinuerleg forbedring etter kvar sprint, og det er vanskeleg å få til utan å stoppe opp å tenke over kva som kan forbedrast. Gjerne prøv deg fram med litt ulike format på møtene for å få teamet engasjert!

Resultat av Scrum

Om du fortsatt er usikker på kva dette vil gi deg og teamet ditt så er dette noko av forbetringane me har sett etter å ha tatt i bruk Scrum (på den “ordentlege” måten).

Det som har gjort den største forskjellen for oss er å ha fått med heile teamet til å jobbe mot eit felles mål og sørge for at alle har lik forståelse av alle oppgåvene. Dette har me tilrettelagt for i hovedsak gjennom sprintplanlegging og backlog refinement.

Etter å ha tatt i brukt Scrum har me kommunisert bedre og tydlegare med produkteigar om korleis proritering fungerar og at me må kun ha eitt fokusområde om gongen. Det har gjort at færre oppgåver har dukka opp midt i ein sprint. Dette har og ført til eit bedre samarbeid mellom teamet, produkteigar og andre stakeholders då prioritering er noko me samarbeider om.

Teamet har meir nøyaktige estimeringar på oppgåvene no enn før (sjølv om me fortsatt har litt å lære her). Me har fått redusert antall oppgåver som viser seg å vera større enn først antatt sidan me har gjort ei grundigare vurdering og diskusjon av oppgåvene før sprinten.

Teamet vår har hatt fordelar av å bruke Scrum meir konsekvent, men me er endå ikkje utlærte og det finnast mykje forbedringspotensial. Det er alltid noko som dukkar opp under retrospektiv som kan utbedrast, men problema blir litt mindre kritiske og litt enklare å håndtere for kvar sprint.

Dette er kanskje som å banne i Scrum-kyrkja, men det er ikkje så viktig kva rammeverk ein brukar, eller om du kallar arbeidsmetoden smidig eller ikkje, eller om du velger å kalle møtene for noko heilt anna enn det som står i Scrum-manifestet. Det viktigaste er at teamet har ein felles forståelse om kva målet er, at alle har respekt for kvarandre og motiverar kvarandre, og ikkje minst at ein saman lagar ein arbeidsplass der ein kan ta opp problem før det oppstår ein konflikt. Det høyres enkelt ut, men likevel trur eg det er eit få antall team som får til akkurat dette.