Jag blir ofta engagerad som Agil coach av organisationer som upplever att de har problem med sina IT-leveranser.
När man skrapar lite på ytan så visar det sig att problemen ofta manifesterar sig just i själva leveransen.
- Leveranser drar ut på tiden
- Har inte heller den kvalitet man har förväntat sig.
- Skapar inte heller den affärsnytta man som beställare förväntat sig.
Om man följer processen bakåt så kan man se att det verkliga problemen faktiskt uppstår betydligt tidigare
- Leveransen sker inte i tid eftersom man inte kontinuerligt mäter framdriften, mycket är “In progress” och nästan klart” hela vägen fram till release. Man missar tendenser och trender som man borde ha kunnat identifiera tidigt.
- Att man inte kan mäta framdriften beror ofta på att man inte har gjort tydligt vad som faktiskt ingår i sprinten eller releasen. Otydliga User stories läggs in i sprinten och man gör så gott man kan när det gäller leveransen.
- Att man inte har tydliggjort vad en User story faktiskt innebär i form av komplexitet och beroenden beror på att man inte gjort tydliga prioriteringar, allting är “High”, “Bråttom” och “Prio 1” vilket gör att man sprider ut arbetet på en mängd olika aktiviteter istället för att fokusera på det som är viktigast
- Att man inte har kunnat göra någon prioritering beror på att det inte finns någon tydlig vision eller strategi för vart man är på väg med produkten eller projektet.
Hur blev det så här?
Jag träffar många team som har en överfylld backlog där allt man kan komma på som behöver göras finns med och ofta innehåller den hundratals aktiviteter i en enda lång lista. Enligt agila modeller ägs en Product backlog av den som är Product owner som ansvarar för att prioritera vad som ska göras. I praktiken är detta oftast mer eller mindre omöjligt då det bara är en lång lista med aktiviteter utan något egentligt sammanhang. I många fall resulterar detta i en “best effort” från båda håll. Produktägaren lyfter in ett antal aktiviteter i sprinten och teamet levererar efter bästa förmåga.
Hur borde vi göra då?
Så hur borde vi arbeta för att ge utvecklingsteamen en ärlig chans att faktiskt leverera den affärsnytta som vi behöver?
Om vi följer modellen ovanför så behöver vi:
- Hämta behoven från existerande affärsplaner, förvaltningsplaner, strategidokument, visionen för produkten etc.
- Baserat på existerande planer gör prioriteringar och avvägningar baserat på affärsnytta, tid och tillgängliga resurser.
- Baserat på prioriteringar görs åtagande för kommande releases och sprintar.
- Leveranser följs upp baserat på åtaganden för att identifiera avvikelser tidigt.
- Leveranser görs i tid och till en överenskommen kvalitet!
Det här är ett av momenten som vi går igenom i kursen “Confluence för Produktägare” som är en del av modellen Agile 360 och som syftar till att skapa en arbetsstruktur där du Implementerar ett ekosystem av information hela vägen från strategiarbetet, via din roadmap till de konkreta krav och leveranser som hanteras i Jira för att leverera den tänkta affärsnyttan.
Läs mer om filosofin bakom Agile360 här
