Om du frågar de flesta chefer om "psykologisk trygghet" eller "vision" (läs mer: Psykologisk säkerhet) i sina agila mjukvaruutvecklingsteam är de överens om att dessa saker är viktiga, men... När kunden signalerar brådska eller tidsfristen närmar sig, läggs alla dessa "mjukare" variabler vanligtvis åt sidan. Cheferna är främst intresserade av ett förutsägbart fungerande agilt leveransflöde från sitt agila team.

Om du tittar på vår Echometer-blogg (till vår blogg), vet du att vårt innehåll tenderar att fokusera på att förbättra de mjuka färdigheterna hos team och organisationer. Dessa underskattas ofta av beslutsfattare. Men inte av Scrum Masters och Agile-coacher.

Återigen, vad jag tror Scrum Masters och Agile coacher underskattar är fokus på att förbättra leveransflödet – i grunden vad chefer vill. I dagens inlägg beskriver jag en enkel teknik för att avsevärt öka sannolikheten för att leverera i tid och enligt budget om och om igen.

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 anser att en giltig mätning av hastighet etc. beror på "rätt storlek" på uppgifter eller arbetsobjekt, där alla arbetsobjekt har ungefär samma storlek. Först då är story points (som behövs för att mäta hastighet) användbara för att mäta hastighet eftersom de ser mer ut som 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 därför följande för att bli förutsägbar: Bevaka andelen "nya uppgifter som påbörjas" jämfört med andelen "uppgifter som slutförs". Dessa två bör vara i balans. Med andra ord bör "ingångs-" och "utgångsfrekvensen" för uppgifter ligga så nära varandra som möjligt, helst till och med vara densamma.

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 finns en slutförd uppgift för varje påbörjad uppgift kommer du att ha bättre möjligheter att frigöra de få fokuserade uppgifterna i Daily. Din övergripande prestation blir mer förutsägbar och teamet blir gladare eftersom din chef och dina kunder blir gladare.

Några "positiva symptom" på ett hälsosamt agilt Agile-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. Vad är nu det bästa sättet att komma igång praktiskt? Genom att skapa medvetenhet och "beredskap för förändring" 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" (läs mer: 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: