Dette indlæg giver dig tips og tricks til at ødelægge sprint planning. 
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 alle team medlemmer bestemme hvad de vil arbejde på individuelt. Der skal ikke være samhørighed i planlægningen blot fordi man arbejder agilt.
- Planlæg så product owner ikke kan deltage eller være i nærheden under mødet. Teamet ved jo alligevel godt hvad planen er for fremtiden.
- Sørg for at projektlederen har detaljerede tidsestimater inden mødet så uddelegeringen sker hurtigst muligt.
- Arbejd gerne i siloer. Opgaver der har en karakter af at gå på tværs af folks kompetencer bør brydes ned. Alle ved jo hvor ineffektivt det er når skal tales, koordineres og samarbejdes i et sprint.
- I mange tilfælde kan sprint planning aflyses med god samvittighed, da teamet alligevel arbejder videre på udeståender som ikke blev afsluttet i sidste sprint. Der er ingen grund til at stoppe op og kontrollere retningen endnu.
- Hvis product owner deltager på mødet, bør han ikke have taletid. Det er teamet og dets autonomitet der giver fremdrift og ikke et fælles mål defineret af ham. Sprint goals er blot et teoretisk begreb som ikke har sin gang i hverdagen!
- Sprint planning kan ofte udføres således at hvert team medlem selv estimerer de opgaver vedkommende skal løse. Så fylder man blot sin egen plan og returnerer til sin arbejdsplads når man er færdig.
- Product backloggen behøver ikke at være prioriteret og internt rangeret af product owner inden mødet. Det kan ofte klares “on the fly” enten af teamet eller af product owner.
- Estimater på opgaverne skal gerne være oplyst på forhånd og allerhelst være beregnet enten af product owner eller en lead developer uden involvering af resten af teamet.
- Det er vigtigt at teamet planlægger opgaver til 120 % af den kapacitet der er tilrådighed. Hvis dette ikke gøres risikerer man at folk sidder og surfer midt i sprintet.
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!
Se de øvrige indlæg i serien:
Hej Rasmus,
Kan du ikke uddybe pkt 4 “Arbejd gerne i siloer” lidt mere – jeg synes du diskutterer både for og imod (eller også læser jeg den forkert) ?
/Jeppe
Hej Jeppe
Det er også et ømtåeligt emne. Man kan tolke det agile manifest på mange måder – én af dem er at alle skal kunne klare alt. Faktum er bare at det sjældent er fornuftigt eller pragmatisk. På den anden side, så kan det være til “skade” hvis folk gemmer sig bag silo-tankegangen og opgaver f.eks. bliver nedbrudt efter hvilket system en pågældende opgave omhandler fremfor at se på det større perspektiv.
Forestil dig en forretningsgang der krydser flere systemer. Hvis man tager en systemetisk, silo baseret, tilgang så brydes opgaven ned i de ændringer der forventeligt skal laves i de forskellige systemer. Det kan have sine planlægningsmæssige fordele, men samtidig give nogle udfordringer for slutbrugeren (manglende sammenhæng i systemerne) og testerne (f.eks. kan visse ændringer være færdige før andre – i en ikke hensigtsmæssig sammenhæng). Hvis systemet er lagdelt og man forsøger at analysere sig frem til alle ændringer der skal til i de nedre lag før man kigger på de øvrige lag kan man risikere en forfærdelig masse tilbageløb.
Den idealistiske agile tilgang vil være at forsøge at implementere hele features fra top lag til bund lag i et sprint. Det er naturligvis ikke altid muligt, men det bør være udgangspunktet.
Håber det gav lidt mere indsigt i min holdning 🙂
Det er en rigtig interessant problemstilling du bringer op, specielt fordi der er mange aspekter der spiller ind.
Det centrale spørgsmål er hvordan er projekt organiseringen mht. de forskellige systemer og hvordan aligner det med den/de arkitekturer der anvendes. Hvordan er kommunikations kanalerne, sidder folk tæt på hinanden, deler de deadlines, er deres sprints alignet?
Domain Driven Design (DDD) har introduceret et sprog for at beskrive hvordan samarbejdsformen mellem projekter er og hvordan man kan håndtere det kode mæssigt/arkitekturelt (f.eks. shared kernel, supplier/consumer, separate ways, anti corruption layer, etc.)
Hvis organiseringen ikke er alignet med system og domæne boundaries så bliver det nemt som at padle mod strømmen pga. Conways law – “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. Det er svært at arbejde mod den menneskelige natur, det er meneget nemmere at arbejde med den, hvis man forstår den 🙂
Der er flere idealistiske måder at løse det på i en perfekt verden hvor afd. ledere ikke jagter hver deres egne mål (og bonusser), hvor organiseringen er alignet med arktekturen og domænerne, hvor forretningens forskellige områder arbejder sammen om fælles mål og ikke bekriger hinanden, hvor data ejerskab er klar og data duplikering minimal eller i det mindste korrekt udført mht. ejerskab og hvor koblingen mellem systemerne er tilpas løs (f.eks. ingen eller minimale synkrone kald mellem systemerne – se http://qed.dk/jeppe-cramon/2014/02/01/soa-synkron-kommunikation-data-ejerskab-og-kobling/ ).
Det kan være svært at opnå i store organisationer, hvor man typisk er endt op med store monolitiske systemer, matrix organisering, en masse synkrone integrationer til følge. Rom blev ikke bygget på en dag, men det er bestemt min erfaring af man iterativt kan arbejde frem mod en anderledes organisering og arkitektur, men det kræver at man har sat sig nogle mål, ledelsen bakker op og alle arbejder frem mod det slice by slice.
Det sker bare sjældent. Det jeg oplever i de fleste store virksomheder er et forsøg på at få status quo til at virke bare lidt bedre, og hvis det ikke virkede før, så prøver vi endnu hårdere; med lidt mere bureaukrati, lidt mere top styring. De har indset at det er svært at padle mod strømmen, så derfor har de skiftet pagajerne ud med en motor. Det er lidt “doing the things right vs. doing the right thing”.
Det der efter min mening nok er det sværeste er ændre er organiseringen og kulturen og der også tit der at agile tiltag dør eller bliver stækket.
Jeg er stor tilhænger af silo orienteret arbejde, men det kræver at siloerne er tilpas små og er løst koblede fra de andre siloer (synkron integration er undtagelsen). Det kræver endnu mere fokus på organiseringen, den tværgående koordinering og analyse og ikke mindst fokus på at arkitekturen understøtter dette. Min næste blog post i SOA serien kommer til at behandle det emne.
Hej Jeppe
Jeg er ikke nødvendigvis modstander af siloer. Det er bare ikke nødvendigvis en opdeling man skal bestræbe sig på at opnå.
Det er naturligt, for de fleste teams, at arbejde med specialiserede opgaver og deraf opstår der ofte siloer.
Min pointe er blot at man skal overveje nøje hvornår opgaver skal nedbrydes i siloer og hvornår man hellere skal arbejde med det store overblik (og tage stilling til integrationsflader m.m.)
Hej Rasmus,
Når du snakker om siloer, hvilket granulerings niveau har du i tankerne?
For mig kan en silo kan være en aggregate (en samling af samhørende objekter mht. transaktionalitet og konsistens) eller en bounded context (et område hvor sproget et samhængende og konsistent, kan typisk indeholde flere aggregates). Et team kan være ansvarlig for en eller flere bounded contexts.
Man kan også se et team som en silo, en applikation kan også være en silo (der skal koordinere med andre siloer).
Jeg mener at silo tanken og overbliks tanken går hånd i hånd. Det er ikke en enten eller. På et hvert ikke trivielt projekt vil jeg mener at du har behov for begge dele.
Troen på at vi kan håndtere det hele udelukkende som lagdeling har vist sig ikke at holde når kompleksiteten stiger. Jeg mener man har brug for silo tanken for at holde tingene adskilt. En af måderne (hvis vi snakker et enkelt system/bounded context) er at benytte feks. hexagonal arkitektur der tillader at arbejde lagdelt/horizontalt (med de specialisering fordele der er der) kombineret med en vertikal/silo opsplitning i form af adaptere. Opsplitning vertikalt kan ikke ske uden at være fokuseret på at etablere overblik og sikre det løbende.
/Jeppe
Hvad enten du arbejder i siloer eller lagkage-form så vil der altid være integrationsflader. Opgaver bør, efter min mening, defineres så de dækker integrationsfladen. Det er på dette niveau jeg mener folk skal samarbejde.
Say, you got a nice blog article.Really looking forward to read more. Want more.