Smidig metode: Gi oss i dag vårt daglige standup?

Standup-møtet er for mange selve definisjonen på Scrum og smidig. På spørsmålet om man kjører smidig, så hender det at man får svaret: «Ja, vi kjører daglige eller ukentlige standup-møter», og dermed kjører man smidig. Men hva skjer om man fjerner standup-møtene helt?

Av Pål Berg og Margrethe Sæther Johannessen

jj

«Det var en gang et utviklingsteam som var så velfungerende og selvorganiserende at retrospektivene bare ble koselige sammenkomster der alle var fornøyd. Men så en dag, på et retrospektiv midt i 3. delleveranse, så var det plutselig en som hadde skrevet en lapp som fikk de andre til å gispe: «Vi dropper daglige standup-møter». Forslaget ble diskutert både lenge og vel, og til slutt så ble man enige om å prøve ut dette i neste sprint. Slik starter eventyret om utviklingsteamet som ikke stod opp hver dag…..»

Slik hadde kanskje Asbjørnsen og Moe ordlagt seg. Og det er ikke helt tilfeldig at vi har valgt å starte dette blogginnlegget som et eventyr. For de fleste høres det kanskje ut som et eventyr at man skal kunne kalle det smidig eller Scrum når man ikke har daglige standup-møter…?

Vel, vi gjorde det vi, og det fungerte bra. Faktisk så bra at vi på neste retrospektiv valgte å videreføre ordningen. Og på neste, og på neste…

Men hvorfor ønsket vi å droppe de daglige standup-møtene?

Det var flere faktorer som spilte inn, blant annet:

  1. De var et avbrudd fra arbeidsflyten. Som også varte noe utover møtets varighet, da man bruker litt tid på å komme inn i flyten igjen.
  2. Siden vi hadde fokus på å besvare De Tre Spørsmålene (mer informasjon om disse kommer under) og ikke alltid hvorfor de stilles, så gjentok vi gjerne oss fra dagen før. Vi jobbet jo ofte med oppgaver som tok flere dager.
  3. Vi fikk ikke nødvendigvis oversikt over teamets fremdrift, og hvordan vi lå an i forhold til sprintens mål.
  4. Vi opplevde at møtet ofte kunne vare lenger enn vi ønsket.
  5. Vi syns vi hadde god kommunikasjon innad i teamet og mente vi kunne basere oss på den kommunikasjonen for å oppnå samme verdi.

Så, hva var det vi gjorde?
Jo, først så tok vi en diskusjon på hva disse daglige møtene hadde som formål.

Scrum Master forkynte:  «Stand-up er den daglige arenaen hvor teammedlemmene holder oversikt og kontroll på teamets fremdrift med sprintens mål for øye. Stemmer dagens status med commitmenten vår?»

Man synliggjør hverandres fremdrift og hjelper hverandre ved hindringer, ved hjelp av de tre spørsmålene;

  1. Hva har du gjort siden sist?
  2. Hva skal du gjøre til neste gang?
  3. Har /forventer du noen hindringer?

Kan vi oppnå det samme på andre måter?
Vi diskuterte oss frem til at det er kommunikasjon som er nøkkelen for dette, og at standup tilbyr tre nivåer for kommunikasjon:

  1. Vi kunne i plenum ta opp og adressere problemer/hindringer.
  2. Daglig rapportering av framdrift vha scrumtavla: Utviklingsteamet, prosjektleder, leveranseteamet og produkteierteamet ble enkelt oppdatert ved å være tilstede, selv bare som kyllinger.
  3. Vi kunne på standup-møtet få beskjeder fra utenfor utviklingsteamet.

Altså et forum for kommunikasjon innad i teamet, ut av teamet og inn til teamet.

GB-180809-6422

Ved å ta bort stand-up måtte vi sørge for at alle disse punktene og formålet for stand-up fortsatt ble tatt vare på. Vi skrev dem ned og gikk igjennom dem og diskuterte hvordan vi kunne ivareta dette uten standup. Vi brukte også listen på de påfølgende retrospektivene for å vurdere hvordan vi klarte oss uten standup.

Alle ble enige om at alle kunne kommunisere med alle så fort behov for det dukket opp, dvs at man risikerte å bli forstyrret oftere enn før, men til gengjeld så fløt kommunikasjonen raskere. Tidligere så utsatte man ofte problemene til neste standup. Det ble også oppfordret til mer bruk av parprogrammering/partestdesign/partesting. Spesielt vha testeaktivitetene bidro det til bedre forståelse både på utviklings og testsiden. Vi senket også terskelen for å holde «ad-hoc»-møter med hele teamet.

Målet med å kommunisere med kundesiden vha av stand-up viste seg å være begrenset oppfylt. Først og fremst ved at kundesidens deltagelse varierte veldig. Vi konkluderte derfor med at dette ikke var en avgjørende faktor. Vi hadde allerede såkalte groomingmøter der produktkøen ble prioritert. Her var produkteier og hele teamet tilstede. Det ble også ved behov holdt minidemoer og spontane diskusjoner med kundesiden gjennom hele sprinten.

I vårt team så hadde Scrum Master også en teamleader-funksjon. Nå som daglig standup var borte ble det strengere oppdateringsregime i Jira. Dessuten ble det veldig viktig å holde orden på scrumtavla. Men i stedet for at den først og fremst ble oppdatert på standup, ble den nå oppdatert løpende og reflekterte bedre enn før hele tiden hva som var tilstanden i sprinten. Det var også viktig at hele teamet var med på planning poker for å estimere oppgavene. Og da først og fremst for å få identifisert oppgavene, avhengighetene og avklaringene slik at de kom opp på scrumtavla.

Etter å ha kjørt en hel sprint uten stand-up så tok vi en evaluering på retrospektiven. På det forrige retrospektivet var det egentlig bare forslagsstiller som var overbevist om at det ville gå bedre uten standup.

Ble alle overbevist etter en sprint? Var dette et eventyr som ble virkelig?

Hadde vi noen utfordringer?
Joda, det var ikke bare et rosenrødt eventyr, vi opplevde følgende utfordringer:

  1. Forum for kommunikasjon inn til teamet. Den daglige informasjonskanalen som prosjektet rundt oss hadde til å kommunisere direkte med teamet var forsvunnet. Vi holdt ikke lenge nok på til at vi fant en prosess/løsning på det, og stort sett så var ikke dette et problem for oss, men kanskje mer for de som hadde beskjeder å gi til oss. Arenaene ble da enten fellesmail, ukentlig groomingmøte eller gå bort til teamet og snakke der og da, evt at beskjeden ikke ble gitt/kom sent.
  1. Skjerme teamet for unødige forstyrrelser utenfra. Det ble en økende utfordring for Scrum Master å skjelne mellom unyttige og nyttige forstyrrelser. Samtidig økte det med forstyrrelser utenfra. Ettersom nevnte ovenstående forum forsvant tok andre prosjektmedlemmer oftere kontakt med enkelt-teammedlemmer.  Vi merket en økning av tilstrømmende oppgaver. Spesielt gjaldt dette arkitekt-oppgaver som hadde sitt eget forum/opplegg og som da ikke var like synlige som brukerhistoriene.
    Det kunne også være at produkteierteammedlemmer tok direkte kontakt med teammedlemmer for å få gjennomslag for sine ønsker.  Dette kunne for eksempel gjelde en feilretting som i utgangspunktet var enkel og rask å implementere, men som ville påføre ganske stor mengde med testing i etterkant. Saker som altså burde vært diskutert med flere fagmennesker stod i fare for å ikke bli det, da de som var involvert ikke så rekkevidden av det de diskuterte.
  1. Konstellasjoner av mindre team i teamet. Vi opplevde også at vi dannet mindre team i teamet. De som jobbet på de samme brukerhistoriene fikk sterkere kommunikasjon, samhold og ansvarsfølelse, men fikk mindre oversikt over de andre brukerhistoriene. Om dette var negativt eller positivt konkluderte vi ikke helt med i og med at vi økte farten vår og leverte med bedre kvalitet.

En annen effekt av dette var at vi så fordelen av mindre team på 3-4 personer, som fulgte brukerhistorien tidligere i forløpet og lenger i forløpet. Ettersom vi økte farten så kunne teammedlemmer delta tidligere i prosessen på brukerhistoriene. De var med på behovs- og kravanalyse sammen med produkteier. Med færre team steg ansvarsfølelsen og vi ble mer opptatt av å levere med kvalitet/mer opptatt av teste-delen på de brukerhistoriene man var involvert i.

For å håndtere dette kreves det et modent team, med medlemmer som vet å kommunisere til resten av teamet og klarer å si nei til/bytte ut/utsette oppgaver, men også i høyeste grad et modent prosjekt. At resten av prosjektet respekterer et teams commitment til oppgaver i en sprint.

På denne tiden var det flere prosjektmedlemmer som var kritiske til scrum og som i større grad ønsket kanban, eller en kombinasjon av evt. andre prosesser. At standup ble fjernet gjorde oss sårbare i denne perioden.

 Media%2050

 

Enn fordelene og de positive effektene da?

  1. Raskere kommunikasjon. Kommunikasjonen innad i teamet  fløt mye raskere. Man tok kontakt i det man trengte det, og diskusjoner fikk en mer naturlig flyt. De som trengtes å involveres ble det, og de som ikke trengte det jobbet med sitt. Vi trengte ikke bruk tid på å avtale at noen skulle diskutere, man tok bare kontakt. Og man brukte ikke tid på å lure på om dette måtte ventes med til standup eller kunne tas med en gang. Spesielt godt fløt kommunikasjonen for de som jobbet tett på de samme brukerhistoriene og greit nok for at alle hadde oversikt nok til å vite hvordan vi lå an i forhold til sprintens mål.
  2. Tettere samarbeid. De som jobbet på de samme brukerhistoriene fikk automatisk tettere samarbeid, det fløt naturlig når man bare tok kontakt når man lurte på noe.
  3. Økt ansvarsfølelse for brukerhistorier. Dette ga i sin tur økt ansvarsfølelse. Man jobbet mer integrert, oppdeling av oppgaver innen brukerhistorie ble mindre tiltrengt og alle fikk mer forståelse for domenet og målet med brukerhistorien.
  4. Slapp selve møtet som både i forkant, under og rett i etterkant ikke bidro produktivt. Man slapp å hver dag bli flyttet fra det man holdt på med og inn i et møte der man som oftest ikke fikk greie på noe avgjørende nytt
  5. Mindre team som fulgte brukerhistoriene tidligere og lenger i prosessen. I stedet for at alle i teamet visste mye om alle brukerhistoriene visste nå færre personer “alt” om en brukerhistorie. Vi økte farten vår, som gjorde at vi ble ferdig med commitmenten og målet for sprinten tidligere. Vi kunne da ta inn brukerhistorier som var ment for neste sprint i inneværende sprint. Ettersom disse gjerne ble gjort klare til sprint rett før de skulle inn i sprinten, fikk teammedlemmer være med på å klargjøre brukerhistoriene. De fikk dermed en mye bedre forståelse for brukerhistoriene og kunne da levere raskere og med bedre kvalitet enn tidligere. En ganske så positiv ringvirkning! Ansvarsfølelsen økte, og med færre personer på en brukerhistorie så økte også ønsket om å levere med så høy kvalitet som mulig, (Økt sannsynlighet for å bli den som rettet, kan også ha medvirket. ). Vi ble derfor mer engasjert i testingen og var i så måte lenger med i prosessen.
  6. Teamet vokste og ble mer modent. Teammedlemmene fikk økt ansvar på flere områder. Hvert teammedlem fikk større ansvar for å holde kommunikasjonen oppe, økt ansvar for hver brukerhistorie, økt ansvar for å vurdere forespørsler/avbrytelser utenfra, mer bevisst ansvaret om å nå teamets commitment og mål. Samt de fikk også en økt selvtillit av å bestemme at en av reglene til Scrum ikke lenger skulle gjennomføres.
  1. Retrospektiv. En annen ringvirkning av å droppe standup var at rammene for hva man kan foreslå på retrospektiv ble endret. Det var kanskje grensesprengende å foreslå å endre på en av rutinene til Scrum?

 

Vi må også kommentere at flere av punktene kan selvsagt også skyldes andre tiltak vi gjennomførte samtidig, da vi ikke testet dette ut helt isolert. Vi tror imidlertid at mye av æren skyldes manglende standup.

Summasumarum?
Alt i alt… Selv om vi fikk økte utfordringer med forstyrrelser så produserte vi bedre uten stand-up.

Vi leverte med høyere fart og bedre kvalitet.

Vil vi så anbefale å bruke Scrum uten daglige standups?  Både ja og nei.

 Vi tror følgende forutsetninger må være tilstede:

  • Teamet må allerede fungere veldig bra og med høy grad av teamwork. Vårt team, som bestod av utviklere, arkitekt, testleder og interaksjonsdesigner, drev både testdrevet og akseptansetestdrevet der alle var med på både testdesign og scriptbasert testing. I tillegg så pågikk det i parallelt med utviklingen, i forkant av systemtest, utforskende test på alt som ble levert.
  • Hele teamet må involveres i arbeidet med å detaljere og forstå kravene. Alle må være med på å identifisere og estimere oppgavene. Dette bidrar til å skape korte og raske kommunikasjonsveier.
  • Enkeltindividene må ta ansvar for egen og hele teamets fremdrift/fart og mål for sprinten.
  • Man må også allerede ha etablert god og rask kommunikasjon mellom kunde og leverandør.
  • Lokalisering: Både leverandør og kunde må være samlokalisert slik at det er lett å kommunisere. Det må også være slik at all denne kommunikasjonen ikke forstyrrer noen, det må være akseptert at det vil være en del «støy i lokalet».
  • Det må være høy disiplin på scrumtavla, i Jira og i andre rapporteringsverktøy.
  • Prosjektet må ha tillit til teamet, slik at de lar teamet bestemme selv om de vil ha standup eller ikke. Eventuelt må man ha en Scrum Master som tør å la teamet ta valg som er upopulære for resten av prosjektet, og skjermer dem for mistillit til teamet når nye ting prøves ut.
  • Prosjektet må forstå Scrum. Resten av prosjektmedlemmene må respektere sprintens mål og commitment, at selv om standup er borte så er det ikke fritt frem for nye oppgaver/endringer på oppgaver når som helst i sprinten.

Vi anbefaler på det sterkeste at man har daglige standup-møter dersom:

  • Man er i ferd med å etablere et team
  • Medlemmene først og fremst jobber selvstendig hver for seg
  • Kommunikasjonen mellom leverandør og kunde er veldig formell
  • De forskjellige disiplinene (utvikling, test, funksjonelt, interaksjonsdesign) i teamet i høy grad er separert
  • Ikke alle forstår / er enige i Scrum
  • Disiplinen på scrumtavla er lav

Så beslutningen om å droppe standup-møter må ikke komme fordi man ikke liker standups, men fordi man mener man har funnet en måte å gjennomføre sprinter på uten standups som gir bedre og raskere kommunikasjon. Og dette må evalueres på hvert retrospektiv.

Men hva da med Scrum?

Hvis man ser for seg at scrum-teamet sitter inne i en liten borg, Scrum Master er portvokteren som hever og senker vindelbroen over vanngraven, og standup er teamets daglige korte utflukt fra borgen for mingling seg i mellom og med «de utenfor», så ble borgen nå bygget om til et palass som det var mye enklere å bevege seg inn og ut av (og inne i), men som fortsatt hadde en Scrum Master som passet på.

cartoon-castle-in-water-3d-model

Samtidig som vi så at teamet ble mer selvstendig/modent og økte farten med bedre kvalitet, så så vi også at mye av Scrum begynte å falle fra hverandre. Folk utenfor teamet tok mer direkte kontakt med enkelt-medlemmer, det kom lettere inn oppgaver på siden, brukerhistoriene passet ikke helt til sprint-syklusen, vi endte opp med ha kortere sprint-planleggingsmøter når som helst i sprinten – siden vi økte hastigheten. Da uten alle i teamet ettersom noen fortsatt hadde oppgaver og andre var ledige.

Vi fikk dermed også anledning til at enkelt-teammedlemmer kunne involveres i brukerhistorier før de egentlig var klare for sprint, og vi kunne introdusere brukerhistorien til de av teammedlemmene som var klare for å begynne å jobbe på den.

Vi klarte oss bedre uten standup, men samtidig så fungerte Scrum dårligere. Skulle vi tilpasse oss tilbake til Scrum eller leke mer med å øke farten og kvaliteten uten å henge oss for mye opp i Scrums regler&rutiner?

Ideen om å etablere mindre og mer dynamiske team, som dannes ut ifra omfang på en brukerhistorie og som eksisterer fra prosjektets detaljerte behov, krav og akseptansekriterer frem til brukerhistorien leveres, var i hvert fall født.

Scrum sine ritualer blir ilagt for mye vekt og uten nok bevissthet rundt hvorfor de anbefales. Er man bevisst årsakene til ritualer/regler/rutiner, så står man også mye friere til å sjonglere med dem, og dra erfaringer av denne sjongleringen.

Snipp snapp snute!

Margrethe Sæther Johannessen har bakgrunn som utvikler og Scrum Master og jobber nå med prosjektledelse. Hun har lang erfaring fra og en brennende interesse for prosesser og metoder brukt i smidig utvikling og prosjektgjennomføring.
Pål Berg er testleder og opptatt av å utvikle og prøve ut nye måter å jobbe på, med spesiell fokus på test og testledelse i smidige prosjekter.

En kommentar om “Smidig metode: Gi oss i dag vårt daglige standup?

Legg inn en kommentar