Fortsätt till huvudinnehåll

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.
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:
Etiketter:

Kommentarer

Skicka en kommentar

Populära inlägg i den här bloggen

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör...
6 kommentarer
Läs mer

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd: "Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?" En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville  så kunde vi skeppa ut produkten med ganska lite efterarbete. Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant. Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre. Jag vill hellre börja med att undersöka om arbetsmötena k...
Skicka en kommentar
Läs mer

Proxy-produktägare förtar effekten

Ibland möter jag team och organisationer som har, eller tror sig kommer att få, stora svårigheter med att engagera de personer som de helst skulle vilja ha som produktägare. Deras försök till lösning kan ibland vara att ducka för problemet, och tillsätta en mindre lämplig person som produktägare. Det kanske vanligaste exemplet är nog det här. En utvecklingsavdelning på ett företag är övertygad om att man aldrig kommer att lyckas övertyga sina produktchefer att ta på sig rollen som produktägare, så man utnämner istället representanter från tekniksidan som mellanproduktägare, eller som man ibland hör, produktägar-proxies. Tanken med en produktägarproxy är att kunna fortsätta kalla den formellt ansvarige för utvecklingsarbetet för produktägare, men samtidigt acceptera att denne inte kommer kunna leva upp till sin roll. Till en början kan detta verka som en lämplig strategi. Utvecklingsteamet får ju i proxyproduktägaren någon man kan gå till för såväl dagliga frågor som för planering...
4 kommentarer
Läs mer