Agile Leveransflöde: Leverera alltid i tid i 3 steg

Frågar man de flesta chefer om den “psykologiska tryggheten” eller “visionen” (mer om det: Psykologisk säkerhet ) för deras agila mjukvaruutvecklingsteam, håller de med om att dessa saker är viktiga, men… När kunden signalerar brådska eller deadlinen närmar sig, skjuts alla dessa “mjukare” variabler vanligtvis åt sidan. Cheferna är främst intresserade av ett förutsägbart fungerande agilt leveransflöde för sitt agila team.

Om du tittar på vår Echometer-blogg ( till vår blogg ) så vet du att vårt innehåll snarare fokuserar på att förbättra teamens och organisationernas “mjuka färdigheter”. Dessa underskattas ofta av beslutsfattare. Men inte av Scrum Masters och agila coacher.

Vad Scrum Masters och agila coacher i sin tur underskattar, enligt min åsikt, är koncentrationen på att förbättra leveransflödet - i grund och botten det som chefer vill ha. I dagens inlägg beskriver jag en enkel teknik för att öka sannolikheten för att leverera i tid och inom budget gång på gång.

Första steget i förhållande till ditt Agile Delivery Flow

Jag talar om att övervaka Agile-leveransflödet för dina uppgifter. Om du bara gör några få saker rätt kommer du att kunna leverera mycket mer förutsägbara resultat. Till och med dina spridningsdiagram för cykeltid eller din Monte Carlo-simulering för att beräkna projektuppskattningar kanske äntligen visar på giltiga förutsägelser istället för att vara helt fel ute (läs mer: 9 Agile Mått för beslutsfattare ).

Det första symptomet att bekämpa är att det finns uppgifter som bara tar några dagar från “Schemalagd” till “Slutförd”, och sedan finns det uppgifter som tar mer än en månad. För att motverka detta bör du se till att en uppgift alltid innehåller den minsta möjliga leverbara versionen av den önskade funktionen. Utan klockor och visselpipor som inte är nödvändiga för kundens kärnförfrågan. I grund och botten en MVT, Minimum Viable Task. Det betyder inte att det gör varje uppgift liten. Men det bör hjälpa dig att nå ett stadium där uppgifter tar högst några veckor, snarare än månader.

Andra steget i förhållande till ditt Agile-leveransflöde: WIP istället för Velocity

Många Scrum Masters eller Kanban-coacher tror att det för en giltig mätning av Velocity etc. handlar om att “right size” uppgifter eller arbetsuppgifter, där alla arbetsuppgifter är ungefär lika stora. Endast då är Story Points (som behövs för att mäta Velocity) användbara för att mäta Velocity, eftersom de mer liknar en jämförbar tidsenhet. 

Men detta är fel: uppgifterna behöver inte ens vara av samma storlek. Du bör inte anta det, eftersom det är alldeles för svårt att kontrollera Story Points uppskattningar. Det enda du kan kontrollera är hur många nya uppgifter du startar.

Gör alltså följande för att bli förutsägbar: Övervaka andelen “nybörjade uppgifter” jämfört med andelen “avslutade uppgifter”. Dessa två bör vara i balans. Med andra ord: In- och utflödet av uppgifter bör ligga så nära varandra som möjligt, helst till och med överensstämma.

Ett exempel: Ett typiskt beteende i programvaruutvecklingsteam är att så snart en uppgift blockeras påbörjas ett nytt arbetsobjekt. Detta leder till att många uppgifter är öppna men oavslutade, vilket gör det mycket mer komplicerat att avblockera dem alla igen. 

Om du istället ser till att det för varje påbörjad uppgift också finns en avslutad uppgift, blir det lättare att ta bort blockeringar för de få fokuserade uppgifterna i Daily. Din prestation kommer totalt sett att bli mer beräkningsbar - och teamet kommer att bli nöjdare eftersom din chef och dina kunder är nöjdare.

Några “positiva symptom” på ett hälsosamt agilt leveransflöde

I praktiken skulle detta leda till följande beteenden:

• • Vi påbörjar inte nya uppgifter när det fortfarande finns många saker som pågår. 

• • Vi fokuserar på att avsluta det vi har påbörjat innan vi börjar med nya saker.

• • Uppgifterna är aldrig äldre än några veckor.

• • Om det inte finns något bra skäl arbetar vi alltid med den äldsta uppgiften.

WIP-gränser (work-in-progress) hjälper också till med detta, även om de ofta inte är tillräckliga. När teamet har lärt sig att fokusera på att slutföra uppgifter i stället för att bara påbörja nya, kommer ni att vara bättre än de flesta team.

Om du använder Agile Delivery Flow korrekt

Att skapa tydliga förväntningar: På det här sättet kan du fortfarande inte kontrollera om en uppgift tar två eller tre dagar. Men du kan åtminstone se till att ditt team inte arbetar med så många uppgifter att 2-3-dagarsuppgifter tar en månad.

Hur mycket bättre skulle ditt team vara om ni visste att i princip alla leveransåtaganden skulle uppfyllas inom några veckor? Detta förutsätter naturligtvis att du implementerar alla de saker som nämns ovan: Fastställande av MVT, en strikt WIP-gräns och ett åtagande att inte starta om uppgifter förrän en annan uppgift har slutförts.

Steg 3: Kom igång med att förbättra leveransflödet för Agile

I teorin vet du vad du ska göra. Hur kan man bäst komma igång i praktiken? Genom att skapa medvetenhet och “förändringsbenägenhet” i teamet. I bästa fall genom självreflektion.

Du måste vara transparent med dessa siffror och kontrollera dem regelbundet för att se om förhållandet mellan påbörjade och slutförda uppgifter är i balans. Det kan vara en del av din retrospektiv att gå lite djupare och reflektera över varför siffrorna inte var i balans under den senaste cykeln. 

Jag kan rekommendera att du diskuterar de beteenden jag nämnde med vårt agila retrospektivverktyg Echometer i ditt retrospektiv (läs mer: 7 Retrospektiva verktyg i jämförelse ). Ni kan till och med göra detta till en del av era arbetsavtal eller regelbundna Health Check för att öka medvetenheten genom att ställa frågorna regelbundet.

Följande frågor är vår retrospektiva mall för “agil leverans” (mer om det: 22 roliga mallar för agila retrospektiv ). Vi börjar med några Health Check-påståenden och frågar teamet om de håller med eller inte. Därefter följer några öppna frågor:

Agile Leverans Retrospektiv

Health Check Artiklar

När har vårt sätt att arbeta lett till ett suboptimalt arbetsflöde? (t.ex. otydliga, olämpliga eller inte följda riktlinjer)

Som du kan tänka dig antyder den sista punkten i hälsokontrollen (kontrollera orsaken) redan en potentiell åtgärd, något du kan prova under en till två agila sprintar för att se om det kan hjälpa dig: Begränsa antalet uppgifter med statusen “Work in Progress”.

Lägga grunden: Upprätta överenskommelser för teamarbete

Har du känslan av att ditt team ännu inte är redo för den här typen av reflektion? I så fall bör du först reflektera över “bra arbete” i allmänhet och sedan fastställa några grundregler, så kallade arbetsöverenskommelser eller Working Agreements. Följande workshopmall kan hjälpa er med detta. Du kan genomföra den som en speciell form av retrospektiv i början av ett projekt eller som en extra workshop.

Först bör du få en uppfattning om hur enigt ditt team känner sig implicit - se Health Check Item för detta. Sedan bör du kontrollera detta praktiskt med några öppna frågor. Varje teammedlem måste avsluta meningen (se fler frågor) med så många svar som möjligt som han/hon kommer att tänka på:

Teamets åtaganden Retrospektiv

Health Check Artiklar

Hantera konflikter: “Om jag märker att en konflikt uppstår i vårt team, då …

När ni har samlat in svaren bör ni naturligtvis försöka hitta mönster och komma överens om konkreta överenskommelser om hur ni vill samarbeta i framtiden - åtminstone tillfälligt som ett experiment.

Ett intressant och kreativt alternativ

Falls euch diese Retrospektive Methoden zu “trocken” erscheinen, gibt es eine weitere Retrospektive Methode, die sich darauf konzentriert, die Qualität des Outputs deines Teams zu reflektieren ( Fun 54 Retrospektiva metoder hittar du här ): “De tre små grisarnas” retrospektiv. Det är ett enkelt alternativ för att börja reflektera och förbättra din prestation, baserat på sagan om de tre små grisarna som byggde hus av olika material.

Fazit - Agile Delivery Flow

Oavsett hur du börjar är det viktigaste att du börjar från första början. De team som håller ett aktivt öga på sitt Agile-leveransflöde är de bättre teamen.

Übrigens sind viele der Ideen, die du hier findest, auch im Podcast “Agile Bites” gut zusammengefasst, den ich sehr empfehlen kann (Zum Podcast: Agile Bitar). 

Ha så kul med att utveckla ditt team!