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!

20 september, 2008

Rätt arbetsmängd är avgörande

Några saker sticker ut från när jag lärde mig Scrum från Ken Schwaber i slutet av 2003. En av dem är insikten om hur avgörande rätt arbetsmängd är. Ken beskrev Scrum som fokuserat på "workload management", till skillnad från ett mer tradtionellt fokus på "work management". Scrum Masterns jobb är att hjälpa teamet att ta sig an rätt mängd arbete i sprinten, inte att styra det arbete teamet tar på sig.

Några av fördelarna med att ett team tar på sig rätt mängd arbete:

  • De kan göra ett starkt åtagande. Ett starkt åtagande betyder att teamet tror på och äger sin egen plan. Man har tagit på sig en utmanande mängd arbete, men inte för mycket. Man kan med gott självförtroende säga att man kommer att leverera det man tagit på sig.
  • Man kan leverera med kvalitet. Ett team som har för mycket att göra måste hitta någon sorts ventil att ventilera genom. Den allra vanligaste ventilen är produktens kvalitet. Man sänker helt enkelt kvalitetsambitionerna. Det funkar på kort sikt, men är fullständigt förödande på lång sikt. Ett team som har tagit på sig rätt mängd arbete för en tid, i Scrum en sprint, har tagit på sig den mängd arbete man kan göra med upprätthållande av hög kvalitet. Det betyder att man inte behöver ta genvägar för att nå målet. Vi vet ju alla att ordspråket är sant: genvägar äro senvägar. Mjukvaruutveckling är inget undantag.
  • Moralen förblir hög. I vilket team tror du arbetsmoralen är högst? I teamet som har pressats att ta på sig för mycket arbete, kanske med motivationen att "stretch goals" är bra för dem, eller i teamet som under tankfull dialog inbördes och med produktägaren vridit och vänt på arbetet som behöver göras för att hitta rätt mängd för den kommande sprinten? Min satsning blir på teamet som lagt sin egen ribba.
  • Misslyckande betyder något. Tänk dig ett team som av någon anledning övertygas om att ta på sig mer arbete än de själva tror att de kommer att klara av. Tänk dig sedan att de träffas i en sprintåterblick för att prata om varför de inte lyckats leverera enligt plan. Vad tror du att de kommer att säga? Självklart kommer man att peka ut den press man utsatts för som orsaken till att man inte levererat enligt plan. Tänk dig nu ett team som själva väljer ut hur mycket arbete man kommer att klara av den närmaste månaden. Tänk dig nu att även detta team misslyckas, och därför i sin sprintåterblick diskuterar detta. Det kommer att vara lättare för detta team att vända tillbaks samtalet till den egna rollen i misslyckandet. Därför kommer de att kunna lära sig från sitt misslyckande.
  • Den goda hälsan består. Jag arbetade med ett team på Arbetsmiljöverket vid ett tillfälle. En morgon när jag väntade i receptionen på att insläppt bläddrade jag i en publikation från myndigheten. En siffra stack ut i statistiken som presenterades: att det var så många som led av problem orsakade av att man inte hade kontroll över sin egen arbetssituation. Det är ju inte så konstigt egentligen - självklart är det stressande att förväntas kunna åstadkomma mer än vad som är realistiskt. Det gäller oavsett om man utvecklar mjukvara eller inte. Varför tror vi att det är en bra affär för våra företag att försöka pressa ut mer än vad som är möjligt ur varandra?
Så för att summera: Scrum handlar om att lära sig vad man kan åstadkomma genom att själv få möjligheten att pröva sina vingar. Det lärandet kan inte komma till stånd om situationen komprometteras av ett aldrig så välment tryck att göra mer än vad görararen tycker är möjligt. Du kan välja själv: antingen får du lite, lite, mer just nu, till priset av osäkra åtaganden, dålig kvalitet, låg moral, försvarsmekanismer som förhindrar lärande och dålig hälsa - eller så får du mycket mer på långt sikt, plus leveranssäkerhet, hög kvalitet, hög moral, ständigt lärande och hälsa.

07 september, 2008

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 att göra sitt bästa för att uppnå sprintmålet. Om planeringen tar längre tid är risken större att vi nöjer oss med det vi har och startar sprinten på ett vagt åtagande - en dålig start för effektivt samarbete.

Produktägaren är väl förberedd när han eller hon har arbetat igenom de högst prioriterade sakerna på produktbackloggen inför planeringsdagen. För att göra det tar produktägaren hjälp av teamet för att förtydliga och estimera det som förmodligen kommer att göras härnäst - alltså det som ligger på toppen av produktbackloggen.

Teamet är väl förberett när det kommer till sprintplaneringen med förståelse för vad det kommer att innebära att börja arbeta med de kommande sakerna på produktbackloggen. Man har tittat framåt på det som har hög prioritet, gjort lite efterforskningar, tänkt till kring risker och kanske utvecklat ett testskott på någon funktionalitet som känns svårgreppbar.

Förberedelserna inför sprintplaneringen kan liknas vid att stå i kö för att köpa glass en het sommardag. När vi väl kommer till kassan vill både vi och glassgubben att transaktionen ska gå fort och smidigt, vilket underlättas av lite förberedelse.

Det man absolut inte ska göra är att vänta med att granska det goda sortimentet tills dess man står längst fram i kön. Vissa gör det, och drar på sig övriga köandes vrede. Effektiva glassköpare lutar sig därför ut lite från sin position i kön och tittar på menyn medan de väntar. Så länge man inte står först i kön kan man ju i lugn och ro planera sin beställning. När man sen till slut kommer fram är man en redo köpare. Visar det sig då att någon sort man önskar är slut har man kanske till och med funderat på en backup-smak.

På samma sätt kan både team och produktägare, medan man jobbar i en sprint, titta lite framåt i produktbackloggen och sätta upp en hypotes för vad man sannolikt vill, och kan, få med i nästa sprint. När man sen kommer till sprintplaneringen kan man jobba extra effektivt med att göra ett åtagande om innehåll. Skulle något ha hänt i sista minuten som gör att den hypotes man haft måste förkastas ligger man ändå bättre till än om man kommit oförberedd till sprintplanering.