Da jeg tidligere skrev om Kniberg scrum checkliste faldt der pludselig nogle brikker på plads for mig - og jeg vil gerne dele nogle af dem med jer her, men lov mig til gengæld, at tilgive mig på forhånd, hvis der i virkeligheden er tale om, at jeg er den sidste til at indse det indlysende!
Og hvad er det så, som er gået op for mig? Jo, at demo er vigtigt for et godt scrum.
Tit springes demo over, og vel som oftest fordi at det er en noget kunstig affære - en ceremoni, som der står i teoribøgerne, at man skal lave (som f.eks. førnævnte checkliste)- og så laver man det. Sådan har mange af de demoer, som jeg har deltaget i på diverse teams i hvert fald været, og er der noget, som vi ikke har tid til i en agil verden, så er det ceremoni!
Vi har også prøvet at efterrationalisere over det, og som oftest har det været noget med, at vi med demoen markerede, at vi var færdige - eller med andre ord en slags sejrsdans over sprintet. Hmm - hvis ikke man har styr på sit done-kriterium, så vil ikke nok så mange demoer hjælpe en ... og hvem har ikke oplevet en demo af noget, som i virkeligheden viste sig at være foilware? Nej, jeg mener ikke, at det er derfor.
Et andet argument var, at nu havde vi arbejdet på så mange forskellige ting i løbet af sprintet, at det var godt, at vi fik lejlighed til at vise det frem for hinanden. Hmm i anden - der er forhåbentlig kun et team, og det har forhåbentlig allerede arbejde sammen imod samme mål i et helt sprint ... så hvad er der lige at vise hinanden? Næh, det kan heller ikke være derfor.
Lad os i stedet kigge på nogle af de andre elementer i scrum:
Vi har for det første en Product Owner (ja, altså en rigtig en, som skal leve - eller dø! - med det, som vi laver, og ikke sådan en "produkt-stråmand", som man desværre alt for tit ser i stedet for), fordi at vi hele tiden vil lave de ting, som er til størst nytte.
Vi har for det andet retrospectives, fordi at vi hele tiden vil forsøge at gøre det bare lidt bedre (og fordi at vi ved, at gør man det hele tiden lidt bedre, så bliver det meget bedre på langt sigt!).
Hvad er demoen så? Jo, det er det sted, hvor vi som team får direkte feedback fra dem, som skal leve af og med resultatet af vores arbejde. Hvis Product Owner er en rigtig Product Owner, så er han helt essentiel for, at demoen giver værdi: for temaet skal opleve, hvor han griner og hvor han græder. Men det skal ikke kun være begrænset til Product Owner selv - der må meget gerne være andre slutbrugere til stede - de som også skal leve af, og med, det som temaet har frembragt.
Som et naturligt resultat af en demo vil hele teamet have en forståelse af, hvad som virkede godt, og hvad, som virkede mindre godt - og det er en viden, som teamet kan tage med direkte med tilbage i dets arbejde på løbende at forbedre processen.
Demo skal derfor falde rimeligt kort efter sprintets afslutning, og gerne inden retrospektiv, for en god demo vil danne et godt udgangspunkt for diskussionen på retrospektivet.
Teamet vil, når det har mødt brugerne, også naturligt få en bedre forståelse for baggrunden for de ønsker, som det fremover skal arbejde med realisere, og vil derfor være væsentligt bedre rustet til dette.
Demo har også en anden værdi - for i scrum fokuserer man hele tiden på, at levere noget, som gør en synlig forskel ... og hvordan kan man vise noget frem, som ikke gør en synlig forskel? Demoen er dermed en indikator af, om Product Owner og temaet tilsammen evner at fokusere på det rette ... falder det svært eller unaturligt at lave en demo efter et sprint, så spørg jer selv, om det er det rette, som man har brugt tiden på?
Endelig er der jo det faktum, at der ikke er noget mere motiverende end at vide, at man har gjort en positiv forskel - og det gælder også for et scrumteam.
5 kommentarer:
Et af de problemer jeg har oplevet i forbindelse med demoer er at de kan virker temmelig påtaget, fordi stort set alle deltagerne ved demoen allerede har set de ting der demonstreres. Dette er f.eks. tilfældet på projekter med høj grad af interaktion mellem teammedlem og andre projekt interessanter (product owner mm.). Her har man typisk allerede i løbet af selve funktionalitetsudviklingen haft de relevante folk forbi til sparring og fremvisning af hvad der bliver udviklet. I dette tilfælde bliver selve demo'en ved sprint afslutningen hurtigt til en opsummering af hvad der er blevet vist undervejs i sprintet. Derfor kan selve demonstrationen da sagtes bidrage med noget, men som ved alle andre møder skal man kraftigt overveje om den tid man 'tager' fra alle mødedeltager, ikke er givet bedre ud til andre aktiviteter.
Et andet problem med demostrationer ved sprint afslutninger er at de (som alle andre af SCRUM ceremonierne) fungere bedst i den 'lette' del fase af et udviklingsprojekt, dvs. under selve funktionalitetsudviklingen i midten af projektet.
I starten af et projekt, hvor det meste af tiden går med kravsafklaring, planlægning, opsætning af udviklingsmiljø osv. kan det være meget svært at finde ordentlige demonstrerbare resultater at fremvise, det er ikke helt det samme med en demonstration bestående af par word dokumenter og et regneark.
På samme måde for den sidste del af et projekt, hvor tiden for det meste går med bugfixes, integrationer, deployments osv. Også her kan det være meget svært at fremvise resultater ved sprint afslutningen, uden at det har karakter af en gennemgang af issuelisten for det forgangne sprint.
Gode pointer, som jeg helt kan tilslutte mig. Hvis der udelukkende er tale om indholdsløs ceremoni, så har det ingen plads i et fornuftigt drevent projekt.
Men tit så er der langt ud til der, hvor "hverdagen" er, selv med en ideel product owner, og det er helt essentielt, at projektgruppen får feedback fra dem, som skal leve med det (og ikke kun de chefer eller indhyrede "professionelle", der som oftest skubbes ind imellem). Jeg vil snakke med den chauffør, som kører lastbilen, eller den sygeplejeske, som står i medicinrummet, for det er der, at man kommer til at forstå de små ting med den store betydning: knappen, som er for lille eller har en uheldig farve, for eksempel. Og det er sjældent dumme folk, som laver udvikling (selvom vi af og til gør dumme ting i uvidenhed), så der vil helt naturligt ske det, at løsningerne fremover mere og mere vil være noget, som også fungerer i praksis.
Vedr. dine betragtninger om livscyklussen, så kan jeg kravle helt op i det teorestiske tårn og svare, at det kun sker fordi, at du "leger" iterativ udvikling i det, som reelt er et vandfalds-setup. Men det er jo der, hvor vi som oftest i praksis befinder os, og så kan jeg kun bifalde, at man er almindelig snusfornuftig i sin gøren og laden.
Jeg er enig i at det man virkelig kan drage nytte af at samle udviklings delen og brugerdelen til evaluerering af det produkt man arbejder på undervejs i projektet. Spørgsmålet er bare om det helt kan holde til at man afholder det ved hver eneste sprint. Dette er dels fordi det nu er en større flok der skal samles, dels fordi der skal et vist volumen af ny funktionalitet til for det giver mening at indkald flere af systemets daglige bruger til mødet. Så demomøde er helt sikkert en god ting, men forsøg på at passe den ned i sprint kasserne er måske mindre godt.
Mht. spørgsmålet om man med en 'rigtig' interativ proces undgår at have mere analyse og forberedelse i starten og mere tid på fejlrettelser i slutningen har jeg det lidt på samme måde som med kommunismen, i teorien virker det bare fantastisk, problemet er bare at alle forsøg på at implementere det i virkeligheden har fejlet. Når man står i sådan en situation hvor alle eksperimentelle data går imod teorien, bør man tilpasse eller udvide teorien (eller forkaste den), så den undstøtter den virkelighed man observere.
Forøvrigt mener jeg absolut man skal afholde en demostration af de resultater man har opnået i den sidste iteration. Man skal bare som altid (specielt i SCRUM's lettere forsimplede verden), være opmærksom på alle de kræfter der er relevante for en given aktivitet/proces, fremfor bare at konstatere at det var da ikke så godt det fejlede igen, igen, vi går det bedre næste gang. Det er meget bedre at planlægge med at samme problem opstår næste gang og tilpasse sine arbejdsgange efter det. Forbedringer er altid lettere i forhold til problemer man forstår og har vist man kan håndtere. Vi kender det fra test-first princippet, lad være med at forsøge at rette det du tror er fejlen, men sørg for at lave en test der reproducere fejlen inden. Dette viser dels at du har forstået årsagen til problemet, og efter rettelsen er lavet kan du se at du har rettet det rigtig (fuldstændige samme situation, ikke ;-).
Jeg undrer mig også såre over, hvorfor man dog ikke snart lærer af erfaringerne - men det er måske meget menneskeligt gerne at ville vide præcist, hvad man får ... men hvad er det værd, at få det, som man oprindelige bad om, når man i mellemtiden er blevet klogere, og nu ved, at man i virkeligheden skulle have bedt om noget helt andet.
Og ja, det giver væsentligt mindre planlægning at beslutte sig for at følge vejskiltene efterhånden som man kommer frem, i stedet for at måle hele strækningen ud til mindste detajle - og det giver faktisk også større tillid til, at man er kommet godt frem, så verifikationen bliver også mindre. Men den største fordel er dog nok, at man meget nemmere kan ombestemme sig undervejs.
Det betyder så til gengæld ikke, at man bare skal tage afsted med hovedet under armen - man finder selvfølgelig nogle milepæle undervejs, og noterer sig, hvor man regner med at møde kritiske punkter, hvor man skal have øget opmærksomhed.
Send en kommentar