De största misstagen av leveranstransformation till agilt förklarade

När företagen flyttar med mjukvarulösningar från on-premise till molnet sätter de ofta upp som mål att bli mer ”agila”. Detta bör ofta gälla för allt på företagsövergripande nivå. Och naturligtvis överallt samtidigt.

Transformation av processerna skulle vara lätt möjlig, åtminstone i teorin. Du kan definiera scrum-ceremonier och omplacera personer till nya roller (som scrum-mästare, produktägare, leveranschefer och scrum-team).

Du kan ta med verktyg som Jira, Azure ADO och Miro-kort och göra dem obligatoriska att använda. Men hur är det med processerna som kopplar ihop verktygen? Vad sägs om att förändra människors sinnen, beteenden och sätt att arbeta? Det blir tydligt att de inte kommer att förvandlas smidigt och inte heller kommer de att sluta snabbt. Låt oss nu se varför.

Vad är ett leveranstransformationsinitiativ och varför företag gör det?

En stor del av företagen arbetar idag fortfarande enligt vattenfallsleveransmodellen. Det betyder att:

  • Planera först vad du vill göra som slutresultat/produkt och hur mycket det ungefär kan kosta.
  • Starta kravinsamlingsprocessen, där du noggrant diskuterar alla detaljer om slutprodukten, protesterade mot, ifrågasatte, kom överens om, diskuterade igen och slutligen bekräftades.
  • Uppskatta det hela och bekräfta budgetförväntningarna.
  • Designa lösningen. Genomför flera möten med intressenter. Skapa olika dokument och låt intressenter granska dem. Bekräfta och godkänn den slutliga funktionella och tekniska designen.
  • Implementera lösningen utifrån designen. Det är här du utvecklar den kompletta slutprodukten.
  • Gå in i testfasen och utför olika typer av tester: enhetstester, systemtester, funktionstester, integrationstester, prestandatester, regressionstester, användaracceptanstest och potentiellt många fler (beroende på företagets kultur). Dokumentera allt och låt intressenterna granska och godkänna det.
  • Distribuera lösningen till produktionsmiljön. Det är här målanvändarna börjar använda den slutliga och kompletta produkten.
  • Schemalägg en supportfas under vilken utvecklingsteamet korrigerar potentiella buggar i lösningen.
  • Hela denna process kan ta några månader till några år, och som du kan se kommer användarna att se resultaten först i slutet av den processen. Så efter lång väntan kommer sanningens (eller misslyckandets) ögonblick.

    Om något förändras under den långa tiden och slutprodukten skulle se lite annorlunda ut, är det en situation som kallas en förändringsförfrågan. Designen måste öppnas igen, omarbetas och godkännas på nytt. Det förlänger hela tidsschemat med ytterligare en del.

    Det är klart att detta inte är smidigt på något sätt. Varje förändring kräver en omstart av hela processen innan.

    Byter till Agile

    Så, hur tar vi oss ur den här situationen och ändrar den för att bli smidig? Människorna arbetar i vattenfallet i många år eller till och med århundraden. De har roller och ansvar som de är bekväma med, och de vill inte ändra status quo. Den främsta anledningen till det är att att göra denna förändring i slutändan innebär att förlora en del av den makt de hade fram till nu.

    Detta är huvudorsaken till att en sådan förändring extraherar den starkaste nivån av motstånd från människorna som du kan skapa.

    #1. Team omstrukturera

    Det första och relativt enklaste att göra är att omstrukturera folket till scrum-team. Dela upp dem baserat på de funktionella områdena eller någon annan logisk uppdelning som är vettig.

    Klyvningen går oftast smidigt; problemet börjar när man inser att människor fortfarande är bundna till de ursprungliga strukturerna. Även om de redan är en del av de nya scrum-teamen är de praktiskt taget inte det. De jobbar fortfarande med det gamla upplägget eftersom de fortfarande har ansvar som inte avslutades tillsammans med teamomstruktureringsprocessen (för varför skulle det vara det – ledarskapet bryr sig inte så mycket om vad som behöver göras klart, utan mest om vad som måste påbörjas).

    Så praktiskt taget slutar du med ett scrum-team som inte är helt dedikerat scrum-team. Det är en grupp människor som nu helt enkelt har mer att göra. Det finns inte så mycket tid för arbetet inom scrum-teamet som ledningen förväntar sig.

    Samtidigt är förväntningen att folket ska avsluta sina ursprungliga aktiviteter såväl som denna nya förväntning inom scrum-teamen. Det är en inställning som är fast besluten att misslyckas direkt i början.

    #2. Schemaläggning av Scrum-ceremonier

    Att beordra teamen att schemalägga flera vanliga samtal (sprintceremonier) är lätt att definiera och starta. Åtminstone, förutsatt att dina scrum-team inte består av personer från 3+ tidszoner (vilket ofta är fallet).

    Problemet börjar när folket inte kommer att delta i ceremonierna regelbundet. Beroende på vem som saknas och hur ofta kan detta utvecklas till olika typer av problem. Till exempel:

    • Om produktägare inte deltar i planerings- och förädlingsceremonierna har teamet inga nya berättelser att arbeta med. Eller så är beskrivningen av berättelserna så dålig att resten av teamet inte kan börja arbeta med dem.
    • Om scrum masters saknas på callen, saknar teamet grundläggande scrum-orkestrering och kan gå vilse med tiden så småningom.
    • Om teammedlemmarna i utvecklingsteamet ofta saknas kan de inte synkronisera med varandra, och kommunikationen inom teamet är mycket svårare. Det krävs också fler möten för att hinna med, vilket tar ut ännu en tid från laget.

    I slutändan är det inte nödvändigtvis folks fel att de missar ceremonierna. Det är bara upplägget som inte tillåter dem att delta i samtalen (se ovan om parallella tidigare uppdrag).

    #3. Lagets stabilitet

    Du kanske har ett scrum-team med struktur och ceremonier, men om det laget inte är stabilt över en längre tidsperiod – låt oss säga minst ett halvår idealiskt, ett år av stabilitet skulle vara mitt personliga minimikrav – så kan ett sådant team inte riktigt utvecklas och förbättras.

    Därefter kommer du förmodligen aldrig att nå ett helt oberoende scrum-team som hanterar spurterna som vanligt. Slutligen måste du ständigt utbilda och lära människor i teamet för att förstå scrum-tänkesättet och processerna. Det är ett utmattande problem att ha.

    Detta är ett mycket underskattat problem, särskilt av företagets ledning eller ledning. Att kalla teamen av människor bara för ”resurser” och planera deras ”användning” från kvartal till kvartal är en omedelbar väg till helvetet.

    #4. Nya roller för samma personer

    Ett annat hinder att övervinna är att omplacera befintliga personer till olika nya roller. De som tidigare ledde team med ultimat makt kan nu bli produktägare, till exempel. Detta är en stark position i ett scrum-lag, men det kan ses som en svagare roll i förhållande till det befintliga setupet.

    Plötsligt måste produktägarna synkronisera med scrummastern eller programansvariga. De är fortfarande ansvariga för innehållet men inte så mycket för leveransprocesserna. Denna situation kräver att man avstår från vissa ansvarsområden som människorna tidigare hade och är därför svåra att svälja.

    #5. Arbetssätt

    Den här är intressant, och jag hör den då och då ganska ofta – vi behöver lära oss nya sätt att arbeta för att bli relevanta på den växande marknaden där smidighet är grundförväntningen. Men vad betyder det egentligen de sätten att arbeta på?

    Frågar du mig är det tydligt vad ledningen menar med det – att uppnå (mycket) mer på kortare tid. Efter att ha satt upp scrum-teamen är förväntningen att varje teammedlem plötsligt kommer att uppnå några dokumenterade inkrementella resultat från dag till dag. Om så inte är fallet kommer ledarskapet att börja fråga varför den agila processen inte fungerar bra.

    Bara från ingenstans förväntar sig ledningen att varje timme ska räknas och att scrum-teamen i princip inte har någon ledig tid, bara för att det inte finns något utrymme för det kommer alla scrum-processer på plats. Och det är definitionen av ”nya arbetssätt” ur ledarskapsperspektivet i ett nötskal.

    Naturligtvis bygger denna förväntning inte på verklighetskontrollen. Det är en illusion att förvänta sig att människor i företaget ska börja arbeta mer inom samma period, bara för att vissa dagliga processer kommer att förändras. Jag menar, vissa av dem skulle kunna, även om det bara är en minoritet. Men även denna grupp reduceras ytterligare genom att belamra dem med fler uppgifter samtidigt.

    Skillnaden mellan mål och verklighet

    Det råder ingen tvekan om att beskrivningen av slutmålet ofta är bra, och det är mycket vettigt. Det går runt följande principer:

    • Stabiliserade scrum-team som arbetar med oberoende eftersläpningar med tydliga KPI:er och OKR:er.
    • Produktägare att bygga upp solida färdplaner och planera prioriterat innehåll för att leverera mot konkreta tidslinjer.
    • Definierat eftersläpningsinnehåll med relevanta funktioner redan detaljerade innan arbetet påbörjades.
    • Tillförlitliga testprocesser som utförs vid sidan av det vanliga sprintutvecklingsarbetet.
    • Regelbundna släpp till produktion – minst en gång per månad, men helst efter varje slutförd sprint.
    • Risker och problem spårning och kommunikation mellan de olika scrum-teamen vid beroenden.

    Sedan, när det kommer till verkligheten, kan jag säga att ingen av punkterna ovan är lätta att uppnå.

    • Man bildar scrum-teamen, men de förändras hela tiden (från kvartal till kvartal). Du investerar tid för att lära teamet scrumprocesserna, och när de äntligen börjar acceptera det och ändrar sitt sätt att arbeta, organiserar du om teamen för nästa period. Färdkartor ändras, flyttas eller avbryts.
    • Produktägare har ingen riktig aning om detaljerna i färdplanen, och (bara för att de hade sådana vanor tidigare) kommer de att tilldela sina uppgifter att bygga upp eftersläpningsinnehållet direkt till teamet. Som ett resultat har teamet inte tid att utveckla innehållet eftersom de först måste ta reda på vad de ska utveckla.
    • Testprocesser är endast manuella och kräver många delsteg och godkännanden och komplicerade processer att följa. Det betyder att det inte finns något sätt att testningen kan avslutas inom samma sprint som utvecklingen gör.
    • Som en konsekvens släpar release till produktion flera spurter efter.
    • Kommunikationen mellan de olika scrum-teamen är kaotisk och ineffektiv, eftersom varje lag har många aktiviteter att utföra varje sprint. Faktum är att produktägare tenderar att tilldela teamet för mycket innehåll varje sprint. Det finns ingen chans att laget kan slutföra allt, så de är ständigt under deadline-stress.

    Rätta till misstagen

    Med erfarenhet från några agila transformationsprojekt skulle jag vilja sammanfatta några av de största misstagen jag upplevt och ge några subjektiva åsikter om att eventuellt övervinna dem.

    #1. Rätt ansvar för Rätt roller

    Om du försöker böja definitionen och fördela ansvaret på något annat sätt än vad de borde vara av scrum/agile, så misslyckas du med hela initiativet.

    • Produktägare ska äga innehållet och underhålla eftersläpningen. De är ansvariga för eftersläpningshistorierna, och om eftersläpningshistorierna inte är väldefinierade är det upp till dem att vidta åtgärder och fixa det. Å andra sidan ska de inte ha något inflytande på scrum team människors uppdrag eller beslut om projektbudgeten.
    • Scrum masters ska inte ha något ansvar för eftersläpningsinnehållet. De är med i teamet för att orkestrera ceremonierna och utbilda teamet i ett agilt arbetssätt. De borde inte vara sekreterare för produktägare. Tvärtom ska de skydda utvecklingsteamet mot produktägaren och externa intressenter.
    • Varje scrum-lag ska ha tilldelat en leveransledning. Den här personen kommer att koppla PO, SM och utvecklingsteamet till en fungerande installation, definiera leveransprocesser och lösa eventuella risker, problem eller konflikter som teamet kan ha. Leveransledaren är rätt person att avgöra projektets bemannings- och budgetfrågor. Denna person ska sträva efter att bygga en miljö för laget där alla kan prestera på sitt bästa.
    • Utvecklingsteamets ansvar är att utveckla berättelserna från backloggen. De kan hjälpa PO att bygga innehåll för vissa berättelser (främst de som är för tekniska), men de är inte ansvariga eller inte ens ansvariga för berättelser som bygger upp färdplanens innehåll.

    #2. Stabilt lag

    Att satsa på teamets agila utbildning är viktigt och måste vara en snabb process. Att låta denna kunskap försvinna med några månaders mellanrum är bara ett slöseri med tid för alla.

    De fem första spurterna kan du använda som en inlärningskurva för laget för att lära känna och träna på de grundläggande scrumaktiviteterna. När de är tydliga för hela teamet kan den kontinuerliga förbättringsprocessen för scrum-teamet starta. Men om människorna i teamet förändras regelbundet, kommer du att hamna i en ständig loop av kunskapsöverföringar och utbildning.

    Ett sådant team kommer förmodligen aldrig att nå full prestationspotential, och ledarteamet kommer att fortsätta att undra varför det tidigare (före den agila transformationen) var mer effektivt än det verkar nu.

    Så bygg teamet, investera kunskapen och när teamet är tryggt med de nya processerna är det bara att behålla det som det är och utvecklas vidare. Härifrån ska den ständiga vägen mot perfektion börja.

    #3. RACI-matris

    Det är en god praxis att bygga upp och komma överens om RACI-matrisen (Ansvarig, Ansvarig, Rådgiven, Informerad) mellan alla team precis innan det verkliga arbetet börjar. Detta kan potentiellt eliminera mycket förvirring redan i början.

    Det är ganska viktigt, särskilt i de tidiga stadierna av omvandlingsinitiativen. Annars kommer personerna att börja ställa frågor om vem som ska göra vad i vilken situation, särskilt i de som inte uttryckligen togs upp via teamets kommunikation.

    Här är ett exempel på en sådan RACI-matris för några av ansvarsområdena. Ditt projekt kan ha en annan uppsättning. Det är viktigt att fånga de relevanta.

    UppgiftRequestorLeverans LeadProduct OwnerScrum MasterDev TeamSprint PlaneringssessionerC/ICA/IRC/IDeliver Release IncrementN/AIA/IC/IRSprint ReviewC/IIRICSprint RetrospectiveIIIA/IRC/IRFörfina BacklogIA/IRAC/I

    Slutsats

    Det kan fortfarande finnas mycket att skriva om, eftersom det finns många sätt och många platser där den smidiga förvandlingen kan leda av banan. Syftet var att peka på några av de problem som jag anser upprepas ofta.

    Initiativet i sig är en bra idé. Det kan dock snabbt bli en mardröm för alla deltagare om man följer några grundläggande regler. Jag lyfte fram några av dem, men använd bara sunt förnuft, så kommer du att klara dig. 🙂

    Kolla sedan in bra lärresurser för Agile-certifiering.