Husk at tage ejerskab ellers dør I

Hvordan kan vi sikre os, at vi ikke bare forplumrer og forværrer tingene i de enkelte områder? Hvordan definerer vi om et besøg fra Agile Excellence i et område har været en succes?

pdca_cycle For mig personligt er det et mål at få de enkelte teams til at tage både ansvar for, og ejerskab af, processen. Uden ejerskab havner man i en situation hvor man springer over forbedringsmulighederne i Scrum og blindt gentager det man har gjort før. Eller værre endnu, glemmer hvorfor man gør det og holder op. Det vil sige, at uden ejerskab fordrer et besøg fra Agile Excellence et og kun et skridt i Demings PDCA-hjul. Vi indfører en agil proces og området udfører processen uden at reflektere og forbedre.

Ejerskab af processen er ikke ligefrem et objektivt målbart kriterie, men vi vil gerne have en pejling.

Mavefornemmelse

Vi prøver at måle de mavefornemmelser et område har omkring fremdriften og graden af samarbejde de enkelte personer har. Dette har vi valgt at gøre ved at spørge ind til flg. punkter. (Her kigger vi på de sidste fire uger og vi beder om et svar mellem 1 & 5):

  • Hvor produktiv har du følt dig?
  • Hvor klare har målene for dit arbejde været?
  • Hvor stor en grad af samarbejde har I haft?
  • Hvor stor en grad af vidensdeling har I haft?

Vi sender et spørgeskema med ovenstående punkter rundt inden vi kommer til området og igen (lidt arbitrært valgt) efter 5 sprints / 10 uger. Kan vi måle en forbedring på disse 4 punkter før / efter Agile Excellences besøg, er der en god indikator for at vi har gjort noget godt for de enkelte teams. Når vi spørger på denne måde, håber vi at italesætte hvad det vil sige at arbejde efter agil proces.

Når vi har vælger at tage et spørgsmål om produktivitet ind her, udelukker det ikke en mere objektiv måling i ledelseslaget for et området. Men forbedringer i det lag siger ikke noget om teamets fornemmelser for ejerskab.

Ledelse

Før et teamet kan tage ejerskab, skal ledelseslaget give teamet plads og lov til dette. Specielt traditionelle projektledere har svært ved at give afkald på micro-management og vandfalds-tankegangen. Der har vi i Agile Excellence altid en udfordring med at sikre at projektlederene lader teamet organisere sig selv. Typisk får vi projektlederen til at tage opgaver som en del af et Product Owner team, men detaljerne må vente til et andet indlæg.

Scrum Master

100% ejerskab forudsætter at ScrumMasteren kan facilitere dette ejerskab. Det kræver erfaring. Flere områder vi har besøgt har kunnet pege på en person med tidligere ScrumMaster erfaring og et vist drive for rollen. Men de områder der ikke har været så heldige har det sværere. Vi gør hvad vi kan for at sparre og hjælpe og uddanne de enkelte ScrumMastere, men intet slår erfaring. Et enkelt område har endda haft behovet for at vi har trådt ind som ScrumMaster for at hjælpe processen i gang.

Heldigvis er der andre indikatorer vi kan lede efter for at se om ejerskabet er på rette vej.

Retrospective

Ønsker ScrumMasteren det, faciliterer vi gerne et retrospective for teamet / området, enten i form af sprint retrospective eller retrospective over oplevelsen med agil udvikling indtil videre. Et retrospective er en god indikator for hvordan fornemmelsen for ejerskab går. Og bliver scenen sat rigtigt, er der god grobund for diskussioner omkring bekymringerne og glæderne ved agil udvikling.

Ved de første retrospectives lægger jeg specielt mærke til om der kommer en diskussion om det mekaniske i processen. Fx omkring formen på backlog items eller måske brugen af scrum boardet. Formen af disse er ikke dikteret nogle steder fra, og tager teamet initiativ til at diskutere mekaniske sider af processen, er et stort skridt mod proces-ejerskab taget. Forhåbentligt åbner det for diskussion om alle aspekter af processen senere og dermed er der taget hul på den vigtige inspect-and-adapt cyklus.

Der er skrevet mangt og meget om det gode retrospective, her på QED har Rasmus fortalt lidt om det. Ellers er Derby & Larsen god læsning ligesom Aino Vonge Corry, der har skrevet lidt om emnet her.

Daily Scrum

Under det daglige stand-up er der typisk små hints til om ejerskabet nærmer sig. Bliver der diskuteret impediments eller er alt bare en dans på roser uden torne? Et helt sprint uden nogen hændelser der på en eller anden måde forhindrer eller sløver et team i deres arbejdeter et sjældent syn. Jeg ser derfor en impediment backlog som en indikator for tillid til proces og ikke mindst ScrumMaster.

Men er der andre tegn vi bør holde øje med? Har du erfaring med hvordan man vurdere om et team er på rette vej?

6 comments for “Husk at tage ejerskab ellers dør I

  1. Jeg synes det er interessant at I stiller de 4 spørgsmål med 10 ugers mellemrum. Hvad er jeres overvejelser om ikke at spørge oftere? Kunne man forestille sig at alle teams svarede hvert sprint og at I dermed fik et heatmap over hvor der er mest brug for jer? En slags bat-signal ;).

    • Ideen om et bat-signal er plantet lidt i de enkelte ScrumMastere. De har altid lov til at hive fat i os og få os ud i området for feedback, sparring eller hvad de nu har brug for. Det betyder så også at de ScrumMastere der buldrer mest, får mest opmærksomhed. Det kunne nemt tænkes at et område havde mere brug for os, men at deres ScrumMaster ikke buldrer nok. For at afhjælpe har vi løbende opfølgning på områderne.

      Et semi – automatisk bat signal kunne være en fordel, men implementationen skal vi nok passe på. Det skulle være hurtigt og nemt at opsamle data. Vi prædiker allerede at der bliver lavet et referat af alle ceremonierne for alle sprints. Måske det kunne bruges, hvis vi fik ScrumMasterne til at sende det til os… Det vil jeg overveje at få med!

  2. Eeek.

    Jeg har super lidt tiltro til den slags målinger. Det kan være det blot er mig der er skeptisk/pessimistisk.

    Personligt har jeg haft større held med at lave periodiske “opfølgningssamtaler” med f.eks. Scrum Master, Product Owner og leder for at få en “team status” og evt. sætte nye agile tiltag i søen. De punkter der er listet i surveyen vil typisk også indgå, naturligt, i de punkter som bliver bragt op til diskussion af teamet på retrospectives.

    Du skriver også at det er vigtigt at det er en “erfaren” Scrum Master der tages i ed. Det er naturligvis et ønskeligt scenarie, men jeg finder det mere vigtigt at personen har de rigtige karakteristika – empati, ejerskab, drive og engagement.

    • Jeg burde nok have nævnt at vi skam også har løbende sparring med både Product Owner og Scrum Master 🙂 Vi stoler ikke blindt på spørgeskema undersøgelser, men har dem med som input.

      Vi har valgt også at bruge et anonymt mavefornemmelses spørgeskema for forhåbentligt at undgå for meget Hawthorne effekt. Til de første retrospectives for et team har vi flere gange oplevet at team members ikke er helt åbne omkring deres oplevelser. Det er både til den negative og positive side. Du har helt ret i, at går alt som det skal, bliver spørgsmålene naturligt diskuteret til retrospective.

      Når jeg skriver erfaren ScrumMaster “med et vist drive” er det med det håb at personen så netop har de karakteristika der skal til. Og kan man ikke få begge dele, foretrækker jeg klart en med de rigtige karakteristika frem for erfaring. Men hvordan valget af personer til de forskellige roller foregår er forskelligt fra område til område og kan fylde blog-posts i sig selv.

      • Et umiddelbart spørgsmål fra min side vil så være: Stemmer survey resultaterne overens med mavefornemmelserne og evt. de emner der diskuteres på retrospective meetings?

        • Jeg er usikker på hvad du spørger om?

          De surveys jeg her snakker om er beregnet på – forhåbentligt – at fange medarbejdernes mavefornemmelser for om den agile process har forbedret noget. De resultater vi får ind sammenholder vi med hvad vi ser og hører på retrospective.

          Vi har først lige indført denne survey og har endnu ikke haft anden runde ude i områderne. Så vi kan ikke sige om der er overensstemmelse mellem survey resultater og retrospective – men vi håber det 🙂

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *