Hur hanterar man leveransåtaganden i Scrum?

Johan, som anlitat mig som konsult tidigare, mailade mig med några frågor.

"Länge sedan sist. Jag har en fråga till dig på lite argumentation kring agil utveckling och främst scrum. Det rör egentligen hur man hanterar commitments på leverans i scrum. Typ: 'ni scrum-tomtar säger ju alltid att ni aldrig kan garantera vad ni kommer att leverera det funkar ju inte. Skulle du köpa ett arkitektbyggt hus till ett fast pris utan att veta vad du får?' (alternativt rörligt utan några som helst garantier). Ofta beställare som känner att man inte har något commitment från projektet på slutresultatet. Jag kan argumentera mot detta men det blir ofta ganska komplicerat och långt. Skulle vilja ha ett kortfattat svar."

Jag svarade Johan att jag inte har något universalrecept, men väl lite tankar om hur man kan närma sig ett svar. 

Korta svaret: 

"vi kan inte förutsäga framtiden, men vi kan prioritera och utföra jobbet på ett sätt som maximerar sannolikheten att vi bygger en produkt som löser problemet och att vi får valuta för pengarna - även om vi inte fick med varenda funktion vi från början tänkte oss".

Lite mer, om personen man pratar med inte redan blivit högröd och stormat ut ur rummet: 

"Vi kan komma överens på hög nivå vad vi ska åstadkomma, istället för att låsa in oss kring en exakt specifikation. Med en kravbild på hög nivå kan vi säga något om vad vi helt säkert kan klara av inom projektramarna, ett kärnscope, även om vi måste låta det vara osagt hur mycket av det lägre prioriterade vi hinner med." 

Mer: 

"En mer detaljerad lögn är inte mer sann. På samma sätt är det med en projektplan: bara för att vi detaljerar den mer blir den inte bättre på att ge oss det vi vill ha. Tvärtom: ju tidigare vi tar beslut, desto sämre kunskap har vi ju. Om vi däremot tar fram detaljerna allt eftersom vi jobbar vidare, så kan vi ta beslut baserat på all den nya kunskap vi börjat bygga upp." 

Ännu mer: 

"Det finns ingen motsättning mellan att jobba med Scrum och att planera på längre sikt, men Scrum har heller inget magiskt trick som löser problemet med planering. Osäkerheten finns fortfarande kvar, men, genom att priortera backloggen efter nytta och risk - och verkligen utveckla i den ordningen - så kan vi försöka sätta oss i en situation där vi utvecklar det viktigaste först. Måste vi sedan hålla en deadline kan vi kapa på omfånget av planen. Och nej, "allt måste" inte med. Det går alltid att jobba med att bygga en enklare produkt som löser problemet." 

Så är i varje fall tanken. Så vad är problemen därute i verkligheten?

• Det är inte ovanligt att Scrum sönderfaller till att bli "vi jobbar bara en sprint i taget". Jag tror att det ibland är en motreaktion mot att man tidigare mer eller mindre avtvingats ett löfte om fast scope, på en fast tid till en fast kostnad. 
• De flesta organisationer har enorma problem med att bygga klar och testad produkt i varje iteration. När man inte kan göra det, utvecklar man inte heller produkten stegvis, och kan därför inte bryta och räkna hem nyttan med en leverans, om man skulle slå i tids- eller pengataket. 
• Större organisationer har ofta en projektfinansieringsmodell som bidrar till att provocera fram specifikations- och planeringstunga projekt. Man behöver passera en beslutspunkt om projektstart. För att göra det behöver man ett business case. För det krävs en nytto/kostnads-bedömning. För kostnadsbedömningen krävs en estimering. För det upplever man att man behöver en detaljerad kravspecifikation, vilket man tar fram. Sedan slutar det med att man styr projektet mot den, istället för mot en målbild på högre nivå.
• Organisationer tenderar enligt min erfarenhet att pressa in precis så mycket risk som går i projekt, och därmed pressa ut allt spelrum som skulle kunna använts för att hantera oväntade insikter och lärdomar som kommer upp längs vägen. Alltså: om någon tar fram en projektplan med "för mycket luft", och som därför KAN lova ett visst innehåll till ett visst datum och en visst kostnad (eftersom man buffrat planen ordentligt på alla sätt och vis), så kapas planen raskt till så att den får mindre chans att lyckas. Hur gör arkitekten för att kunna sätta ett fast pris på sitt jobb? Dels erfarenhet förstås, men också en bra förmåga att ta betalt skulle jag gissa. Fina marginaler. 

Johan undrade också om jag hade några lästips på temat "commitments, agilt, lean och scrum".

En intressant teknik för planering på längre sikt i agila projekt som jag börjat använda mig av så smått är "user story mapping", som är ett sätt att bygga upp sin backlog så att man delar upp projektet i releasebara delar på ett mycket visuellt sätt. Passar bra att göra i workshopform, vilket för mig är det enda sättet att jobba med planering, agilt eller ej. Planen är inget, planeringen allt.

• Story mapping: http://www.agileproductdesign.com/writing/how_you_slice_it.pdf 

Böcker på temat:

• Spelrum på jobbet, Tom deMarco (generellt om mekanismerna kring commitments på jobbet) 
• Poppendiecks lean-böcker (tror jag har en del om kontrakt, om jag inte minns fel) 

Artiklar online:

• Optional Scope Contract av Kent Beck (XP-skaparen) har framför allt en bra beskrivning av vilka problem ett traditionellt "kontraktstänkande" skapar för båda parter i ett samarbete:http://www.xprogramming.com/ftp/Optional+scope+contracts.pdf