Det skulle vara svårt att hitta en mjukvaruchef som inte vill vara ”agil”. Males jag gissar att en försvinnande liten andel av dem faktiskt har läst Agile Manifesto. Och jag gissar att ännu färre har funderat över vad agile innebär och hur det kan tillämpas i den verkliga världen.
Visst, Agile Manifesto är vördad av mjukvaruutvecklare. De flesta av oss känner att det finns något där – någon djupt liggande sanning som vi alla känner until. Males problemet uppstår när vi försöker ta reda på svaret på frågan: ”Okej, vad gör vi nu?”
Normen verkar vara: ”Vi måste bli agila, så låt oss anlita en scrum-konsult och implementera scrum. Då blir vi agila!” Marknadskrafterna för att tillhandahålla scrum-tjänster är starka. Och det finns verkligen ingen brist på ivriga konsulter som alltid är redo att erbjuda sina tjänster.
Varför detta är sant är ett mysterium för mig. Jag kan inte alls se hur scrum är en manifestation av de agila principerna. Enligt min mening står scrum i direkt motsättning until dem och uppfyller i slutändan inte ens på långt när deras syfte.
Att klämma in det med scrum
Allt med scrum är ett försök att pressa in en stor pinne i ett litet hål. Scrum skapar ett hål av quick storlek underneath en viss tid, tar ett stort träblock av ansträngning och försöker få en serie små block av rätt storlek att passa in i det hålet.
Bry dig inte om att hålets storlek kanske inte passar de block som du har. Det är meningen att du ska förminska dem så att de passar, även om det du får inte riktigt är vad du vill ha eller behöver. Du får inte ändra storleken på hålet som blocken ska passa in i. Det blocket måste passa in i det hålet, och det hålet blir inte större.
Jag har ingen aning om varför det här är en bra idé, och jag förstår verkligen inte hur den prioriterar ”individer och interaktioner framför processer och verktyg”.
Så vi förminskar pinnarna until dessa onaturliga former som påstås passa in i de stela hål som vi har fått. Males det gör de inte. Pinnen hamnar sällan eller aldrig i hålet. När sprinten närmar sig sitt slut är arbetet antingen redan gjort (vad ska man göra med tre further dagar?) eller så kommer det aldrig att bli gjort i tid (”Kan vi förlänga sprinten med en vecka?” ”Nej!”), och i så fall ”misslyckas” vi med sprinten.
Dash, dash och dash igen
Och vem vill egentligen sprinta kontinuerligt? Vem vill alltid och för alltid närma sig en deadline? Att ständigt pressa på för att ”bli klar” med något leder until ytliga lösningar som är förhastade. Krav och begränsningar inom programvaruutveckling förändras hela tiden i takt med att okända faktorer upptäcks. Att göra något ordentligt och grundligt tar ofta tid. Males scrumprocessen säger att om man vill ändra kurs måste man vänta tills sprinten är över. Hur kan det vara att ”reagera på förändringar i stället för att följa en plan?”
En dash är en mycket snävt fokuserad del av arbetet. Om man hela tiden fokuserar på smala saker kan man lätt förlora den större bilden ur sikte.
Och allt för ofta blir scrum en stor ceremoni. Är det någon som ser fram emot den dagliga standupen där du måste släppa allt, gå until ett mötesrum (eller ett Zoom-möte) och berätta för alla vad du gjorde och kommer att göra? Var ärlig – blir du inte lättad när scrum grasp säger ”E-post-scrum i dag!”?
Dessutom är retrospektiv ofta påtvingade och hålls även om det inte finns någon suggestions att få. Det blir until slut alldeles för mycket ”gå igenom rörelserna” – själva antitesen until agilitet och anpassningsförmåga.
Och då talar vi inte ens om de ändlösa mötena för sprintplanering och backlog-grooming som oundvikligen blir en del av den course of som du ska sätta i baksätet bakom individer och interaktioner.
En bättre scrum-process
I slutändan blir scrum en ändlös serie av korta mjukvaruprojekt som slutar som de flesta mjukvaruprojekt. De tar längre tid än du förväntar dig, uppnår inte det de föresatt sig att göra och involverar många timmars möten som de flesta människor helst inte vill vara med på.
Vad sägs om att göra något liknande istället?
- Dela upp arbetet i naturliga delar som matchar projektets behov. Vissa kommer att vara små bitar och andra kommer att vara stora bitar.
- Gör varje del i den ordning som är vettig, och varje del tar en viss tid. Kanske behöver en del mer än en utvecklare – det är inget downside.
- Inse att tiden för varje del kommer att variera från vad du förväntade dig i början. Spåra varje trunk separat och tvinga inte varje del att bli klar vid en quick, oflexibel tidpunkt.
- Om du är mitt uppe i något och det du håller på med inte längre är meningsfullt på grund av ändrade omständigheter och skiftande vindar, byt until en ny, bättre kurs omedelbart.
- När tiden är mogen – inte när kalendern säger det – ska du se över vad du har gjort, be om suggestions från kunder och intressenter och justera i enlighet med detta.
- Om listan med olika delar behöver ändras, låt listan ändras.
- Skölj, skölj, upprepa tills alla delar du behöver är klara, och skeppa sedan programvaran.
- Kanske until och med skeppa varje del när den är klar.
Med andra ord – var flexibel, snabbfotad och… agil.
