I morse satt jag och filosoferade över en kopp kaffe med Björn, som är utvecklingschef. Specifikt kom vi att diskutera något som är lite av ett återkommande tema; hur hanterar man krav som kräver så mycket analys att man inte hinner göra klar funktionalitet under sprinten?
Verksamheten i stort kan vara överens om en viss sprintlängd. Men ibland kan den tyckas för kort för vissa utvecklingsinsatser som kräver en större del förundersökning och analys. Det kan få effekten att man ägnar sprintplaneringen åt större analysarbete, vilket i sin tur gör att den kan bli väldigt lång, och sprinten känns som ett litet vattenfall.
"Kan man leverera och demonstrera delresultat vid slutet av en sprint? Ska vi inte alltid visa upp affärsnytta?"
Jo, förvisso. Men bedömningen av vad som är affärsnytta görs ju av produktägaren - och om produktägaren ser ett värde i att få strategiskt underlag för vägval i kommande sprintar, så är ju det gott nog. Om vi dessutom lyckas leverera något övrigt i form av funktion eller kvalitet som har affärsnytta så är det ju utmärkt!
Att ständigt försöka leverera ett klart men inte komplett system efter varje sprint är ett sätt för oss att bygga in många aspekter av taktat arbete i verksamheten. Därför ska vårt rättesnöre vara att försöka bryta ned problem till "sprintformat" så långt möjligt. Men i lägen där vi har svårt att uppskatta storleken på ett krav, är det betydligt mer relevant att försöka uppskatta storleken på att utreda kravet och ta fram lösningsförslag, gärna med ett provskott, och lägga in det som en arbetspunkt i sprinten.
Upskattningar måste tillåtas vara av inkrementell och iterativ karaktär, precis som annat arbete. Det innebär att skattningen vi gjorde på hög nivå, för att se vilken härad en uppgift skulle kunna vara inom (dagar? månad? år?) kan behöva förbättras i en senare sprint och det är ett arbete i sig, som ska tidsuppskattas och planeras i en sprint. Erfarna utvecklare arbetar med min/max/medelestimat och liknande tekniker för tidsuppskattningar.
Jag mindes ett tillfälle då jag coachade ett team som frågade mig när reder vi ut saker egentligen. Pedagogiskt (tyckte jag) att jag svarade med motfrågan "när brukar ni reda ut saker?" Svaret överraskade mig:
"Vi brukar förväntas göra det på annan tid"
Vilken annan tid? Det visade sig att verksamheten var så van vid att tidsestimaten skulle baseras på att koda funktioner, att teamet ägnade kvällar och i vissa fall helger åt att reda ut hur de skulle implementeras! Dolda-kostnader-sirenen ljöd plötsligt över kontorslandskapet!
Ni kan tro att det blev en smärre initial chock när vi började synliggöra den faktiska kostnaden för utvecklingsarbetet genom att börja planera in utredningsarbete i sprintarna.
Tillbaks till min gode vän Björn. Han uttryckte det på ett bättre sätt än jag själv någonsin kunnat göra det, så jag återger det här:
"Jag antar att vi kan välja mellan två angreppssätt, och låta tillfället och uppgiften styra.
Antingen kan vi betrakta vissa typer av utredningar som hinder för effektiv mjukvaruproduktion, och därigenom avsätta tid i sprintarna för att röja undan dessa hinder.
Eller så betraktar vi resultatet av vissa utredningar som nytta, som produktägaren kan förstå och prioritera som separata arbetsinsatser med leverabler i form av resultat"