Vad blir resultatet av att göra för mycket och hur ser man det? Här är en berättelse som beskriver detta.

Låt mig introducera Team Stångån. Stångån är ett tvärfunktionellt team som jobbar med en liten del av ett stort mjukvarusystem. De har jobbat tillsammans i över ett år och har baserat sitt arbetssätt på Scrum.

Företaget som Stångån jobbar för, Roxen, är ett stort och stabilt företag som har funnits i flera decennier. På senare år har Roxen dock börjat bli allt mer hotade av stark konkurrens och det märks från ledningen att de är under hård press. Som en konsekvens av detta så är det många som känner att de behöver göra allt för att öka sin effektivitet.

Team Stångån är inget undantag och deras Produktägare ber dem ofta att få med så mycket som möjligt i sprintarna. Även fast deras Scrum Master poängterar att det leder till att mycket av det de planerar inte blir färdigt så verkar inte Produktägaren bry sig om det. Bara de levererar så mycket som möjligt så spelar sprintarna ingen roll. Scrum Masterns känsla är dock att de levererar mindre. Hon bestämmer sig för att börja visualisera hur mycket teamet jobbar med och hur mycket som blir klart. Hon hittar data från ett antal sprintar tillbaka i ärendehanteringssystemet.

Hon visualiserar pågående arbete i blått och när det blir färdigt så blir det orange. Scrum Mastern tycker att det är fiffigt att det bara byggs på, för då kan man se långt bak i tiden och ända fram till nutid i samma bild, likt årsringarna i ett träd. På så sätt kan hon jämföra tiden innan läget blev mer pressat med nutiden. I grafen nedan visar den blå strimman hur mycket arbete som var pågående vid varje givet tillfälle, medan det orangea fältet visar hur mycket som har blivit slutfört.

Scrum Mastern reagerar på att det blå fältet blir tjockare och tjockare från vecka 4. Det var då som deras Produktägare började bli riktigt stressad och de kom överens om att ta in mer i sprintarna. Det ledde till en ökad mängd pågående arbete. Scrum Mastern minns från sin utbildning att pågående arbete, eller WIP (Work In Progress) som det brukar kallas, ofta är dåligt för flödet. Tjockleken på det blå fältet är alltså WIP - toppen!

Förhoppningen från Produktägaren var förstås att teamet skulle leverera mer när de hade mer arbete i sprintarna - frågan är om det hände? Scrum Mastern tittar nu på det orangea fältet. När arbete går från blått till orange så betyder det att det blivit färdigt, så det måste ju betyda att lutningen på det orangea fältet visar hur snabbt de levererar. Jämför man de första 3 sprintarna i grafen mot de senare så har lutningen, och alltså teamets genomströmning (eng. throughput), minskat! Detta måste vi diskutera med produktägaren.

De tar ett möte där de tittar på grafen tillsammans och Scrum Mastern förklarar vad hon lärt sig för Produktägaren. Produktägaren förstår logiken i att ju fler saker man gör samtidigt ju långsammare går varje sak och mycket tid förloras till task switching. Han ber om ursäkt för att han pressade dem att ta in mer i sprintarna och förklarar sin situation. Produktägaren berättar att han får mycket frågor om när saker kommer vara färdigt och att han hade märkt att det lugnade sig när saker planerades i en sprint. Men nu när det mesta som planeras i varje sprint inte blir färdigt så får han ändå många frågor.

Team Stångån och deras Produktägare tar en diskussion där de påminner sig själva om att de vill samma sak - leverera så mycket värde till kund som möjligt. Produktägaren säger att han ska lita på Teamet i hur mycket de planerar i sprintarna. Teamet i sin tur uppmuntrar Produktägaren att ge dem återkoppling på om de kan öka sin transparens för vad som händer i sprintarna. De börjar med att plocka ut påbörjat arbete tills deras WIP är på den nivå som de hade innan vecka 4. Några sprintar senare så ser grafen ut som nedan. Den streckade röda linjen visar resultatet om trenden från de överfulla sprintarna hade fortsatt.

Genom den här berättelsen ville jag visa på värdet av att visualisera ett flöde. Jag upplever att det är vanligt att även om Team har en känsla av att de får mindre gjort när de tar in mer arbete, precis som i berättelsen, så har de svårt att visa det och få gehör för det. Man kanske kan visa siffror på att man levererar mindre i sprintarna, men det ger sällan en lika bra diskussion som när man kan titta på en graf tillsammans.

Det som Scrum Mastern skapade här brukar kallas för ett kumulativt flödesdiagram (eng. Cucmulative Flow Diagram - CFD). Det är en väldigt enkel graf att skapa samtidigt som den ger mycket information i samma bild, med nackdelen att det inte är den enklaste grafen att förstå sig på. Grunderna är dock inte svårare än detta:

• Tjockleken i Y-led är hur mycket som finns i fältet. WIP om du kollar på In Progress.
• Lutningen på ett fält visar hur snabbt det ökar. Inflöde för In Progress och utflöde för Done.
• Tjockleken i X-led visar hur lång tid arbete finns där i genomsnitt. Ledtid för In Progress.

Kumulativa flödesdiagram kan användas för vilken typ av flöde som helst. Till exempel för Stories i ett Team, Features eller Epics för ett Team-av-Team, eller varför inte incidenter. Man kan även lägga till fler fält utöver In Progress och Done, till exempel Analysis eller Testing, och kan då se WIP, in- och utflöde och ledtid för de fälten på samma sätt. Funktionalitet för detta finns inbyggt i Jira, men det är även enkelt att göra i Excel eller liknande.

Lycka till! Hojta gärna om du har några funderingar kring just ert flöde!