I en tidigare artikel initierade jag diskussionen kring undermåliga vanor inom ett scrumteam, vilka oundvikligen leder till misslyckanden i leveransen. I den här artikeln vill jag vidareutveckla ämnet och fokusera på de funktionella processerna inom teamet.
Dessa processer är lika viktiga som teamets tekniska expertis. Även om teamet består av mycket kompetenta individer kan det finnas faktorer som underminerar deras strävan efter perfektion. Det är sällan individernas fel, utan snarare ett direkt resultat av projektledningens beslut och deras förmåga att skapa lämpliga processer som ger teamet tydliga mål och förutsägbara aktiviteter.
Ett starkt uppdelat team med specifika kompetenser
Tänk dig ett team med skickliga utvecklare som är oberoende och levererar det överenskomna sprintinnehållet i tid. Även i detta idealiska scenario (vilket är ovanligt) kommer teamet att ha svårt att hantera en växande backlog om kompetenserna är alltför åtskilda.
Exempel
- Teamet har en eller två DevOps-ingenjörer som kan göra ändringar i de automatiserade pipelines eller hantera plattformstjänsterna. Resterande team saknar kunskap inom dessa områden. Diskussioner om dessa ämnen under scrum-ceremonier blir ineffektiva, eftersom majoriteten inte kan delta aktivt, medan DevOps-utvecklaren inte är intresserad av de funktionsorienterade ärendena.
- Det finns en enda databasexpert för hela teamet. Beroende på systemets komplexitet och användningen av datalösningar kan denna person överbelastas med ärenden som de inte kan slutföra i tid. Detta leder till att andra ärenden försenas, eftersom de är beroende av databasexperten.
- Om en produkt huvudsakligen fokuserar på backend-utveckling, kan en ensam frontend-utvecklare finnas med ”för säkerhets skull”, eftersom mindre UI-ändringar kan behövas ibland. I det fallet blir de flesta scrum-ceremonier ineffektiva för den här personen, eftersom deras expertis är begränsad till frontend.
Slutsats
I dessa fall leder det till att medlemmar slösar bort sin tid, eller inte hinner med efterfrågan. De blockerar resten av teamet från att påbörja nästa uppgifter, eller minskar teamets totala effektivitet på grund av ineffektiv användning av sprinttiden.
Teamet har fortfarande samma antal utvecklare. Det är inte uppenbart (eller så döljs det) att teammedlemmarna inte kan ta på sig vissa uppgifter på grund av specialiserade kompetenser. De kan inte bistå andra medlemmar, trots att kapaciteten och prioriteringarna tillåter det.
Det blir svårt för produktägaren att skapa meningsfullt sprintinnehåll, eftersom de måste beakta hur många som kan arbeta med varje ärende. Om för många liknande ärenden tas med, blir teamets kapacitet översvämmad, även om det finns medlemmar som potentiellt skulle kunna hantera dem, men saknar kompetens.
Lösningen
Detta är ett dilemma som projektledare måste hantera, med valet mellan:
- Att ha många fullstack-utvecklare som kan arbeta med ett brett utbud av uppgifter, men inte är experter på något. Leveransen går snabbt, men kvaliteten riskerar att påverkas.
- Att ha specialiserade experter för varje teknik, vilket medför begränsningar och kräver bättre anpassning av innehållet. Man kan gå djupare och skapa fantastiska uppgifter, men hanteringen blir sekventiell och tar längre tid.
Svag produktägare
Detta är inte nödvändigtvis en processfråga, men jag tar upp det här eftersom skapandet av solida ärenden är en process som teamet bör sträva efter att ha välfungerande och kompatibelt med utvecklingsteamet.
Med svag menar jag inte nödvändigtvis kunskapsnivån, utan produktägarens förmåga att leverera ärenden som utvecklarna förstår och som är tydliga i produktens färdplansperspektiv. Båda dessa aspekter är viktiga för ett framgångsrikt scrumteam.
Om ärendena saknar detaljer för att utvecklare tydligt ska förstå syfte, funktionsvärde eller tekniska förväntningar, kan två scenarier uppstå:
- Utvecklarna bygger något annat än vad produktägaren avsåg. Detta är svårt att upptäcka under sprinten, eftersom produktägaren ofta inte följer upp framstegen i detalj och bara förväntar sig att det ska hända (magiskt).
- Utvecklarna lägger alltför mycket tid på att förtydliga ärendena istället för att börja bygga. Det leder till många extra diskussioner, upprepade överenskommelser och att arbetet skjuts upp till sprintens slutskede. Uppskattningarna blir felaktiga, och ärendena kan inte slutföras under sprinten och flyttas till nästa. I värsta fall upprepas situationen i efterföljande sprinter.
Dags för självreflektion
Det är svårt att erkänna, men produktägaren bör reflektera över skapade ärenden och jämföra dem med produktplanen för att se om det finns en vettig koppling. Om inte, är det första problemet som behöver lösas. Ibland kan lösningen vara att erkänna att produktägaren är för långt ifrån teamet och målet.
I så fall bör produktägarrollen i teamet ses över. Att ta in en affärsanalytiker som är mer orienterad mot teamets innehåll än affärsinnehåll (vilket produktägaren hanterar) kan vara ett alternativ, även om det ökar teamets totala kostnader.
Testprocesser utan fast tidsram
Vad händer om testaktiviteterna inte har en fastställd tidsplan i en scrum-sprint?
Vid första anblicken kan det verka bra för ett agilt/scrum-team. Flexibilitet är eftertraktat och låter bra utåt sett.
Min erfarenhet visar att resultatet av denna frihet är mer kaos än flexibilitet. Lösningen är inte att skapa ”vattenfall i sprint” med dedikerade testfaser direkt efter utvecklingen. Det är inte rätt tillvägagångssätt. Du kan läsa mer om detta i mina inlägg om scrumteststrategi och agila testlivscykel.
Vi kan fortfarande tillåta viss flexibilitet och anpassa testplanen efter utvecklingsteamets och produkternas behov. Det finns två huvudmål som bör uppnås:
- Minimera störningar i utvecklingsframstegen under testaktiviteterna.
- Skapa en solid (innehållsmässigt), pålitlig (händelsemässigt) och repeterbar (förutsägbart) aktivitet inom teamet.
Om dessa villkor uppfylls kommer teamet att anpassa sig till processen, och leveransschemat påverkas inte av oplanerade testaktiviteter.
I slutändan är det viktigaste en pålitlig och förutsägbar sprintrelease, vilket leder mig till den sista punkten.
Odefinierad releaseprocess
Detta är en självklarhet för alla scrumteam, men märkligt nog är det också en av de mest underskattade processerna.
Ofta säger ett scrumteam att releasen sker efter varje sprint, men det backas inte upp av en stabil process. I verkligheten uppstår kaotiska och oförutsägbara aktiviteter under releasetiden. Plötsligt är alla upptagna med ”releaseuppgifter” och ingen kan fokusera på utvecklingen av nya sprintärenden. Sprintmåtten sätts ur spel, och releasen uppfattas som slumpmässig och oförutsägbar utifrån sett.
Människor är så fokuserade på backlogen, sprintinnehåll, utveckling, testning och resultatpresentation att de glömmer att nästa sprint redan är på gång när de väl är klara. De förlorar tid.
När är det rätt tid för release?
Så när ska teamet göra releasen till produktion? Det är det viktigaste i slutändan.
Svaret finns i processen, förutsatt att det finns en. Beroende på:
- Komplexiteten i sprintinnehållet.
- Sprintens varaktighet.
- Antalet inblandade systemkomponenter.
- Antalet användare och deras önskemål om förändringar.
En repeterbar releaseprocess bör upprättas och följas. De exakta reglerna kan vara flexibla. Men precis som med testaktiviteter, gör det till en förutsägbar rutin som är planerad för specifika dagar, vilket ger teamet något att lita på.
Valmöjligheter
Möjliga former för en sådan process kan vara:
- Slutför testningen av funktionerna från den aktuella sprinten under nästa sprint och släpp innehållet i slutet av sprinten (när testet är klart). Då kommer varje release inte att innehålla något från den sista sprinten, utan från de två föregående.
- Den sista sprinten före release är alltid dedikerad till att testa innehållet från de två föregående.
- Detta betyder inte att utvecklingen under ”testsprinten” avstannar. Utan innehållet som utvecklas i den testsprinten kommer inte att inkluderas i nästa release.
- Om det finns tillräckligt med automatiserade tester, sträva efter att göra releasen i slutet av varje sprint. Det måste i så fall vara en strikt process med engagerade personer som fokuserar på de dagarna. Det ska inte påverka det övriga utvecklingsteamet.
- Du kan också välja att släppa en gång i månaden eller var N:e månad, om det är bra utifrån användarens perspektiv. Det kommer att öka testinsatsen för varje sprint (eftersom innehållet blir större för varje release). Men det kommer också att innebära färre repetitiva aktiviteter, vilket kan vara en fördel för teamet. Det kan också ge teamet möjlighet att utveckla fler nya funktioner mellan utgåvorna, trots att de faktiskt når produktion i en långsammare takt.
Men som jag sagt tidigare, det är inte så viktigt vilken process som väljs. Det är viktigare att teamet följer den valda processen och gör den till en vana.
Du kan också läsa den här guiden till processen och praxis för releasehantering.