Forleden var jeg til middag med en gammel bekendt som nu er CEO i en mindre dansk finansiel virksomhed. Snakken faldt på Agile, og pludselig udbryder han
“…jeg har lige landet en super aftale med en ny kunde, og da jeg så spørger IT-folkene hvad det kræver at udvikle den nødvendige tekniske løsning, svarer de ‘175 point’. 175 point?! Hvad fa’en skal jeg bruge det til??“
Situationen er velkendt og virkelig en gammel traver indenfor agil udvikling, nemlig mødet mellem traditionel tænkning (her er scope, hvad koster det og hvornår kan I levere det?) og agil tænkning (vi ved faktisk ikke hvordan slutproduktet ser ud, men vi skal hurtigst muligt finde frem til om, og hvordan, vi kan levere det). Man kan næsten kalde det Agiles svar på “El Clásico”.
Klassisk skyttegravskrig mellem traditionel og ny tænkning
Jeg ser denne konflikt igen og igen, både fordi det agile Rom ikke blev bygget på en dag, og fordi behovet for én eller anden form for økonomisk vished naturligvis er helt legitim. Det ender ofte med en ukonstruktiv skyttegravskrig som kan blive ved i det uendelige.
På den ene side er der behov for vished og sikkerhed for en investering i et nyt produkt. Men hvor mange IT-projekter er ikke startet med en grundig foranalyse og et seriøst estimat (måske endda startet med et forudgående “guestimat” – som om et estimat ikke også er gætværk?!) og endt med at det var skudt flere hundrede meter over mål?
På den anden side er der behov for en grundig forståelse af hvad der egentlig bliver efterspurgt. Men hvor mange projektmedlemmer er ikke endt med at grave sig ned i store uproduktive huller uden konkrete leverancer i måneds-, ja måske endda årevis med dårlige relationer, stress og ringe kvalitet til følge?
Selv i virksomheder der praler af at “være agile” (og dem er der efterhånden ret mange af) hører jeg ofte bulderet og bragene fra skyttegravskrigen runge på gangene.
Løsningen er et fælles mindset
Så hvad skal min gamle bekendte gøre? Og hvad skal IT-udviklerne i hans virksomhed gøre? Svaret er, at hvis Agile skal virke, bliver ledelse og medarbejdere nødt til at beslutte sig for at gå i en ny retning. Sammen! Og det kræver omstilling fra begge sider.
Lad os starte med det agile team, som bliver nødt til at tage Agile seriøst. Det kræver bl.a. at teamet:
- udviser den nødvendige disciplin mht. selvorganisering og tager ansvar for sine leverancer (både teammedlemmernes egne men også kollegernes),
- måler egen performance og aktivt forholder sig til hvad der skal til for at forbedre den,
- viser respekt for at der ikke bare bliver hældt penge ned i et bundløst hul hvis leverancerne udebliver,
- følger evt. storypoint estimater op med dokumentation for en stabil velocity så story point estimater rent faktisk giver mening – også for teamets omverden (og hvis velocity ikke er stabil endnu, et bud på hvad der skal til for at stabilisere den) samt
- laver et bud på et roadmap, i hvert fald 3-6 måneder frem i tid.
Og lad os dernæst fortsætte med ledelsen, som faktisk også skal tage Agile seriøst. Det kræver bl.a. at ledelsen:
- erkender at krystalkuglen må en tur på genbrugspladsen (økonomi, scope og tidsplan er dårlige parametre til at måle værdiskabelse),
- begrænser “ressourceallokering” til et absolut minimum for at sikre teamet den nødvendige arbejdsro,
- efterspørger output fra retrospektives eller lignende i en form der er operationel og forståelig (fx en konkret top 5 med teamets største forhindringer),
- viser vilje og evne til at fjerne disse forhindringer for teamet, samt
- beder om kendskab til teamets strukturerede målinger af egen performance og afholder sig fra at pege fingre (man får jo som bekendt hvad man beder om).
Ansvaret er fælles
For medarbejdere og ledelse er Agile altså med et godt ikke-dansk udtryk en såkaldt “two way street”, og det handler først og fremmest om at tage et nyt mindset. Det er ikke altid nemt. Det er ikke altid kønt. Men blodpletterne fra skyttegravskrigen sviner dog meget mere…
Hvad mangler på mine to punktlister? Hvad er dine erfaringer med hvad der virker og ikke virker i din virksomhed. Alle gode forslag og input vil blive modtaget med kyshånd i kommentarfeltet nedenfor…
8 Comments
Leave A Comment
You must be logged in to post a comment.
Jeg er i princippet enig i dine punkter. Men måske skulle man krydre det lidt med et punkt omkring kommunikation. Det er min erfaring at når man kommunikere som bla team at man lige tænker over hvem modtageren er. Her er det CEO og her vil jeg forvente at der tænkes i omkostninger kontra indtjening, strategi og pmo prioitering. Så i den historie som er fortalt her kunne man kigge lidt på de historiske tal man har i virksomheden. Og nu bevæger jeg mig lidt ind i et minefelt hos noge agile evangelister. Men de tidligere projektet man har kørt hvor mange storypoint har de kostede og kombinere man det med den tid som faktisk er lagt har man da et lidt bedre kommunikationsgrundlag. “Vi tror det tager 175 sp hvilket i vores team ca svare til xxx timer = xxx kr. Det er vores bedste bud her og nu. Men vi vil blive klogere undervejs. Skal vi kigge på en hurtig nedbrydning og sætte noget forretningsværdier på disse.”
Bare mine tanker.
Hej Peer. Mange tak for din kommentar og jeg er med dig her – og forstår også godt hvorfor du beskriver det som et minefelt. Jeg har før arbejdet med agile teams der er blevet så gode at de kan udtale sig om prisen på et storypoint, men det er godt nok en fin balancegang man skal gå her! For det ender jo hurtigt med at hele idéen med story points falder til jorden, hvis der pr. automatik forventes en omregning. Og jeg har også arbejdet med teams hvor en sådan konvertering skabte langt mere forvirring end klarhed. Uha, denne diskussion kan man jo bruge en hel aften på…
Enig men man holder balancen er druen brugbar metode. Har selv brugt den med kraftige klare meldinger om forsigtighed.
Men hvis man anvender SP og samtidige registrer tid til økonomi opfølgning har man faktisk valgt den vej.
Ser ikke et problem med omregning – kunden har vel krav på svar.
“…175 point betyder at teamet har taget stilling til opgavens størrelse, kompleksitet og usikkerhed. Baseret på teamets kapacitet, load og velocity (erfaring), bør scope (stories) og leverancetidspunktet kunne synliggøres overfor kunden”.
Hej Dan
Tak for kommentaren. Der poppede flere ting op i mit hoved da jeg læste den. For det første: “Kunden har vel krav på svar”. Men svar på hvad? Hvis det er leverancetidspunktet, så kan teamet godt komme med et bud på hvornår alle 175 point er leveret, men det er jo ikke særlig agilt (der er en vis risiko for at det alligevel ikke holder). Begreberne ‘scope’ og ‘leverancetidspunkt’ er naturligivs ikke irrelevante, men jeg tror verden ville være et bedre sted at være, hvis der lige så tit blev stillet spørgsmål som “hvilken værdi ønsker I at skabe?”, “Hvilken mindre del kan vi starte med for at finde ud af om dette overhovedet er en god idé”, “Hvad skal vi putte ind i en første iteration for at blive klogere”.
Men derudover giver jeg dig helt ret i at teamet bør ledsage sit svar (de 175 point) med nogle oplysninger om netop kapacitet, load og velocity – eller også skal ledelsen bliver bedre til at efterspørge disse oplysninger…
Gode punkter.
Der bliver lagt op til input hvilket altid er positivt i mit verdensbillede.
Et punkt der kunne tilføres kunne være: Outcome vs Output. Dette passer godt til fælles ansvar og mindset.
Hvis der kun fokuseres på outcome stopper rejsen tidligt. Retning og Vision vs Hvad Koster det? To vidt forskelle mindstes
Edit ?
Gode punkter.
Der bliver lagt op til input hvilket altid er positivt i mit verdensbillede.
Et punkt der kunne tilføres kunne være: Outcome vs Output. Dette passer godt til fælles ansvar og mindset.
Hvis der kun fokuseres på output (edit) stopper rejsen tidligt. Retning og Vision vs Hvad Koster det? To vidt forskelle mindstes
Tak for kommentaren, Thomas – og meget enig. Outcome er en meget mere interessant parameter end output. I hvert fald på sigt. Men den er nogen gange sværere at arbejde med og ikke mindst synliggøre.