Köp Boken Scrumtips!

Om du vill ha alla scrumtipsen samlade i ett bekvämt format som fungerar i både läsplattan och på mobilen, så köp ett exemplar av min bok Scrumtips. Du sätter själv priset!

31 mars, 2012

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:

30 mars, 2012

Läsning till hängmattan

Robin, som gått kurs hos mig, hörde av sig och ville ha lite (jobbrelaterade) lästips till hängmattan. Jag utgick från att han hade en hängmatta med starka rep, och stor läslust, och svarade med denna lista.


De böcker som varit till störst användning för mig har inte alls handlat om agila metoder per se, utan om alla de saker man behöver förstå och träna på för att lyckas med att jobba agilt.
  • Becoming a Technical Leader av Jerry Weinberg, som handlar om den typ av stöttande ledarskap som behövs för att lyckas med den här typen av arbetssätt
  • Leading Self-Directed Work Teams av Kimball Fisher. Handlar om hur man får igång team på riktigt.
  • Project Retrospectives av Norm Kerth handlar om att leda retrospektiv, och föregår mycket av det Esther Derby skriver om i sin Agile Retrospectives-bok
  • The Blind Men and the Elephant av David Schmaltz
  • Zen and the Art of Motorcycle Maintenance, som jag blir sugen på att läsa igen bara jag skriver namnet på den. En kombination av road trip och filosofisk avhandling. Handlar om vad vi egentligen menar med kvalitet.
  • Idealized Design av Russell Ackoff. Kompletterar agila metoder med metodik för att etablera en vision att iterera mot. Det är inte tillräckligt att bara vara flexibel och lättrörlig, vi måste veta vad vi rör oss mot också.
  • Scaling Lean and Agile av Bas Vodde och Craig Larman. Handlar om teori och praktik kring användning av agila metoder i större organisationer.
  • The Five Dysfunctions of a Team av Patrick Lencioni. Ett ramverk för att förstå och utveckla team.
  • The Power of Learning av Klas Mellander. Handlar om hur vi lär oss, och varför så mycket av traditionell undervisning misslyckas med att sprida förståelse. Relevant när man börjar prata om att köra utbildningar på stor skala för många medarbetare.
  • Slack, av Tom deMarco. Brilliant skrivet om vikten av att ha spelrum på jobbet, problemen med övertid, svårigheterna att planera och mycket mer.
  • Are Your Lights On av Jerry Weinberg. Om hur vi ser på problem och hur vi löser dem.
  • The Psychology of Computer Programming. Jerry var tidigt ute med att kombinera teknik och psykologi för att få en bättre helhetsbild av vad som får utvecklingsarbete att lyckas eller misslyckas.
  • The Fifth Discipline av Peter Senge. Storsäljare från 90-talet om systemtänkande och systemdynamik, om hur vi själva orsakar många av de problem vi drabbas av, och vad vi kan göra åt det.