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!

17 april, 2012

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 kan göras mer effektiva, snarare än att hålla dem mer sällan. Många organisationer lider av dåliga arbetsmöten som bara blir slöseri med alla närvarandes tid. Så, börja med att se till att mötena är ett under av effektivitet.

Hur kort ska en sprint vara då? En sprint kan inte vara så kort att utvecklingsteamet inte hinner bygga ett värdefullt eller intressant produktinkrement. Många organisationer klarar helt enkelt inte att få ihop något vettigt på två veckor, eftersom man inte har en utvecklingsprocess som är tillräckligt bra. Om detta är ett problem behöver vi börja redan idag med att lära oss hur man egentligen gör för att utveckla mjukvara i korta iterationer.

Ofta handlar det om att komma upp på banan med saker som vettiga bygg- och testmiljöer, och såklart automatisering av byggen och vissa tester. Inte sällan finns det även tuffare saker att ta itu med, som när våra utvecklare helt enkelt inte är särskilt duktiga på att skriva begriplig och väldesignad kod.

Sammanfattningsvis: en sprint ska vara så kort att man inte hinner känna behovet att ändra riktning under sprintens gång, men så lång att teamet faktiskt hinner göra klart något som är värdefullt.

Jobbar ni i sprintar? Hur långa sprintar har ni just nu? Hur fungerar det för er?

12 april, 2012

Introduktion till story points

Estimering med storlekspoäng är en sån där sak som somliga älskar och andra tycker är totalt förvirrande. Jag gillar det lugna sköna tempot i den här korta snutten om story points från Rally Software.


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.

21 december, 2011

Vad är en scrum-coach?

Vad är en scrum-coach egentligen? Trots att jag sällan kallar mig scrum-coach har jag arbetat med att coacha andra i att använda Scrum sedan 2003, när jag först lärde mig om Scrum på allvar och började använda metoden i praktiken.

Jag brukar inte kalla mig för scrum-coach, utan för konsult. Om någon som pratar engelska frågar vad jag gör säger jag att jag är en “software management consultant”, vilket låter rätt pretentiöst när man väver in titeln i en svensk mening. På engelska låter det - i mina öron - som en saklig beskrivning av vad jag gör: jag jobbar med chefer, ledare och team för att förbättra hur man styr och leder sin mjukvaruutveckling. Kärt barn har förstås många fler namn. Andra som gör det jag gör använder titlar som mentor, rådgivare eller agile coach.

Eftersom jag arbetar som konsult i ordets ursprungliga bemärkelse (jag erbjuder en konsultativ tjänst) anpassar jag mitt engagemang hos kunden efter vad situationen kräver. Ibland gör vi en serie workshops, ibland finns jag på plats några dagar i veckan under ett längre förändringsarbete. Jag har bott i Uppsala sedan mitten på nittiotalet, när jag utbildade mig till systemvetare på Uppsala Universitet, och mina kunder finns utspridda lite här och där. De flesta finns i Stockholmstrakten, och några i Göteborg och Malmö. Lite flängigt ibland, men det är också uppfriskande med miljöbytena.

Men, om vi struntar i titlarna och fokuserar dels på syftet med att ha en scrum-coach, dels hur det kan gå till i praktiken, hur ser det ut då?

Syftet
Syftet med att ta in en coach i Scrum kan tyckas självklart. Det är väl att få hjälp att införa Scrum? Tja, det är en bra start, men verkligheten är inte fullt så enkel. Inget företag “inför” bara Scrum, och så är det bra så. Scrum är ett enkelt ramverk som hjälper sin användare att upptäcka vilket arbetssätt som fungerar bäst för just den egna organisationen.

Att börja med Scrum är heller inget självändamål. Om förändringen ska leda till något gott behövs ett mål som ligger bortom själva metoden. Något större, något mer lockande och mer relevant för verksamheten. Det kan handla om allt från att vi ska trivas bättre på jobbet till att vi ska bli mer effektiva. Ofta är det en blandning av många olika faktorer. Min erfarenhet är att det är oerhört viktigt att jobba med att identifiera vilka dessa större mål är, så att vi kan jobba mot dem över tiden.

En scrum-coach uppdrag är därför inte bara att hjälpa till att införa Scrum, det är att hjälpa människorna i en organisation lyckas med hjälp av Scrum. Det kan tyckas som en hårfin skillnad i formulering, men för mig är den avgörande. För mig betyder det att vi använder Scrum för att hitta det som behövs för just den specifika organisation jag jobbar med just nu. Det är skillnaden mellan att blint hamra in en metod, och att lyhört upptäcka vad som verkligen passar och behövs.

Hur
Scrum introduceras inte med en vattenfallsplan. Det är ingen idé att sätta sig ned och planera ut i detalj exakt vilka steg som ska tas för att rulla ut metoden. Det är inte så Scrum fungerar. Scrum bygger på granskning och anpassning. Vi formulerar en hypotes, testar den, och lär oss av resultatet. Skölj och upprepa vid behov. Jag gör på samma sätt i själva förändringsarbetet: en tillräckligt bra plan, så tydliga mål vi kan sätta upp, sedan itererar vi.

En erfaren scrumcoach hjälper sin kund att balansera fokus på de större mål man siktar på med regelbundna konkreta förbättringar. Märker jag till exempel att det fortfarande är otydligt hur prioriteringarna ser ut, så lär jag ut några enkla men kraftfulla visualiseringstekniker och förklarar för kunden hur de kan hjälpa oss att komma närmare målet “Alla känner till våra prioriteringar”. Vi anpassar kontinuerligt både förändringens innehåll och vår timing för att passa situationen.

Vad
Att börja med Scrum omfattar så oerhört mycket mer än att bara genomföra de ceremonier som beskrivs i metoden. Att komma igång med gemensam planering och uppföljning, upprätta en backlog och förtydliga teammedlemskapet kan vara nog så svårt, men de utgör ändå bara en bråkdel av en scrumresas omfång.

Scrum omfattar precis allt som påverkar de resultat vi presterar i vårt utvecklingsarbete. Scrums mål är ju att hjälpa oss lyckas uppnå våra mål på ett effektivt och tillfredställande sätt. Det betyder att Scrum också kräver att vi tar itu med vad det nu kan vara som hindrar oss från att lyckas.

Här är några saker som detta har inneburit för mig genom åren:

  • Utbilda organisationens chefer i värdet av arbetsro och fokus
  • Höja kunskapen om hur tvetydigt det skrivna språket är
  • Lära ett teams medlemmar ge varandra tydligare feedback
  • Utmana byråkratin
  • Lyfta fram och diskutera alla olika åsikter som finns om förändringen
  • Möblera om på kontoret
  • Rekrytera produktägare, eftersom ingen gått att hitta internt
  • Öva sig på att modellera på en tavla, istället för att bara prata om designval
  • Automatisera tekniskt arbete som stjäl tid
  • Ta fram effektiva dokumentationsmallar
  • Introducera digitala verktyg för att hantera krav
  • Sparka ut digitala verktyg för att hantera krav
  • Sätta upp pulsmöten för att synkronisera skilda avdelningar och grupper

Listan skulle kunna fortsätta i all oändlighet. Att börja med Scrum innebär mer än att bara börja med Scrum, skulle man kunna säga.

Scrum i annat än mjukvaruutveckling
Ännu bredare blir uppdraget när man inser att Scrum, och särskilt principerna bakom Scrum, kan användas även utanför mjukvaruutveckling. Över åren har det också blivit så att jag även jobbat med driftsgrupper och marknadsavdelningar. Om några år kanske jag suddar ut “software” helt ur min titel, men jag tror det kommer dröja. Mjukvara är ju trots allt det som ligger mig närmast om hjärtat, och de andra grupper jag jobbat med har alla verkat inom mjukvaruutvecklande företag som valt att satsa på lättrörlig utveckling.

12 december, 2011

Är vi klara snart, eller?

Vad betyder det egentligen att vara klar med något? Det är svårt att komma överens om det, eftersom vi har olika mål, perspektiv och behov. En begriplig och gemensam definition av vad det innebär att vara klar med en ny funktion kan göra utvecklingsarbetet både effektivare och mindre frustrerande för alla inblandade.

Utvecklare tycker ibland att arbetet är klart när de funktioner som efterfrågats finns implementerade i kod. Testare brukar vilja fylla i med att funktionerna måste vara testade också. Folk i supporten brukar lägga till att buggarna man hittade under test gärna får vara lösta innan man levererar ut funktionen till användarna. Nyanställda utvecklare brukar gräma sig över att den kod som skrevs innan man själv började är så grötigt skriven att det nästan är omöjligt att sätta sig i den. Därför vill de lägga till att koden ska vara snyggt skriven och väl designad.

Scrums definition på att vara klar med något är ganska krävande. De flesta organisationer får jobba länge på att lära sig nå upp till Scrums klarkriterium.

I Scrum är en funktion klar när:
  • Funktionen fungerar som den ska för användaren, som därför kan använda den nya funktionaliteten för att uppnå sina mål och lösa sina problem.
  • Den är implementerad i välskriven kod som går att jobba vidare med.
  • Vi har testat funktionen så att vi kan göra ett tryggt uttalande om produktkvaliteten.
  • Buggar som vi hittat under testningen har fixats inom ramen för sprinten (”what happens in the sprint stays in the sprint”) och behövs det användardokumentation har vi tagit fram den med.
  • Dessutom har funktionen de kvaliteter som vi förväntar oss av den, när det gäller till exempel snabbhet och säkerhet.
  • Det enda sättet att uppnå Scrums krävande klardefinition sprint efter sprint är att bryta ned arbetet i små fristående delar, och utveckla delarna en i taget.
Målet är att varje sprint ska sluta med potentiellt levererbar produkt.

Potentiellt levererbar betyder att om vi skulle vilja leverera produkten till användarna, så skulle vi kunna göra det. Det betyder inte att vi alltid gör en leverans till användarna efter varje sprint. Ibland väntar vi med leveransen av affärsmässiga skäl. Några sådana skäl kan vara att:
  • Vi vill invänta mer funktionalitet för att produkten ska bli mer komplett
  • Vi inte vill tynga användarna med att lära sig ny funktionalitet för ofta
  • Vi vill synkronisera leveransen med marknadsaktiviteter
I praktiken är det oerhört utmanade att utveckla potentiellt leverbar produkt i varje sprint. Att vara klar i Scrum är kräver ett dubbelt fokus: dels behöver vi samsyn om hur slutmålet ser ut, dels behöver vi samsyn kring hur utvecklingsarbetet ska genomföras. Med andra ord: vi behöver både tydliga krav och en gemensam utvecklingsprocess.

Oklart arbete: kraven
När det är svårt för utvecklingsteamet att verkligen bli klara med något i sprinten kan det tyda på att vi lyfter in krav som inte är redo. I Scrum är ett krav redo när utvecklingsteamet tillsammans med produktägaren bedömer att kravet är möjligt att realisera i sprinten. Det betyder att när vi har ett stort och otydligt projekt att genomföra, så behöver vi bryta ut en liten väl definierad bit och utveckla den i sprinten. Idealet är att varje sprint slutar med att vi demonstrerar faktiskt användbar produkt, något som användaren inte kan vänta på att få lägga vantarna på.

Ett effektivt sätt att bedöma om vi har samma förväntningar på slutresultatet är att fantisera om att vi redan sitter på sprintgenomgången och får en demo av den planerade funktionaliteten. Vi berättar helt enkelt för varandra vad vi tänker oss att vi ser på demonstrationen. De detaljer som kommer upp ser vi till att fånga upp skriftligen (gärna på en whiteboard så att alla kan se). Sedan diskuterar vi tills vi är överens om vad som ska ingå i sprinten, och vad som inte ska ingå.

Oklart arbete: utvecklingsprocessen
En annan stor anledningen till att vi inte blir klara med funktionalitet vi lyfter in i sprinten är att vår utvecklingsprocess ännu inte räcker för att ta oss hela vägen från krav till potentiellt levererbar produkt under en sprint. För att lyckas med detta krävs solida utvecklarpraxis, till exempel:
  • Förmågan att skapa och upprätthålla en design på kodnivå som går att jobba vidare med, utan att vara överdrivet generaliserad
  • Att kunna testa med en kombination av mänsklig och automatiserad testning för att säkerställa att ny funktionalitet fungerar som den ska, samtidigt som vi har koll på att sådant som brukade fungerar inte har gått sönder nu
  • En effektiv bygg- och leveransprocess som är automatiserad så långt som möjligt
  • Fortlöpande integration och testning av hela produkten
  • Gemensamt ansvar för den tekniska kvaliteten, så att vi inte får ”fickor” av hög eller låg kvalitet i produkten baserat på vem i utvecklingsteamet som jobbat med en viss funktion
Framgång med Scrum kräver att vi satsar på att snabbt utveckla såväl vår förmåga att arbeta effektivt med kraven, som vår förmåga att effektivt gå hela vägen från krav till potentiellt levererbar, klar, produkt under sprinten.






25 maj, 2011

Stanna inte efter första etappen

Scrum är ett idealsubstitut. Det är en trevlig modell att sikta mot, men knappast en slutdestination. Grupper som ser på Scrum som slutdestinationen löper större risk, enligt min erfarenhet, att låta förändringen stanna av när man fått till grunderna i Scrum. Man kör sprintar, planerar och följer upp dem tillsammans, och bygger saker och ting som går att demonstrera. Då tar energin för förbättringsarbetet slut, trots att det finns massor av saker kvar att förbättra.

Stanna inte efter den första etappen. Ni kanske behöver ta en paus och sänka förändringstempot lite, om ni är utmattade, men stanna inte helt. Då kommer ni kanske inte igång igen.