I min tidigare artikel startade jag diskussionen kring dåligt utvecklade vanor inom ett scrum-team som så småningom kommer att leda (förr eller senare) till ett misslyckande i leveransen. I den här artikeln skulle jag vilja utöka detta ämne ytterligare en gång och fokusera nu på funktionella processer inom teamet.
De är lika viktiga som lagets tekniska spetskompetens. Även om människorna inuti är superskickliga för jobbet de ska leverera, finns det fortfarande områden som kan förstöra deras ansträngning för perfektion. Och det kommer inte att vara så mycket deras fel eftersom det kommer att vara det direkta ansvaret för projektledningsbesluten och deras förmåga att betjäna teamet med lämpliga processer för att stödja teamet med tydliga avsikter och förutsägbara aktiviteter.
Innehållsförteckning
Mycket segregerat team med distinkta färdigheter
Föreställ dig att teamet har skickliga utvecklare, helt oberoende och med förmågan att hålla vad de lovar och leverera det överenskomna sprintinnehållet lagom innan sprinten är slut. Även i ett sådant perfekt scenario (vilket är högst osannolikt ändå) kommer teamet att ha problem med att hänga med i (ständigt växande) eftersläpningsfunktioner om kompetenserna är strikt åtskilda mellan teammedlemmarna.
Några exempel
- Teamet har 1 eller 2 DevOps-ingenjörer som kan göra ändringar i de automatiserade pipelines eller ta hand om tjänsterna inne på plattformen, men resten av teamet har ingen aning om sådana saker. Att sedan diskutera dessa berättelser om scrum-ceremonier som förbättringar kommer att leda till slöseri med tid för majoriteten av teamet genom att hänga på mötet utan något deltagande och vice versa – DevOps-utvecklaren kommer inte att ha något intresse av resten av de funktionalitetsorienterade berättelserna, och tiden på mötet kommer också att vara bortkastade.
- Det finns en enda databasexpert för hela teamet. Beroende på komplexiteten och användningen av datalösningarna i systemet som teamet utvecklar, kan denna person ständigt överbelastas med berättelser som de inte har någon chans att slutföra tillräckligt snabbt, särskilt när man tar hänsyn till sina prioriteringar. Ännu värre, andra berättelser måste också vänta, eftersom de är beroende av datakällan som tillhandahålls av databasberättelserna.
- När en viss produkt mestadels är inriktad på backend-utveckling är den enda frontend-utvecklaren där för säkerhets skull (eftersom då och då behövs en liten förändring även i UI-applikationen ändå). I så fall, återigen, är de flesta scrum-ceremonierna ett slöseri med tid för den här teammedlemmen, eftersom deras kunskap endast är begränsad till frontend, och inget annat spelar roll.
Var den avslutas
I något av ovanstående fall blir resultatet att människor antingen slösar bort sin tid eller alternativt kan de inte hinna med efterfrågan på eftersläpning. De blockerar resten av teamet från att börja arbeta med nästa berättelser, eller så minskar de effektivt scrum-teamets totala effektivitet eftersom det finns för mycket tid som inte används inom sprinten.
Teamet har dock fortfarande det här antalet utvecklare. Från utsidan är det inte synligt (ens att de inte vill bli avslöjade) att personerna i teamet inte kan ta på sig vissa historier bara för att de är för inriktade på någon specifik kompetens. Så de kan inte hjälpa de andra teammedlemmarna med berättelserna, även om deras kapacitet skulle tillåta det, och prioriteringarna för berättelser skulle gynna det också.
Det är till och med svårt för produktägaren att komponera något meningsfullt sprintinnehåll för teamet, eftersom produktägaren alltid måste ta i åtanke hur många personer som kan arbeta med varje enskild berättelse och om fler liknande berättelser tas till sprinten samtidigt , i slutändan är teamets kapacitet översvämmad, även om det faktiskt finns människor som möjligen skulle kunna arbeta med dessa berättelser, men de har inte kompetensen att börja med dem.
Att lösa dilemmat
Det är ett dilemma som ska lösas och projektledare ska vara medvetna om vilken väg de ska välja. Närmare bestämt ett val mellan:
- Att ha många full-stack-utvecklare som kan arbeta med bredare innehåll, men inte riktigt experter på många ämnen. Så de kan gå brett men inte djupt. Då kan leveransen gå snabbt, men kvaliteten kan bli lidande.
- Att ha dedikerade experter för varje teknik, men sedan acceptera begränsningen och arbeta hårdare med bättre anpassat tryckt innehåll. Då kan folk gå på djupet och bygga fantastiska berättelser, men berättelserna kommer att behöva närma sig sekventiellt, vilket tar längre tid att leverera.
Svag produktägare
Den här är inte nödvändigtvis en ”processfråga” per definition, men jag behandlar det så bara för att skapandet av solida berättelser kan förstås som en process som teamet borde vilja ha stensäkert och kompatibelt med utvecklingsteamet.
Vad jag menar med svag behöver inte hänvisa till kunskapsegenskapen hos en person utan snarare till produktägarens förmåga att servera teamberättelser som utvecklare kan förstå och som är tydliga ur produktens färdplansperspektiv. Båda dessa är mycket viktiga för ett framgångsrikt scrum-team.
Om berättelserna saknar detaljer för att utvecklare tydligt ska kunna förstå syftet, funktionsvärdet eller tekniska förväntningar, kan i princip två scenarier inträffa:
- Utvecklare kommer att bygga något annat än vad produktägaren faktiskt ville ha. Det är till och med svårt att fånga under själva sprinten eftersom produktägaren oftast inte har haft förmågan att spåra berättelsernas framsteg på en så detaljerad nivå, och för det mesta förväntar PO bara att det kommer att hända (magiskt).
- Utvecklare kommer att lägga alldeles för mycket tid på att förtydliga berättelserna och diskutera dem om och om igen istället för att börja bygga dem. Detta innebär många ytterligare samtal, upprepade överenskommelser och att skjuta upp arbetet till den sena sprintfasen. Det når en punkt där de ursprungliga uppskattningarna för berättelserna inte längre kan anses vara korrekta, och berättelserna är inte möjliga att stänga inom sprinten och rullar in i nästa spurter. I värsta fall upprepas situationen sedan i de efterföljande spurterna.
Tid för självreflektion
Det är vanligtvis svårt att erkänna, men produktägaren bör hitta tid att reflektera, titta på de berättelser om eftersläpning som skapats och så småningom jämföra det med produktplanens vision om det fortfarande finns någon vettig koppling mellan dessa två – om det finns någon färdplan alls. Om inte är det det första att lösa. Ibland är lösningen att erkänna att produktägaren är för långt från laget och för långt från det egna målet.
I ett sådant fall ska produktägardelen av teamet lösas. Om inte annat, att ta in en solid affärsanalytiker som är mer orienterad mot teamets innehåll snarare än affärsinnehåll (för det har vi redan en produktägare i det här fallet) kan vara ett giltigt alternativ att gå efter, även för priset av ökade totala kostnader för laget.
Testa processer utan fast tidslinje
Vad händer om testaktiviteterna inte är snäva till ett konkret schema i en scrumsprint?
Vid första anblicken kan det här se ut som något bra vi vill ha för ett agilt/scrum-team. Flexibilitet är alltid välkommet och låter bra när det presenteras utanför.
Min erfarenhet visar att resultatet av denna frihet är mer kaos än flexibilitet. Det betyder inte att lösningen på detta ska vara att skapa ”vattenfall i sprint” med dedikerade testfaser som följs precis efter att utvecklingen är klar. Detta är inte på något sätt rätt tillvägagångssätt i det här fallet. Du kan läsa mer om detta i mina inlägg om scrumteststrategi och agila testlivscykel.
Vi kan fortfarande tillåta viss flexibilitet och välja testschemat eftersom det ser mest lämpligt ut för det nuvarande utvecklingsteamet och de givna produktegenskaper som teamet levererar. Det finns dock två huvudmål som bör uppnås med detta val:
Om dessa villkor kommer att uppfyllas kommer teamet naturligtvis att anpassa sig till anpassningsprocessen, och leveransschemat kommer inte att påverkas av oplanerade långvariga testaktiviteter.
I slutändan är det som betyder mest pålitlig och förutsägbar sprintrelease, vilket leder mig till den sista punkten i den här bloggen.
Odefinierad releaseprocess
Nu är detta en så självklar sak för varje scrum-lag. Men märkligt nog är det också vanligtvis en av de mest underskattade processerna.
Mycket ofta säger ett scrum-team bara att släppet kommer att ske efter varje sprint, men det backas inte upp av en stabil process. Vad som händer då, i verkligheten, är en massa kaotiska, oförutsägbara aktiviteter som kommer att uppstå under släpptiden. Plötsligt är alla människor upptagna med ”släppuppgifter”, och ingen kan fokusera på att fortsätta utveckla nya sprintberättelser. Sprint-mätvärden är avstängda och release ser ut som slumpmässig, oförutsägbar aktivitet från tredje persons (vanligtvis klientens) synvinkel.
Människor är så fokuserade på eftersläpningen, sprintinnehåll, utveckling, testning och slutligen att visa upp resultaten att de glömmer att när de väl är klara med allt detta så är nästa sprint redan på gång, och de tappar redan tid.
Letar efter ett bra tillfälle att släppa
Så när exakt ska teamet göra själva releasen till produktion? Det enda viktiga som betyder något i slutet.
Svaret på den frågan sitter i processen, förutsatt att du har en. Beroende på:
- komplexiteten i innehållet som laget producerar i spurterna,
- varaktigheten av en sprint,
- antal berörda komponenter i systemet
- antalet personer som använder och begär ändringarna,
en upprepad frisättningsprocess bör upprättas och följas framöver. De exakta reglerna för processen kan återigen vara flexibla att definiera. Men som det är med testaktiviteter, gör det till en stensäker vana som är förutsägbar och schemalagd för konkreta dagar i framtiden, vilket gör det till något att lita på och referera till.
Val att välja
De möjliga formerna för en sådan process kan vara någon av följande eller andra:
- Slutför testningen av funktionerna från den aktuella sprinten under följande sprint och släpp innehållet i slutet av sprinten (när testet är klart). Detta innebär att varje utgåva inte kommer att ha något innehåll från den allra sista spurten, men den kommer att innehålla berättelser från de två föregångarna.
- Den sista spurten före release är alltid dedikerad till att testa innehållet från de två föregående spurterna.
- Detta betyder inte att utvecklingen under ”testsprinten” kommer att stoppas; det står bara att innehållet som utvecklats i den testsprinten inte kommer att inkluderas i nästa release ännu.
- Om det redan finns tillräckligt med automatiserade testaktiviteter, sträva efter att göra releasen efter slutet av varje sprint. Då måste detta vara en mycket strikt process med engagerade människor som fokuserar på de där få dagarna till 100%. Det ska ändå inte påverka resten av utvecklingsteamet på något sätt.
- Du kan också välja att släppa en gång per månad eller en gång per N månader, främst om det är bra ur slutanvändarnas perspektiv. Detta kommer att öka ansträngningen på testsidan för varje sprint (eftersom innehållet blir större för varje release). Men å andra sidan kommer det att innebära mindre mängd upprepade aktiviteter över tiden, vilket i det här fallet kan ha fördelar för laget. Som ett resultat kan det göra det möjligt för teamet att bygga fler nya funktioner mellan utgåvorna, trots att funktionerna faktiskt kommer till produktion med en långsammare kadens.
Men som redan nämnts några gånger tidigare är det inte så viktigt vilken av dessa processer som kommer att väljas. Det är mycket viktigare hur bra laget sedan kommer att hålla fast vid den processen och kommer att göra det till en slitstark vana.
Du kan också läsa den här guiden till processen och praxis för releasehantering.