I mit daglige virke som agile coach har jeg observeret en række guldkorn der alle bidrager til nedbrydning af den agile tankegang. Følg med i de kommende indlæg og få flere hints til hvordan DU saboterer med størst mulig virkning!
- Lad projektlederen styre slaget. Det er vigtigt at alle er indforstået med vigtigheden af projektlederen. Det er udelukkende ham der kender status for projektet og det falder derfor naturligt at han rapporterer status på fremdrift over for teamet. Hvis muligt, så læser projektlederen op fra projektplanen således at alle er informeret om hvilke opgaver de afsluttede den foregående dag og hvilke de skal arbejde på samme dag.
- Sørg for at lave afrapportering omkring alle detaljer i opgaverne. Skulle det uheldige ske, at team medlemmerne får taletid på det daglige møde, så skal de sørge for at gå dybt i detaljen omkring løsning af deres opgaver. Alle kender jo til vigtigheden af opgaverne og bør derfor også kende til alle overvejelser og tanker.
- Afhold møde separat for alle lokationer (hvis der arbejdes distribueret). I disse moderne tider arbejder teams ofte på tværs af landegrænser. Det er et faktum der ikke kan ændres. Til gengæld kan teamet selvstændigt bestemme at afholde separate daily standup således at der bliver skabt en solid atmosfære omkring ansvarsfordelingen – det skulle nødig hedde sig at alle trækker på samme hammel.
- Hvis der er scope ændringer i opgaverne behøver det ikke at blive afsløret før det ugentlige statusmøde. Projektlederen er naturligvis informeret og han har korrigeret planerne. Der er ingen grund til at involvere de øvrige team medlemmer i de drastiske ændringer i scopet før senere – det påvirker jo alligevel ikke andre i gruppen!
- Hvis team medlemmerne ikke har planlagt hvad der skal arbejdes med i dag, så bare fortæl det samme som i går. Så går det også meget hurtigere med at få afviklet daily standup og alle kan komme tilbage til deres skærm for at arbejde. Det giver alligevel ikke mening at informere om stilstand i fremdrift eller problemer med implementering af den valgte løsning – det skal jo fixes alligevel.
- Det betyder ikke noget om folk møder op til tiden. Hvis team medlemmerne ved at de alligevel ikke får taletid først i talerækken, så må de gerne støde til senere. Det vigtigste er at projektlederen og scrum masteren bliver opdateret på status, ikke så meget om de øvrige team medlemmer får informationen.
- Brug gerne 30-60minutter på det daglige møde. For at få fuldt udbytte af møderne er det vigtigt at diskussioner og drøftelser omkring problemløsning bliver færdiggjort direkte på mødet. Hvis det udskydes risikerer man blot at glemme det. Desuden er det også vigtigt at hele teamet hører om hvilke løsninger der er i spil for at løse problemet.
- Det er ikke vigtigt at alle får taletid. Hvis der er afsat 15 minutter, så skal mødet afvikles på 15 minutter. Så er det bare ærgerligt hvis ikke alle får taletid – de kan blot få taletid først i talerækken den efterfølgende dag.
- Hvis der er kommet vigtig information fra ledelsen, kan de blot få ordet på mødet – så er alle samlet alligevel. Den opdaterede status fra teamet kan projektlederen og scrum masteren eventuelt komme rundt og høre individuelt senere således at grafer og deslige bliver opdateret til afrapportering.
- Det gør ikke noget at alle ikke er forberedt. I det store hele gør det jo ikke den store forskel, hvorvidt alle møder op til mødet og har tænkt over hvad gårsdagen blev brugt på og hvad der skal ske samme dag. Det er vigtigt at improvisere lidt, så alle ved hvor travlt der er i projektet!
Jeg håber virkelig at disse observationer vil blive taget i mod med kyshånd. Skriv gerne en kommentar hvis du har forslag til yderligere punkter eller har erfaring med implementering af ovenstående. God vind!
Læs også artiklen på engelsk:
Se de øvrige indlæg I serien:
Til at starte med synes jeg din post bare var god humor, men jo mere jeg tænker over det, bliver jeg trist over hvor mange steder jeg hører at det daglige standup er afrapportering. Medarbejderne er der for projektledelsens skyld og projektledelsen er ikke interesseret i at afgive en millimeter af kontrol – og gider ikke høre, hvilke roadblocks de kunne bruge deres tid på at fjerne… de har jo alt for travlt med at “styre” projektet.
SUK!
Der findes mange måder at implementere og anvende disse daily standup møder på – og de er ikke alle lige effektfulde (de kan dog godt være effektive).
Det store spørgsmål, for mig, er hvad ønsker folk at få ud af mødet? Hvis formålet er at projektlederen er opdateret på status; så kan det måske være det er OK? Hvis formålet er at skabe samhørighed og samarbejde på tværs – så er det formentlig ikke OK!
Hvis man afholder et afrapporteringsmøde og tror at man kører et agilt daily stand-up, så er der nogle dybere ting, man skal have kigget på. Som du skriver handler det om ønsket udbytte, men micromanagement og afrapportering frem for aktiv deltagelse er i hvert fald ikke agilt.
Det handler generelt om at have en fælles forståelse for hvorfor man gør det man gør. Hvis man vil afholde et Daily Standup i kontekst af agiludvikling så er formålet at skabe samhørighed, team spirit og hjælpe hinanden med at opnå et fælles mål. Hvis man nærmere er ude i et operationelt driftmøde hvor der skal rapporteres status, så er formålet et andet – hvilket sikkert kan være fornuftigt, det er bare ikke specielt agilt 🙂
Hehe. 😉
Fint provokerende indslag. Nogle gange får man mest ud af at vende tingene på hovedet.
Jeg får lyst til at spørge – hvad mener du med projektleder her? Det er en titel, hvis mening efterhånden er blevet ekstremt udvandet. Er det afdelings/gruppelederen – evt. med personaleansvar – og evt. ham med rapporteringsansvaret opadtil?
Hvilken rolle har han i den agile udvikling? Er han PO? Eller er han bare en andre stakeholders? Eller er han i virkeligheden ikke rigtigt noget indenfor modellen?
Jeg spørger fordi jeg efterhånden er blevet lidt skeptisk overfor mellemlederroller i scrumbåren udvikling, der ikke har nogen fornuftig rolle indenfor udviklingsmodellen.
Opinions?
Hej Troels
Reelt er dit spørgsmål noget der kan besvares med “det kommer an på …”
Projektlederen/mellemlederen er en rolle der tit bliver overset i mange agile projekter. I mit hoved findes der to forskellige forløb for scrum teams:
1) Et kontinuert forløb
2) Et tidsbegrænset forløb
I det kontinuerte forløb nedsættes et “stabilt” scrum team der løbende modtager nye opgaver via backlogs. Et sådan team har ikke nødvendigvis en projektleder, men nok nærmere det du betegner som en “afdelings/gruppeleder”. Hvorvidt vedkommende har personaleansvar er i princippet ikke så vigtigt, det vigtige er at vedkommende er ansvarlig for f.eks. rapportering og håndtering af impediments.
I det tidsbegrænsede forløb nedsættes et projekt scrum team der fra starten af har en begrænset “levetid”. Det er samme struktur som man kender fra traditionelle projekter. Her er en projektleder ansvarlig for alt hvad der hedder rapportering, projektplaner samt håndtering af impedients.
Efter min opfattelse så er han ikke nødvendigvis Product Owner og indgår heller ikke nødvendigvis i et Product Owner Team.
Hej igen
Tak for udførligt svar. Jeg vil kvittere med lidt mere om mine tanker. 🙂
Hmmm, ok, jeg tror at jeg er enig med dig et godt stykke af vejen. Enig i at der er behov for at der bliver afrapportering og projektplaner bliver håndteret, og jeg har også mødt at der kan være en tendens til at det kan blive glemt i agil udvikling.
Hvor personaleansvaret ligger er nok ikke så relevant her, enig.
Håndtering af impediments for teamet forankres bedst i det nære, er min holdning. En scrummaster, der ikke er bange for at banke et par døre ned, kommer et langt stykke af vejen.
Ifht afrapportering og projektplaner:
Konkret har jeg haft (og set) bedste erfaringer med at det håndteres af personer med roller indenfor udviklingsmodellen. Det bliver en naturlig del af modellen at PO og scrumteam (med scrummaster som tovholder) sammen løbende skal justere planer, hvad vi forventer at kunne levere til hvornår, at vi har opgaver på at afrapportere til visse stakeholders osv. PO og scrummaster er i forvejen typisk de personligheder der har bedst styr på at der ikke er noget der falder i mellem gulvbrædderne, men alle skal tage det seriøst.
Jeg har været både gruppeleder og scrummaster på et team, hvor der var en separat projektleder, der fulgte op og sørgede for opsamling til brug for afrapportering. Det blev ærligt talt noget rod, fordi det blev hæftet på siden af de interaktioner team, scrummaster og PO/gruppeleder allerede havde. Udviklerne følte at de nu skulle forklare én til hvad de lavede, og i modsætning til team, scrummaster og PO føltes grunden til at projektlederen skulle høre om progress mindre relevant. Som scrummaster skulle jeg passe på ikke at træde projektlederen over tæerne (som scrummaster opfatter jeg det som en central opgave at have styr på hvad der sker på teamet, og om det sker fornuftigt). Og som PO/gruppeleder endte det med at jeg havde mindre kontakt med mine udviklere end tidligere, men bare fik snakket med projektleder og scrummaster.
Der er garanteret andre måder at fordele ansvaret på, men det var sådan det landede hos os.
Så det holdt vi op med. 🙂