“Man plans and God laughs” ~ gammelt jødisk ordsprog.
For nu at sige det skarpt: planlægning er spildtid, som tager energi væk fra det faktiske arbejde. Måske er planen allerede forældet i det øjeblik den er færdig. Måske kommer der en fantastisk forretningsmulighed ind fra højre som bliver prioriteret højere end alt hvad der ligger i den oprindelige plan. Måske bliver vores eneste databasemand ramt af en bus i morgen og det vil tage uger ud af planen at sætte en ny ind i opgaverne.
På den anden side: uden planer og fælles vision løber vi i hver sin retning og så kan det være ligegyldigt hvor hurtigt vi løber og hvor hurtigt vi er kommet i gang med at løbe. Hvem kan bygge et hus uden en plan? Selv hvis vi får bygget huset, så bliver det en bastard, hvor f.eks. vandrør løber uden på murene fordi ingen havde tænkt dem ind fra starten og det var der de kunne komme til at løbe, da man kom i tanke om at de også er nødvendige. I kodeverdenen er det utænkeligt at man starter et projekt med flere deltagere op uden at fastlægge et minimum af fælles ting, såsom fælles sprog, en måde at håndtere en fælles kodebase (f.eks. versioneringssystem) og aftaler om samarbejdets natur.
Begge ekstremer er altså utiltrækkende, så vi skal finde en god balance mellem dem. Lidt vejledning finder vi i det agile manifest.
Set i kontekst lyder det fjerde og sidste punkt i det agile manifest (se også punkt 1, punkt 2 og punkt 3):
Through this work we have come to value:
– Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Vi skal altså sætte håndtering af forandringer over at følge planen.
Det betyder ikke at vi ikke skal planlægge overhovedet (som det til tider udlægges), men at vi skal være klar til at lave planerne om. Vi skal acceptere at vores planer ofte skal revideres og derfor giver det ikke mening at bruge energi på at lave en stor detaljeret plan på forhånd. Som allerede nævnt kan planen være forældet i det øjeblik den er færdig (/godkendt af ledelsen/sat i sten ved at sende pressemeddelelser ud med faste udgivelsesdatoer).
Hvis vi skal se på hvordan det ser ud i praksis i en agil metode som Scrum, så anbefaler Scrum at vi kun detaljeplanlægger en overskuelig fremtid aka et sprint, som typisk er 2-4 uger. Resten af planlægningen består i en liste over hvad der mangler at blive lavet med en midlertidig grovkornet prioritering.
Selv i planlægningen af sprintet godtager vi at der kan komme ændringer, men vi håndterer det lidt mere stringent end ændringer som ikke påvirker vores nuværende sprint for at gøre det tydeligt at vi ikke følger planen – sådan et værktøj er f.eks. et sprint abort. I sprintet prioriterer vi altså at følge planen eller skrotte den og lave en ny.
Andre agile metoder lægger snittet mellem planlægning og håndtering af forandringer anderledes (Kanban sætter f.eks. næsten ingen grænser for omstillingsparatheden udover at man færdiggør det man er i gang med), men fælles for dem er at vi altid tilstræber os på at arbejde på det der har størst værdi lige nu – og afvejer det med at vi ikke kommer nogen vegne ved at skifte retning hvert femte minut (/time/dag). Der skal være plads til fordybelse og ro til arbejdet.
Det er altid en balancegang mellem “vi detaljeplanlægger for at undgå at vi arbejder på det forkerte” og “al planlægning tager tid væk fra det faktiske arbejde og er spild fordi planerne aldrig holder”. I en verden der ændrer sig vil der altid være spild – det er kun et spørgsmål om hvorvidt spildet er en fejlet plan eller kode der ikke kom med i den endelige version… eller en kombination af de to.
Hvor langt ind i fremtiden planlægger I?
Godt blogindlæg!
Jeg tror det er svært at lave agil planlægning, hvis kunden ikke er med på at køre 100% agilt. Hvis man som IT-leverandør har lavet en kontrakt med en kunde og skrevet under på at levere software med de og de funktionaliteter til en bestemt deadline, så er det svært ikke at blive nødt til at lave en planlægning, der går i detaljer.
Selvom det som oftes alligevel går galt med planlægningen, idet man ikke når al den lovede funktionalitet – eller også skubber man deadlinen for at få det hele med.
Derfor er det vigtigt at kunden stoler på IT-leverandøren mht. hvad der i sidste ende bliver leveret af features. Og så er det mindre vigtigt at få udpenslet alle lovede features i en kontrakt, men måske mere overordnede funktionalitet.
Det som du berører Helena er jo lidt et tabu i branchen. Hvis deadlinen og featuresættet er sat i sten, så er den parameter vi kan skrue på kvaliteten… og hvem vil indrømme at de skruer på den?
Jeg er stor tilhænger af at man – hvis omstændighederne tillader det – også lader featuresættet være en justerbar parameter. Jeg har ofte i dialog fundet ud af at forretningen/kunden hellere vil launche uden enkelte features og så launche kvalitet til tiden… også selv om de ønsker sig alle de fancy features med tiden.
Som du nævner kunne det også være deadlinen der kunne skrues på, men samtidig skal man huske at få noget ud, så vi kan få noget feedback. Derfor kan det være en glidebane at skubbe en deadline foran sig (og bliver deadlines taget seriøst, hvis man er vant til at de kan skubbes?) – ikke at det skal forstås som om jeg mener at man aldrig kan skubbe en for stram deadline.
Med hensyn til hvor detaljeorienteret en kontrakt er, så er et svar “it depends”. Det er utroligt svært at skrive noget generelt om, fordi selvfølgelig skal man gøre, hvad der giver mening i situationen. Har man tillid mellem parterne kan man slippe afsted med langt mere end hvis man ikke har :). Det er en af grundene til at jeg godt kan li’ det agile manifest. Disse emner er ikke sort-hvid/ja-nej, men det er guidelines om hvilken retning vi skal foretrække at læne os i, hvis vi har valget.
Plans are worthless, but planning is everything
Tak for endnu et godt blogindlæg!
Jeg kan helt sikkert genkende den udfordring Helena nævner: Det kan være svært at forklare en kunde, at planerne under alle omstændigheder ikke holder 3 mdr. fremme i tiden. Uden at kunden får en følelse af, at det er fordi man er inkompetent. Min oplevelse er også, at der er et element af tillid som spiller ind, og som ikke er specifikt adresseret af de agile principper. Eller har jeg misset noget?
Helt konkret så arbejder jeg med følgende 3 niveauer af planlægning. Der alle forsøger at holde planlægning på et minimum og som samtidig sigter mod at “get the most bang for the buck”:
– Planlægning af roadmap, hvor PO opstiller en vision for hvert kommende release. F.eks. for det kommende halve eller hele år. Vision skal være helt overordnet, uden at gå i detaljer. F.eks. “Bruger skal kunne oprette konto”/”Kunde kan submitte ordre” og lignende. Der skal være slack til at ændre detaljerne. Godt link IMHO: http://www.romanpichler.com/tools/product-roadmap/
– Planlægning af sprint: Sikre, at user stories i sprint backlog er “skåret” efter MVP-tankegang. Så man f.eks. undgår, at funktionalitet ikke kan afsluttes indenfor sprint. Sikre, at der er “fornuftige” tasks på alle user stories i sprint backlog, hvilket indikerer, at forventninger er afstemt og opgaven klar. Godt link til MVP-tankegang: http://www.planetgeek.ch/2014/06/06/effective-teams-start-with-minimal-solution/
– Daglig planlægning hos hvert medlem af team. Vi kører typisk 2-ugers sprints, hvilket vil sige 10 arbejdsdage. Det er tilpas få til at de kan overskues, og den enkelte udvikler kan efter planlægning af sprint have en skitse til arbejdsplan for disse 10 dage. Hver dag er opgaven så at løse een task ad gangen – kanban-tankegang – og altid tænke i at løse de tasks, der fører til, at en user story kan leveres.
Tak for kommentaren og linksne Christopher!
Tillid er nødvendigt for at opfylde især punkt 3 i det agile manifest, men derudover er manifestet ikke der hvor tilliden bliver fremhævet. Det er mere når vi snakker om de agile værdier at tillid kommer på bane sammen med respekt, feedback, simpelhed, mod og kommunikation.
Superfedt at høre om jeres niveauer af planlægning, Christopher. Jeg er nysgerrig omkring hvordan team-medlem-planlægningen fungerer. Arbejder I ikke i teams? Hvis I arbejder på hver sin plan, hvordan håndterer I samarbejde?
Jo, vi arbejder i teams, og det er naturligvis teamet som helhed, der påtager sig at levere de user stories, der lægges i backloggen for et sprint.
Min brug af betegnelsen “daglig planlægning” er ikke i den forstand, at det enkelte medlem af team skal lægge en udførlig plan som et slags solo-løb. Min erfaring er bare, at når vi laver planlægning af sprint så er det en god idé, at alle lige tænker igennem, hvad sprintet betyder for vedkommende. Sådan i stil med: “Det vil være godt, hvis jeg kan have de og de tasks løst til på onsdag, og så kan jeg torsdag sidde sammen med Rasmus, så vi sammen kan koordinere den snitflade som hans kode skal udstille og jeg skal kode op i mod i næste uge.”. OSv. osv. Lidt på sammen måde som man som mental træning kan gennemtænke en løberute.
Jeg oplever, at dette er med til at gøre daily scrums mere handlingsorienterede og “to the point”. I den forstand, at det enkelte medlems daglige rapportering bliver en både individuel og fælles ajourføring af planen for afvikling af sprint.