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:

Kommentarer

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

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…