Utmaningar vid övergång till agila metoder i mjukvaruutveckling
När företag övergår från traditionella lokala mjukvarulösningar till molnbaserade alternativ, är ett vanligt mål att uppnå ökad ”agilitet”. Denna ambition bör omfatta hela organisationen, och det är ofta en önskan att se snabba och omfattande förändringar.
I teorin kan processerna tyckas enkla att transformera. Det är möjligt att implementera scrum-ceremonier och omfördela personal till nya roller som scrum-master, produktägare och scrum-teammedlemmar.
Man kan även införa verktyg som Jira, Azure ADO och Miro-tavlor och göra dem obligatoriska att använda. Men vad händer med de processer som länkar samman dessa verktyg? Och hur förändrar man människors tankesätt, beteenden och arbetsmetoder? Det blir snabbt uppenbart att en sådan transformation inte sker smidigt eller över en natt. Låt oss undersöka varför.
Vad innebär en transformation till agil leverans och varför genomförs den?
Många företag använder fortfarande vattenfallsmodellen för leverans. Denna metod innebär följande steg:
- Inledande planering av önskat slutresultat/produkt och uppskattning av kostnader.
- Detaljerad kravinsamling, där alla aspekter av slutprodukten diskuteras, ifrågasätts och slutligen godkänns.
- Kostnadsuppskattning och godkännande av budget.
- Design av lösningen, inklusive möten med intressenter, dokumentation och godkännande av teknisk design.
- Implementering av lösningen baserad på designen, vilket inkluderar utveckling av den färdiga produkten.
- Testfas med olika typer av tester: enhets-, system-, funktions-, integrations-, prestanda-, regressions- och acceptanstester. Allt dokumenteras för granskning och godkännande av intressenter.
- Distribution av lösningen till produktionsmiljön, där användarna börjar använda den färdiga produkten.
- Supportfas för att åtgärda eventuella fel.
Denna process kan ta månader eller till och med år, och slutanvändarna får inte se resultatet förrän i slutet. Om kraven ändras under processen uppstår en ändringsförfrågan, vilket kräver en omstart av design- och godkännandeprocessen.
Det är uppenbart att vattenfallsmodellen inte är smidig. Varje förändring kräver en omstart av processen.
Övergången till agila metoder
Hur kan vi då övergå till mer agila metoder? Många har arbetat med vattenfallsmodellen i åratal och är bekväma med sina roller och ansvar. Den största utmaningen är ofta motståndet mot förändring, eftersom det kan upplevas som en förlust av makt.
Detta motstånd utgör en av de största hindren för en framgångsrik transformation.
#1. Omstrukturering av team
Det första steget är ofta att omstrukturera personalen till scrum-team, baserat på funktionella områden eller annan logisk uppdelning.
Själva uppdelningen kan gå smidigt, men utmaningen uppstår när individer fortfarande är bundna till de gamla strukturerna. Även om de formellt ingår i de nya scrum-teamen fortsätter de ofta att arbeta enligt det gamla systemet, med ansvar som inte avslutades i samband med omstruktureringen. Ledningen fokuserar ofta mer på vad som ska påbörjas än vad som behöver slutföras.
Resultatet blir att scrum-teamen inte är helt dedikerade. De är bara grupper av människor som fått ännu mer att göra. Det finns inte tillräckligt med tid för det arbete som förväntas inom scrum-teamen.
Samtidigt förväntas personalen slutföra sina tidigare uppgifter samtidigt som de levererar inom de nya scrum-teamen. Denna situation är dömd att misslyckas från början.
#2. Schemaläggning av Scrum-ceremonier
Att beordra teamen att schemalägga regelbundna scrum-möten (sprintceremonier) är lätt att definiera och initiera. Åtminstone om teamen inte befinner sig i flera olika tidszoner (vilket ofta är fallet).
Problemet uppstår när deltagarna inte dyker upp regelbundet. Beroende på vem som missar och hur ofta, kan det uppstå olika problem:
- Om produktägaren inte deltar i planerings- och förfiningsmötena saknar teamet nya användarberättelser att arbeta med, eller så är beskrivningarna så bristfälliga att arbetet inte kan startas.
- Om scrum-mastern inte är med saknas grundläggande scrum-ledning, och teamet kan tappa fokus.
- Om utvecklingsteamets medlemmar ofta är frånvarande kan de inte synkronisera, vilket gör kommunikationen svårare. Det kan krävas fler möten för att komma ikapp, vilket i sin tur tar tid från teamet.
Ofta beror uteblivna deltaganden inte på deltagarnas ovilja, utan på att systemet inte tillåter dem att delta (se ovan om parallella uppdrag).
#3. Teamets stabilitet
Även om ett scrum-team har struktur och ceremonier, är stabilitet över tid nödvändig för att utvecklas och förbättras. En stabilitet på minst sex månader, eller helst ett år, är önskvärd. Annars kommer teamet inte att utvecklas till ett helt självständigt scrum-team.
Detta innebär att man ständigt måste lära och utbilda nya medlemmar i scrum-tänket och processerna, vilket är utmattande.
Detta problem underskattas ofta av ledningen. Att betrakta team som ”resurser” som ”används” från kvartal till kvartal är en snabb väg till ineffektivitet.
#4. Nya roller för samma personer
En annan utmaning är att omplacera befintlig personal till nya roller. De som tidigare haft ledande positioner kan nu bli produktägare, vilket är en viktig roll men kan upplevas som svagare.
Produktägare måste samarbeta med scrum-mastern eller programansvariga. De ansvarar fortfarande för innehållet men inte längre för leveransprocesserna. Det krävs att man släpper en del av det tidigare ansvaret, vilket kan vara svårt.
#5. Arbetssätt
Ett vanligt argument är att man måste lära sig nya arbetssätt för att vara relevant på en marknad där agilitet förväntas. Men vad betyder egentligen dessa nya arbetssätt?
Ledningen vill ofta att teamen ska åstadkomma mer på kortare tid. Efter att scrum-teamen har etablerats förväntar man sig att varje medlem ska leverera mätbara resultat dagligen. Om det inte sker ifrågasätter ledningen om den agila processen fungerar.
Man förväntar sig att varje timme ska räknas och att det inte finns utrymme för ineffektivitet, bara för att scrum-processer har införts. Det är definitionen av ”nya arbetssätt” ur ett ledningsperspektiv.
Denna förväntning saknar ofta förankring i verkligheten. Det är en illusion att tro att personalen ska bli mer produktiv bara för att dagliga processer ändras. Vissa kan göra det, men de blir snabbt överbelastade med ännu fler uppgifter.
Skillnaden mellan mål och verklighet
Beskrivningen av det slutliga målet är ofta bra och logisk. Den kretsar kring följande principer:
- Stabila scrum-team som arbetar med oberoende backloggar och tydliga KPI:er och OKR:er.
- Produktägare som bygger solida färdplaner och prioriterar innehåll.
- Detaljerat backlog-innehåll innan arbetet påbörjas.
- Tillförlitliga testprocesser som utförs parallellt med sprintutvecklingen.
- Regelbundna leveranser till produktion, minst en gång i månaden eller helst efter varje sprint.
- Spårning och kommunikation av risker och problem mellan scrum-teamen vid beroenden.
I verkligheten är dock inget av detta lätt att uppnå.
- Scrum-teamen bildas men förändras ständigt. Man investerar i att lära teamet scrum-processerna, men när de börjar anpassa sig omorganiseras teamen. Färdplaner ändras, flyttas eller avbryts.
- Produktägare har inte koll på detaljerna i färdplanen och delegerar (av gammal vana) att bygga backlog-innehållet direkt till teamet. Detta gör att teamet inte har tid att utveckla innehållet eftersom de först måste ta reda på vad som ska utvecklas.
- Testprocesserna är manuella, kräver många steg och godkännanden, vilket gör att testningen inte kan slutföras under samma sprint som utvecklingen.
- Leveranser till produktion släpar efter flera sprintar.
- Kommunikationen mellan teamen är kaotisk och ineffektiv, eftersom varje team har för mycket att göra varje sprint. Produktägarna ger ofta teamen för mycket innehåll, vilket gör att de ständigt jobbar under stress.
Rättelse av fel
Baserat på erfarenheter från agila transformationsprojekt följer en sammanfattning av de vanligaste misstagen och förslag på hur de kan övervinnas.
#1. Rätt ansvar för rätt roller
Om man försöker förvränga rollerna och ansvaret i scrum/agile riskerar man hela projektet.
- Produktägaren ska ansvara för innehållet och underhålla backloggen. De ansvarar för användarberättelserna. Om dessa inte är väldefinierade är det upp till dem att åtgärda. De ska inte ha inflytande på bemanningen eller projektbudgeten.
- Scrum-mastern ansvarar inte för backlog-innehållet. De leder ceremonierna och utbildar teamet i agila arbetssätt. De ska inte vara sekreterare åt produktägaren, utan skydda teamet mot produktägaren och externa intressenter.
- Varje scrum-team ska ha en leveransansvarig som länkar samman PO, SM och utvecklingsteamet, definierar leveransprocesser och löser risker och konflikter. Leveransansvarig är rätt person att hantera bemanning och budgetfrågor och ska skapa en miljö där alla kan prestera på sitt bästa.
- Utvecklingsteamets ansvar är att utveckla berättelserna från backloggen. De kan hjälpa PO med att bygga innehåll för tekniska berättelser, men de är inte ansvariga för berättelser som bygger upp färdplanens innehåll.
#2. Stabilt team
Agil utbildning av teamet är viktigt och måste ske snabbt. Att låta kunskapen gå förlorad med några månaders mellanrum är ineffektivt.
Använd de första fem sprinterna som en inlärningsperiod. När alla känner sig trygga kan den kontinuerliga förbättringen starta. Om personalen byts ut regelbundet uppstår en ständig loop av kunskapsöverföring och utbildning.
Teamet kommer sannolikt aldrig att nå sin fulla potential, och ledningen kommer att undra varför effektiviteten verkar sämre än innan den agila transformationen.
Bygg teamet, dela med er av kunskap och behåll teamet intakt. Därifrån kan en kontinuerlig resa mot förbättring börja.
#3. RACI-matris
Det är en bra idé att skapa och enas om en RACI-matris (Ansvarig, Ansvarig, Rådgjord, Informerad) mellan alla team innan arbetet startar. Det kan minska förvirring.
Detta är extra viktigt i början av transformationen. Annars kommer frågor om vem som ska göra vad att uppstå, speciellt i situationer som inte kommunicerats tydligt.
Här är ett exempel på en RACI-matris. Din kan vara annorlunda, men det viktiga är att fånga relevanta ansvarsområden.
Uppgift | Requestor | Leverans Lead | Product Owner | Scrum Master | Dev Team |
Sprint Planeringssessioner | C/I | A/I | R | C/I | I |
Leverera Release Increment | N/A | I | A/I | C/I | R |
Sprint Review | C/I | I | R | I | C |
Sprint Retrospective | I | I | A/I | R | C/I |
Förfina Backlog | I | A/I | R | C/I | I |
Slutsats
Det finns mycket mer att skriva om eftersom en agil transformation kan gå snett på många sätt. Syftet här har varit att lyfta fram några av de vanligaste misstagen.
En agil transformation är en bra idé, men den kan snabbt bli en mardröm om man inte följer några grundläggande regler. Jag har nämnt några, men sunt förnuft räcker långt. 🙂
Kolla sedan in bra lärresurser för Agile-certifiering.