Hvordan få teamet til å ha stand-up møter?

Når jeg holder kurs og ellers når jeg snakker med folk som strever med å innføre smidig, får jeg ofte dette spørsmålet:

“Noen av teammedlemmene synes det er noe pes med disse møtene, og de vil gjerne slippe. Hvis de møter opp, kommer de for sent. Hvordan kan jeg få dem til å møte opp på de daglige møtene?”

Det som slår meg er at dette spørsmålet er veldig tilsvarende et annet typisk spørsmål:

“Hvordan får jeg teamet til å redusere WIP-grensene sine?”

Selv om dette er to ganske ulike saker, har de noe til felles. De representerer noe som utviklere synes kommer i veien for det daglige arbeidet. Daglige møter fører til irriterende avbrytelser i utviklingsarbeidet og lave Work-In-Progress (WIP)-grenser fører til at flyten av arbeidet i det daglige stopper opp.

Hva man skal gjøre i disse tilfellene er ikke opplagt. Vi har lært oss at det er viktig med daglige møter og vi har lært oss at WIP bør være så lav som mulig for å øke gjennomstrømningen av arbeid.

La oss først problematisere litt rundt spørsmålet – hva er det som får noen til å gjennomføre disse (uønskede) tingene? For det er jo utvilsomt mange som faktisk gjør dette. Jeg tror du finner dem i tre kategorier:

1. De som gjør det fordi det er bestemt.

2. De som gjør det fordi de har en vag idé om at det sikkert er lurt

3. De som gjør det fordi de ser at det hjelper

Kategori 1 favner jo de organisasjonene som er prosedyredrevne og som har en sterk “complience-kultur”. Vi finner dette mange steder, og enkelte bransjer synes å peke seg ut her. Det kan også være at personlighet spiller inn. Det finnes opplagt folk som “bare følger etter” uten å tenke så mye over hvorfor – og det finnes rebeller som helt naturlig vil forsøke å unngå begrendense regler. Kategori 2 omfatter de som har en klar bevissthet på at det vi har gjort til nå suger – ergo må dette være bedre. De gjør det ganske helhjertet og vil stadig være på utkikk etter positive effekter. Kategori 3 er de som virkelig har satt seg inn i hvorfor. De ser det store bildet – og de ser aktivt etter effekten av det de gjør. Dette er katedralbyggerne (jeg har skrevet litt om dette begrepet på LinkedIn Pulse) som hele tiden er opptatt av sluttresultatet og “det store bildet”. Så i dette perspektivet kan vi drøfte hvordan vi skal løse disse problemene. For det er selvsagt problematisk at et team tydeligvis ikke er enige om hvordan de skal jobbe.

Jeg kommer nå rett fra 4 dager med fordypning i ulike aspekter av smidig. Først Agile Coach Camp Norway, deretter Agile Culture Hacking med Olaf Lewitz. Her har det vært rikelig anledning til refleksjon og fordypning i slike spørsmål. Hovedsaken alle disse dagene var finne ut mer om hvordan vi som er entusiastiske “smidige endringsagenter” kan gi verden et lite dytt i riktig retning.

Om kulturen tillater det kan vi “pålegge” folk å stille på daglige møter med fast agenda samme tid, samme sted hver dag. Men dette gir selvsagt ikke den effekten vi er ute etter. Det vi får er en syltynn, overflatisk implementasjon uten noe engasjement. Dette er compliance, ikke en bevisst handling. Dette er “command and control” og ikke Agile. Dette er akkurat det vi må komme oss unna. Skal vi får en implementasjon av smidige prinsipper som virkelig gir effekt, må vi innse at det ikke finnes noe kjapp, enkel løsning. De kjappe løsningene fordrer lydighet og ikke refleksjon. Hva er det vi ønsker i kunnskapsbedrifer egentlig? Lydige tinnsoldater, eller reflekterte katedralbyggere?

For å få til varing endring og forbedring må vi tåle å bruke tid på det. Vi må innse at folk må få være med selv og sette mål, utforske alternativer og gjøre valg. Vi som er endringsagenter må støtte i dette arbeidet. Vi kan opplyse, veilede, fasilitere og coache, men ikke insistere, pålegge eller presse på. CoachingProcess

Så, om vi ser at teamet vi jobber med har problemer, så vet vi altså at den kjappe løsningen der vi forsøker å overtale folk til å følge regler ikke vil fungere godt. I stedet må vi bruke tid på å gi dem den nødvendige innsikten i det problemet vi står overfor (Increase awareness). Deretter må vi snakke om målsetninger (Identify goals). Hva er det egentlig som er viktig å oppnå? Så må vi se på hvilke alternativer som ser best ut i forhold til målet (Explore options). Deretter må teamet selv få velge (Invite to choose). Og bare så det er sagt – de må bli enige om en måte – hvis de skal jobbe som team. Visse rammer må være felles for at et team skal fungere. Og så må vi ikke glemme å evaluere (Reflect on outcome). Fungerer det etter hensikten? Uansett kan vi ta en ny runde og sette nye mål og utforske flere mulige alternativer og forsøke noe annet.

CoacingProcessDailyI dette eksempelet ser vi hva vi i praksis kan gjør om teamet ikke får utbytte av daglige Scrum-møter, eller om de ikke møter opp. Først må vi altså sørge for at de forstår hva man kan oppnå med Scrum som rammeverk og hvilken rolle disse møtene spiller i dette rammeverket. Når alle da har dette felles fundamentet på plass kan vi fasilitere en samtale rundt samarbeid, koordinering og å finne hindringer. Slike ting som de daglige møtene er ment å hjelpe til med. Deretter kan vi få en reell diskusjon rundt hvilke alternativer som finnes. Kanskje de har ideer til bedre måter enn standard Scrum 15 minutters stående møte? I så fall er det jo bare å prøve i en sprint eller to. En coach eller Scrum Master må da være våken og notere seg hvordan dette forløper underveis i sprinten slik at man kan gjøre en ny vurdering senere ( i retrospective).

CoachingProcessWIPPå samme måten kan vi gjøre med WIP-grensene. Vi kommer aldri til å få noe posistivt engasjement rundt WIP-begrensninger om ikke teamet forstår hvorfor, får være med å å styre grensene eller ser med egne øyne hvordan de blir brukt til å øke gjennomflyten og gjøre systemet med effektivt.

Jeg kommer stadig tilbake til dette:

Om du behandler folk som voksne, positive mennesker vil du få – voksne, positive medarbeidere. Voksne mennesker trenger å gjøres myndige og selv eie valgene som gjøres.

 

Posted on January 13, 2015 at 2:35 pm by gamsjo · Permalink
In: ansvar, Coaching, Endringsledelse, ledelse, Scrum, selvorganisering, Uncategorized · Tagged with: , , ,

2 Responses

Subscribe to comments via RSS

  1. Written by Kim Betti
    on 13/01/2015 at 3:40 pm
    Reply · WordPress › Error