Scrumtips - Tips om Scrum!

Vad är en scrum-coach?

2011-12-21T11:15:00.000+01:00

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.

Är vi klara snart, eller?

2011-12-12T23:00:00.000+01:00

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.

Stanna inte efter första etappen

2011-05-25T21:41:00.002+02:00

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.

Certifierad Scrum Master i Västerås

2011-05-16T21:19:00.000+02:00

I höst är mitt mål att genomföra vår oerhört populära kurs "Certifierad Scrum Master" i min gamla hemstad Västerås. Om du är intresserad av att få en plats på kursen, så kan du skicka mig ett meddelande via min profilsida på Citerus.se. På så vis kan jag lägga dig på en intresselista tills dess att anmälningssidan kommer upp.

Så här säger några tidigare kursdeltagare om kursen:

10/10 "Ändra inget. Tobias Fors är entusiasmerande, underhållande och bra på att förklara med målande och tydliga exempel."
-- Jan Bidner, Umeå Universitet/Ladok-enheten, CSM, 5-6 oktober 2010

10/10 "Skönt med mycket interaktivitet, och _inga_ powerpoints!"
-- Marie Ekström, KnowIT Innograte, CSM, 5-6 oktober 2010

9/10 "Tobias var en strålande instruktör/kursledare"
-- Roger Ström, Elvagruppen AB, CSM, 5-6 oktober 2010

10/10 "Bra upplägg, övningar och interaktion"
-- Thomas Ingemarsson, Precio Systemutveckling AB, CSM, 5-6 oktober 2010

10/10 "Bra blandning mellan föreläsning och övningar"
-- Fredrik Nilsson, Logica, CSM, 5-6 oktober 2010

10/10 "Mycket bra och kunnig föreläsare. Bra att slippa ppt!"
-- Martin Håkansson, IEXTAS AB, CSM 2-3 mars 2011

9/10 "Befriande fri från PPT. Kursledaren engagerad och kunnig, inte bara kring det explicita kunskapsområdet. Skön stämning."
-- Johan Estelius, Inceptive AB, CSM 2-3 mars 2011

10/10 "Jag tycker det är bra att man själva får prova på och vara delaktig i kursen. Jag tycker du som kursledare är väldigt pedagogisk och skaffar dig en bra känsla för hur du ska förklara. Bra med egna erfarenheter."
-- Fredrik Stahre, Inceptive AB, CSM 2-3 mars 2011

10/10 "Det mesta var riktigt bra faktiskt. Bra blandning mellan teori och praktik samt en engagerad kursledare som kunde berätta en historia. Kan inte komma på något som borde ha gjorts annorlunda."
-- Krister Arledal, Concrete IT, CSM november 2010

Återblickens grundregel

2010-08-10T21:22:00.002+02:00

En av de svåraste utmaningarna i tider av förändring är att effektiv förändring kräver trygghet. Precis när allt är som osäkrast behöver vi göra som mest för att skapa en situation där alla i organisationen vågar bidra med sina idéer om hur verksamheten kan utvecklas. En artikel i DN om hur anställda på SJ inte vågar kritisera brister, och en om en lokförare som blev uppsagd, fick mig att reflektera över detta.

Oavsett vad som hänt i just detta fall, är det ett faktum att när ledningen bestraffar kritik, så försvinner kritiken ur organisationen. Det kan kännas aldrig så skönt för ledningen, men hur jobbig den än är, så är kritik information om organisationen. Till och med kritik som i sak är helt irrelevant är användbar: den kan till exempel få oss att fundera på varför vi har medarbetare som ger osaklig kritik. Medarbetare som mår bra och trivs ägnar sig inte åt att sprida osaklig kritik. Varför har vi medarbetare som inte mår bra och inte trivs, är frågan som en kompetent ledning då frågar sig.

För den som leder en organisation finns ett problem som glöms bort ibland. Det är väldigt svårt för en högt uppsatt chef att få information om vad som verkligen händer i verksamheten. Självklart får man sina rapporter, sin statistik och sina briefings från den närmast underlydande, men förståelsen för verksamheten och vad som verkligen händer lyser ofta med sin frånvaro. Inte så konstigt egentligen: få vill riskera sin karriär genom att leverera aldrig så viktiga data till en chef som ända bara skjuter ned budbäraren.

I Scrum använder vi, bland annat, genomgångar och återblickar för att samla in data och information om vad som faktiskt händer i verksamheten. Nyckeln till en lyckad återblick stavas trygghet. Grundregeln i retrospektiv är den här:

"Alla gjorde sitt bästa givet förutsättningarna"

En återblick handlar aldrig om att hitta skyldiga, och alltid om att förstå och förändra. Förståelse föregår förändring, och förståelse kan bara uppstå i en situation där alla inblandade på ett tryggt sätt kan förena sina skilda perspektiv till en gemensam bild av vad som verkligen hände och vad som verkligen behöver göras.

Jag brukar rekommendera att varje team som genomför en återblick avslutar den genom att ta två beslut om saker man själva, inom teamet, kan bestämma sig för och genomföra. Jag rekommenderar också att man ger exakt en rekommendation till den omgivande organisationen kring något som, om det gjordes, skulle göra att teamet kunde göra ett ännu bättre jobb. Rekommendationen går vidare till ledningen ovanför teamet, besluten genomförs autonomt av teamet.

Alltså: 2 beslut + 1 rekommendation.

Sitter du i en ledande position? Får du verkligen den information du behöver om verksamheten? Hur vet du det? Vad gör du för att försäkra dig om att du inte bara inbillar dig att du vet vad som verkligen händer?

Böter för sen ankomst = kontraproduktivt

2010-02-14T08:02:00.000+01:00

Staffan Nöteberg, konsult och författare till Pomodoro Technique Illustrated, påpekar på sin blogg att det är kontraproduktivt att införa en "böter" för sen ankomst till det dagliga Scrum-mötet. Själv har jag aldrig använt mig av någon sådan böter, eftersom jag tycker det skulle vara nedlåtande. Jag skulle själv aldrig acceptera att betala något dylikt. Däremot accepterar jag att ta ansvar för och förklara min sena ankomst.

Staffan har en mer vetenskaplig motivation till varför det inte är någon bra idé att ta ut böter: den inre motivatorn att komma i tid för att det är rätt sak att göra trängs ut av den externa motivatorn, att undvika böter.

Jag har hört (kanske från Staffan?) om liknande försök att införa böter för sen lämning på dagis. Resultatet? Föräldrar inser att det bara kostar några tior att lämna barnet lite sent, vilket visar sig vara ett pris man är mer än villig att betala.

Läs Staffans blogg här.

Certifierad Scrum Master, 15-16 februari 2010

2010-02-08T20:20:00.000+01:00

Om en vecka ungefär har du möjlighet att gå på kurs hos mig. På mina kurser ligger fokus på att verkligen förstå Scrum, så att du vet varför man gör som man gör. Om det låter lockande, och du behöver få en injektion av idéer och erfarenheter från mig och resten av klassen, välkommen! 15-16 februari på Freys hotel i centrala Stockholm, ett stenkast från t-centralen.

Anmäl dig till kursen här.

Ken Schwaber om "Scrum But"

2010-02-01T20:18:00.003+01:00

I den här videon berättar Ken Schwaber om vad han menar med "Scrum But"-argument och vad han tycker de tyder på.

Använd förbättringsstories för att effektivisera dina återblickar

2010-01-19T15:28:00.004+01:00

Jag bloggade precis på tobiasfors.se om hur jag använder "improvement stories" för att göra mina återblickar lite mer effektiva. Läs hela inlägget här.

Apropå återblickar: nu på torsdag den 21/1 2010, föreläser jag på Citerus frukostseminarium i centrala Stockholm. Min dragning heter "Effektiva återblickar".

Om du vill börja dagen med en smaskig hotellfrukost och en dos lättrörlighet tycker jag att att du ska ta och anmäla dig. Anmälan gör du här.

Scrum-pub i Uppsala, 8:e oktober, 18.00

2009-09-30T09:21:00.001+02:00

Jag (Tobias Fors) och Henrik Hindbeck har dragit igång ett evenemang i Uppsala som ska bli återkommande. Vi kallar det för Scrum-pub, och är en helt informell träff den andra torsdagen i varje jämn månad. Mer info finns på Scrum User Group-gruppen på Google.

Nästa träff är alltså: 8 oktober klockan 18.00.

Mål: lära sig om Scrum från varandra, byta visitkort, och dricka något tillsammans.
Plats: Pipes of Scotland, Uppsala.
Anmälan: det finns en mailadress du kan anmäla dig på, på Scrum User Group-sidan.
Kostnad: du betalar själv din dryck och mat.
Värde: kontakter och kunskap är ovärdeliga.

Boktips: Wisdom of Teams

2009-09-29T07:07:00.001+02:00

Teamarbete är kärnan i Scrum. Ett effektivt team kan slå världen med häpnad, och är ett team vars medlemmar trivs tillsammans, strävar mot eftersträvansvärda mål tillsammans, och faktiskt når dem.

Min favoritbok om team är Katzenbach och Smiths "The Wisdom of Teams". Den innehåller bland annat en ofta citerad modell för effektiva team, som passar utmärkt för tvärfunktionella utvecklingsteam.

Vad inspirerar ditt tänkande om teamarbete? Om inte en bok, så kanske någon eller något från sportens värld? Vad specifikt är det som inspirerar dig? Låter du inspirationen ge avtryck i ditt arbete med team?

Lider ni av otydligt klarkriterium?

2009-09-28T20:36:00.000+02:00

Har du varit med om följande? Ni samlas för att planera upp en sprint, men kör snabbt fast i en diskussion om hur lång tid saker och ting kommer att ta. Till slut lyckas ni med möda få ihop en plan för sprinten, men när väl sprintgranskningen kommer visar det sig - alldeles för sent - att ni inte alls är överens om att ni är klara. Produktinkrementet har ojämn kvalitet. Några saker är väl testade, andra håller knappt ihop för demo.

Ni kan lida av otydligt klarkriterium. Många gör det.

Vad kan orsaka otydligt klarkriterium? Här är några möjliga orsaker:

Det känns så självklart vad "klart" betyder att det känns onödigt att prata om det
Ni förstår att ett försök att definiera vad klar betyder kommer att visa hur icke-överens ni är, vilket gör att ni skickligt undviker ämnet
Ni har inte sett behovet av att definiera "klar", eftersom ni ännu inte upplevt några problem av att inte ha en gemensam definition

Klarkriteriet hjälper teamet att samarbeta. Utan ett gemensamt klarkriterium kan man egentligen inte veta vilket slutmål man siktar på. Såväl estimering och planering som genomförande blir lidande. Där någon tänker "if it compiles, ship it", tänker en annan sig att automatiserade tester, uppdaterade byggscript och granskning av koden krävs för att en ny funktion ska anses klar. Det blir en källa till konflikter.

Ett kännetecken hos ett effektivt team är att man har en gemensam överenskommelse om hur man arbetar tillsammans. Klarkriteriet är en del av en sådan överenskommelse för effektiva scrumteam.

Är ert klarkriterium tillräckligt tydligt? Samla ditt team och be alla deltagare att, utan att prata med varandra, skriva ned sin definition av "klart" som en punktlista på ett indexkort. När alla är klara, visa korten för varandra och berätta vad ni skrivit? Är era kort ganska lika eller ganska olika? Vad kan ni lära er av de skillnader som finns?

Scrum-guide

2009-08-12T12:36:00.000+02:00

Som en del av Scrum Alliance plan att införa ett flervalsprov som en del av Scrum Master-certifieringen, har Ken Schwaber skrivit ett "officiellt" dokument som beskriver Scrum. Det är en OK sammanfattning, och kan säkert funka bra för den som vill kolla sin egen kunskap om de olika begrepp som definieras i Scrum.

Du kan ladda ned Ken Schwaber's Scrum Guide från Scrum Alliance webbplats.

Skapa ett teamrum

2009-07-04T10:52:00.000+02:00

Jag var scrum master för ett litet team som bestod av ett par utvecklare och en testare. Utvecklarna satt sedan länge bredvid varandra i samma rum, men vår testare satt i ett annat rum med flera andra testare från andra projekt. Jag förklarade för vår testare att jag gärna skulle se att hon flyttade in i samma rum som oss andra. Jag förklarade också att jag absolut inte tänkte tvinga henne, men att jag verkligen trodde att det skulle gynna både henne och teamet. Efter en tids tvekan rullade hon över sin stol och dator till oss andra. När vi några månader senare under ett retrospektiv utvärderade hur olika viktiga faktorer utvecklats kom vi in på frågan om teamsamarbete. Utvecklarna indikerade att situationen förändrats svagt till det positiva sedan jag kom in i projektet. Vår testare gav däremot utvecklingen högsta betyg. Jag frågade vad det berodde på. Hon sa att det framför allt berodde på att hon nu satt tillsammans med utvecklarna. Äntligen, sa hon, kände hon sig riktigt delaktig i utvecklingsarbetet.

Den placering som först användes var att ha utvecklarna på ett ställe och testarna på ett annat. En sån placering återspeglar den organisation som fanns i företaget: funktionellt uppdelad med grupper för utvecklare respektive testare. Det föll sig helt naturligt att sitta var och en på sitt hörn, för att kunna samordna arbetet inom specialistgrupperna.

Scrum kan användas i funktionella organisationer, men bygger på tvärfunktionella team. Dessa team som sätts ihop av specialister från olika funktioner inom företaget, till exempel marknad, R&D och QA. Resultatet blir team som innehåller all kompetens som behövs för att bygga klar produkt varje sprint.

När man jobbar i ett tvärfunktionellt team är ens dagliga samarbetspartners inte bara experter från den egna disciplinen, utan alla de andra teammedlemmarna som kallats in från olika områden. Målet är en frekvent och effektiv kommunikation över expertgränserna, så att vi snabbt kan nå verkliga resultat.

Tvärfunktionella team kan drabbas av en hel del konflikter, vilket är helt naturligt. En orsak är att medlemmarna har helt olika bakgrund och helt olika syn på de problem man brottas med. Innan teamet lärt sig uppskatta och utnyttja dessa skillnader tar de sig uttryck som konflikter.

Om vi vill snabba upp teamets utveckling mot att bli högpresterande är teamrum ett attraktivt alternativ. Att sitta på samma plats är ingen garanti för att man pratar med varandra, men det ökar åtminstone sannolikheten, och att prata med varandra ofta är en förutsättning för att snabbt reda ut konflikter.

Många har dåliga erfarenheter av att sitta i öppna kontorslandskap. Att försöka samlokalisera team behöver inte handla om kontorslandskap. Ett eget teamrum ger teamet möjligheten att jobba tillsammans, samtidigt som man slipper det störande i att sitta i stora öppna landskap. Om kontorslandskap är det bästa som går att få kan man ändå förbättra situationen genom att avgränsa en teamyta med hjälp av skiljeväggar och växter.

Somliga har dåliga erfarenheter av att inte ha sitt eget kontorsrum. Min erfarenhet är att det är mest störande att sitta tillsammans med personer som tillhör andra team. Om man å andra sidan sitter tillsammans med personer i det egna teamet kan man vara säker på att de samtal som uppstår handlar om saker man är intresserad av.

Även om man har ett teamrum kan för mycket prat och avbrott bli kontraproduktivt. Vem som helst kan därför ta initiativ till att sammanställa teamets gemensamma regler för att man ska kunna arbeta effektivt. Syftet med att sitta i samma rum är ju att underlätta kommunikationen, men det måste också finnas en möjlighet att jobba fokuserat ensam.

Väggarna i ett teamrum ska vara användbara. Det betyder minst en eller två whiteboards i rummet, och möjlighet att klistra upp stora blädderblocksark på övriga väggar. Allra minst vill jag ha upp sprintbackloggen, alltså planen för den innevarande iterationen, på väggen. Där vill jag kunna se vilka uppgifter som valts ut från produktbackloggen, och hur de brytits ned i aktiviteter. Jag vill också kunna se vem som jobbar med vad, hur mycket tid som återstår, och en klarkurva (burndown chart).

På väggen vill jag också ha upp aktuella hinder, vilka som ingår i teamet och deras kontaktinformation, tidplaner från resten av organisationen och annat som är viktigt för teamets arbete. Ingen ska behöva leta efter väsentlig information.

På dörren till teamets rum vill jag kunna läsa vilket team som finns i rummet: vad teamet kallar sig och vad man jobbar med. Det kan verka uppenbart för de som deltar i teamet men, särskilt i större organisationer, är det otroligt givande för andra som råkar gå förbi att snabbt kunna se vilka som finns i rummet och vad de gör. Att posta en liten affisch på dörren är ett enkelt sätt för teamet att marknadsföra sig.

Somliga väljer att införa teamrum genom att göra ett kontorsrum tillgängligt för teamet, som teammedlemmarna kan använda om de vill. Alla behåller sina individuella platser, men om man vill sitta tillsammans kan man göra det i teamrummet.

När jag berättar om tanken om teamrum blir somliga provocerade. Så mycket lediga lokaler har man minsann inte på sitt kontor. Så kanske det är, men är inte kostnaden för mer ändamålsenliga lokaler försvarlig om det ökar chansen att projektet lyckas?

De flesta skulle säga att det är värt att satsa på bra lokaler, men sen är det kanske ändå en lokalchef som bestämmer hur det blir i slutänden. Att låta en så viktig framgångsfaktor som teammedlemmarnas lokaler avgöras av någon som inte har ansvar för projektets framgång är en suboptimering som finns i alltför många företag. Som scrum master är ditt jobb att verka för att även lokalerna blir en faktor som hanteras på ett medvetet sätt i era utvecklingsprojekt.

Ny workshop: Effektiva återblickar (1 dag)

2009-03-04T16:55:00.001+01:00

Jag arbetar på en ny workshop för att hjälpa den växande skaran scrumanvändare att växla upp sina återblickar till en ny nivå. Läs mer om endagsworkshopen Effektiva återblickar på Citerus webbplats.

Nästa CSM-kurs: 6-7 maj

2009-02-25T11:26:00.002+01:00

Min nästa öppna kurs Certifierad Scrum Master går av stapeln den 6-7 maj i centrala Stockholm. Det är en lysande möjlighet att fördjupa din förståelse av varför Scrum ser ut som det gör, och hur man gör i praktiken. Jag tror att betygssnittet på kursen under de tre år vi kört den ligger strax under 8 på en 9-gradig skala. Rätt ok!

Sprintbacklog på väggen, produktbacklog elektroniskt

2009-02-25T11:18:00.004+01:00

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 fullo och att dokumentet den ligger i inte är åtkomligt eller redigerbart.

Jag känner inte till något billigare, enklare och effektivare sätt att hantera sprintbackloggen än att sätta upp den på väggen. En whiteboard är bra, men inte alls nödvändigt. Jag har själv kört med en radda upptejpade stora blädderblocksark, och det fungerar nästan lika bra. Rekommenderas för övrigt även om man har en whiteboard - då kan man ju använda whiteboarden till att modellera och problemlösa.

När sprintbackloggen, komplett med utvalda saker från produktbackloggen, aktiviteter, status på aktiviteter och timmar kvar, sprintmål och klarkurva (burndown) sitter på väggen händer flera saker. Först och främst är planen nu synlig för alla som vill se den. Helst sitter den förstås i teamets eget arbetsrum.

Med planen ständigt synlig, och givet att teamet accepterat ansvaret för den, blir det enkelt och naturligt att hålla den uppdaterad. Allt som behövs är en snabb justering av återstående tid på en aktivitet, kanske en lappflytt och en uppdatering av klarkurvan. Några minuter per dag och person. Kostnadseffektivt med andra ord.

Att lagra sprintbackloggen elektroniskt ser jag inte som särskilt intressant. Det som är intressant är vilka saker från produktbackloggen som valts ut för sprinten, och vilka som blivit klara enligt vårt klarkriterium. Den exakta aktivitetsföljden inuti sprinten är teamets jobb. Om vi vill granska om teamet jobbar så effektivt som möjligt kan vi titta på hur mycket faktiska resultat som åstadkoms, kvalitetsnivån och på dokumentationen från sprintåterblickarna.

Produktbackloggen ser jag som mer naturlig att ha i elektroniskt format. Den är ett officiellt dokument som ska vara brett tillgängligt i organisationen, för att sprida förståelse för vad som händer med produkten. Man kan vilja versionshantera den, och definitivt skicka ut den, eller en länk till den, till personer som behöver titta på den.

Det finns en uppsjö av verktyg för hantering av både sprint- och produktbackloggen idag. Mitt tips är att skippa sprintbacklogghanteringen i dem om du inte måste köra även sprintbackloggen elektroniskt (t.ex. om ditt team inte går att samlokalisera, vilket ju är vanligt), och fokusera på hantering av produktbackloggen. Även där är det emellertid värt att komma ihåg en vanlig fallgrop: att man blir kidnappad av verktyget.

Jag har jobbat med flera organisationer som beskrivit sitt verktyg ungefär så här: "Det är bra och så, men det funkar ju inte riktigt som vi vill. T.ex. kan vi inte [fyll i med bra förbättring de skulle vilja göra], men eftersom det inte går gör vi som verktyget föreskriver". Inte så kostnadseffektivt, men lätt hänt. De mer avancerade verktygen stödjer förstås långtgående anpassningar, men kostnaden för den typen av produktanpassning är inte riktigt samma sak som att stuva om i ett Excelark - ett verktyg som ofta bespottas men som är märkligt kraftfullt och dynamiskt.

Mitt tips när det gäller verktyg är därför: börja så enkelt som möjligt (Excel, t.ex.) och jobba så tills antingen a) du inser att det faktiskt räcker, eller b) du har förstått typ av stöd ni behöver så att ni kan fatta kloka beslut om verktygsval och anpassning.

Ifrågasätt Scrum

2009-01-27T21:05:00.004+01:00

Ingen lösning är så bra att den inte orsakar problem för någon. Här kommer dagens hjärngymnastik.

Välj ut en regel från Scrum som du gillar. Kanske väljer du vanan att ha dagliga morgonmöten, kanske något helt annat. Välj den regel du tycker känns mest självklar och mer eller mindre okränkbar.
Skriv ned minst tre, och helst fler, exempel på problem den regel du valt kan orsaka för någon i din organisation.
Om du inte kan hitta minst tre exempel har du inte tänkt tillräckligt länge än, så gå tillbaks till steg två. Annars, reflektera över om regeln fortfarande känns självklar.
Posta gärna dina reflektioner som en kommentar här nedan!

Örebrovändningen

2009-01-27T20:38:00.000+01:00

Hos ett företag som jag arbetade med under en längre tid träffade jag en mycket trevlig örebroare. Han berättade för mig att han i Närkes Allehanda sett en insändare som beklagade sig över gnälligheten i Örebro (härlig ironi, jag vet) och tyckte att man "borde sätta upp en staty av stor rostig spik" i centrum som symbol för denna jobbiga attityd. Några dagar senare kom en motinsändare som hävdade att Örebro inte alls var så gnälligt som påstods, utan att tvärtom Västerås skulle ses som centrum i det så kallade gnällbältet. Jag höll förstås inte med, eftersom jag är uppväxt i Västerås.

Det är sen länge känt att alla som är från Örebro har ett favoritmotto. Detta talesätt som man kan dra fram när en förändring kommer på tal består av tre enkla ord. Kanske hör du dem uttalas på örebromål när du läser dem:

"Det går aldrig".

Sådär till vardags i företag hör man kanske inte orden "det går aldrig" särskilt ofta - men de finns där och lurar. Även om vi inte säger det rakt ut är det svårt att låta bli att tänka dem då och då. Ibland säger vi orden, fast de kommer ut som helt andra ord. Som när vi säger "det tror jag blir svårt". Det låter kanske mildare, men konsekvensen blir ofta densamma - att tysta den som kommit med ett förslag.

Jag har en metod som jag använder ibland för att hjälpa mig själv och andra att arbeta runt "det går aldrig"-reaktionen. Den använder jag för att minska risken att vi räknar ut goda idéer för tidigt.

Nyckeln till att hantera "det går aldrig"-problemet är att komma ihåg att mottot oftast är osant. De flesta idéer vi får på jobbet går faktiskt att realisera, frågan är bara vad de kommer att kosta i tid, pengar och energi. Därför börjar vi med att konvertera mottot till en fråga. Frågan lyder:

Vad skulle det krävas för att det här skulle gå?

Det är svårt att envist fortsätta att hävda att något aldrig skulle gå att göra, samtidigt som någon ställer en uppriktig fråga om vad som skulle krävas för att få detta något att hända. Genom att göra om den instinktiva reaktionen till en datafråga kan vi därför förvandla situationen från en återvändsgränd till något som till och med kan göra oss lite nyfikna. Jobbet som nu ligger framför oss är att försöka skapa en så bra bild som möjligt av vad som skulle krävas för att uppnå det vi önskar oss.

Ibland visar det sig att det vi vill uppnå är så gott som omöjligt, eftersom insatsen skulle vara för hög. Då är det så, och nu vet vi varför. Ibland visar det sig å andra sidan att det hela inte alls var omöjligt, utan genomförbart med en rimlig insats. Då kan vi ta ställning till om vi vill investera i förbättringen baserat på en faktisk analys av problemet, snarare än baserat på ett känslomässigt avfärdande. Oavsett utkomsten har vi lärt oss mer än om vi stoppat processen baserat på vår instinktiva magkänsla.

Populäraste scrumtipsen, januari 2009

2009-01-19T21:41:00.000+01:00

Scrumtipsbloggen fyller ungefär ett halvt år, och följande topp 3-lista räknar upp till det populäraste inlägget hittills.

#3 - Återblickslöshet får Scrum att stanna. Om hur synd det är att så många faller ifrån när det gäller att lära sig genom aktiv reflektion i återblickar i grupp.

#2 - Scrumtips: Både Scrum Master och teammedlem? Om utmaningarna man ställs inför när man kombinerar rollen som stöttande ledare och utvecklare.

Samt (trumvirvel), det populäraste inlägget hittills på Scrumtips:

#1 - Pragmatisk eller dogmatisk? Progmatisk! Om hur man kan göra för att våga göra anpassningar i sitt arbetssätt på ett lite säkrare sätt än att "bara ändra".

Blädderblockstips

2008-12-29T10:41:00.006+01:00

När jag började hålla kurser för använde jag alltid projektor och en enorm hög med presentationsbilder. Idag har jag gått ifrån dessa helt. Jag tycker att de minskar mängden dialog och ökar mängden sömn i rummet. Istället använder jag vanliga blädderblock och illustrerar efter behov. Här är några konkreta tips kring effektiv användning av blädderblock. Användbara på kurser, workshops och arbetsmöten.

Ha alltid en tom punkt redo. När du skriver upp listor med saker som andra deltagare redovisar, se alltid till att avsluta med en extra tom punkt längst ned i listan. Det blir en tydlig signal att fler synpunkter är välkomna.
Växla mellan två färger varannan rad. Om du använder till exempel svart för jämna rader i en lista, och rött för ojämna, så blir det lättare för de som läser att skilja raderna från varandra.
Anlita en tejpnisse. Om någon hjälper dig att tejpa upp fyllda ark på väggen finns du fortfarande tillgänglig för att fortsätta skriva upp bidrag från deltagarna.
Köp supertjocka blädderblockspennor. Vanliga whiteboardpennor är inte lika bra som pennor avsedda för skrift på papper, men om du skaffar papperspennor i samma format som whiteboardpennor är det bara en tidsfråga innan du råkar skriva med dem på en whiteboard. Jag kör därför så ofta jag kan med extra tjocka pennor för blädderblock. Med dem i handen minskar risken att jag tror att jag håller i en whiteboardpenna.
Fotografera som dokumentation. Idag kan vi spara hela blädderblocksarken precis som de såg ut när vi skapat dem, med en billig digitalkamera eller med en kameramobil. Jag brukar fota av bilder med min tremegapixelmobil, och det blir helt ok.
Numrera arken. Om du planerar att dokumentera era blädderblocksblad med digitalkamera är det bra om du har skrivit ett löpnummer i något hörn. På så vis blir det lättare att se i vilken ordning bilderna skapades, vilket kan vara till hjälp när de ska tolkas i efterhand.

Som man mäter får man svar

2008-12-08T18:58:00.007+01:00

Hur mäter man egentligen hur effektiv en verksamhet är? Det är ingen lätt fråga, och många aldrig så välmenta försök har gått snett.

De flesta som utvecklar mjukvara håller idag med om att det inte är så lyckat att använda antal rader kod som ett mått på hur mycket man åstadkommit. Ett team som anses effektivare om de skriver många rader programkod löper stor risk att börja driva mot uppsvälld klipp-och-klistra kod, särskilt om någon skulle få för sig att koppla ett ekonomiskt incitament till modellen.

Vår bransch är inte ensam om att ha problem med att styra med mätmål. Svenska polisen har blivit omskriven för hur fokuset på antalet gjorda utblåsningstest leder till att man maximerar antalet test, men minimerar antalet stoppade rattfyllerister.

Risken när man väljer att mäta, följa upp och belöna en specifik sak är alltså att man får precis det man ber om: ett totalt fokus på den och bara den saken.

Dagens scrumtips är därför: var försiktig med vad du mäter, du kan få det.

Dialog, inte diskussion

2008-10-27T18:46:00.009+01:00

Dagens scrumtips är ett boktips: Dialogen och konsten att tänka tillsammans, av William Isaacs, översatt till svenska år 2000 av Bookhouse Publishing AB.

Scrum handlar om lärande, alltså om att bygga ny kunskap och ny kapacitet. Vi har tvärfunktionella team för att belysa de komplexa problem vi arbetar med ur så många perspektiv som möjligt. Varje person som bidrar med ett nytt perspektiv tillför fler kontrollerbara variabler, alltså saker vi kan justera för att hitta en lösning på problemet.

Styrkan med ett tvärfunktionellt team är dess förmåga att hitta lösningar som ett team av specialister från samma disciplin helt enkelt inte kan nå, eftersom de inte kan manipulera alla de variabler som behöver manipuleras för att lösning ska kunna uppstå.

Ett team som inser detta samtalar med varandra för att förstå varandras perspektiv. Man accepterar att alla bidrar med sin del av lösningen och att det enda sättet att lösa hela problemet är att lära sig se det i sin helhet.

Denna typ av utforskande samtal kallas dialog. Motsatsen till dialogen är diskussionen eller debatten. Få saker är så energikrävande som en diskussion mellan personer som alla är övertygade om att de sitter på den enda sanningen. Få saker är så energigivande som en dialog där alla deltagares perspektiv uppskattas och utnyttjas.

Hur ser era arbetsmöten ut? Diskuterar ni, eller för ni en dialog? Hur funkar det för er?

Rätt arbetsmängd är avgörande

2008-09-20T20:43:00.003+02:00

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.

Vad sprintplanering och glassinköp har gemensamt

2008-09-07T16:03:00.006+02:00

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.

Proxy-produktägare förtar effekten

2008-08-30T14:50:00.000+02:00

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 och uppföljning, samtidigt som man inte utmanar den etablerade beslutsrätten hos den faktiska produktägaren.

Tyvärr leder strategin till ett problem som går på tvärs med en av Scrums grundtankar, som är att produktägaren och teamet ska ha ett direkt samarbete. Scrum är baserat på granskning och anpassning. Den som beställer produkten ska regelbundet granska den, för att kunna anpassa utvecklingen fortlöpande. Den som utvecklar produkten ska alltid ha tillgång till den som beställer. Målet med Scrum är att få till ett så effektivt samarbete mellan beställare och utförare som möjligt, alltså ett direkt samarbete mellan produktägaren och utvecklingsteamet.

När den faktiska produktägaren kliver åt sidan, och granskningen och anpassningen sköts av en proxy-produktägare, tappar den faktiska produktägaren insynen i arbetet. Utan insyn finns ingen möjlighet till granskning, och därmed ingen möjlighet till anpassningar baserade på faktiska observationer.

Det kan ta ett tag innan de negativa effekterna blir allmänt kända. Den faktiska produktägaren kliver in när en ny levarans planeras upp, och kommer tillbaks mot slutet av utvecklingstiden. Det är först då effekten av att inte ha en riktigt delaktig produktägare blir uppenbar. Produktägaren visar sig nu inte vara insatt i vad som hänt under de sprintar som lett upp till den senaste produktversionen, och blir med största sannolikhet överraskad över resultatet. Men vid det laget kan inte utvecklingsteamet längre med lätthet agera på feedback på produkten.

Hur kan man göra istället?

Jag tror att många som verkar i rollen som ansvariga för produkter och system gladeligen skulle kliva in i rollen som produktägare, om de bara visste vad som förväntas av dem, och vilken nytta de kan förvänta sig tillbaks. Det är Scrum Masterns jobb att hjälpa dem att förstå detta.

Om produktägaren har problem att interagera med teamet på daglig basis, pröva att låta den person som skulle tagit proxy-rollen kliva in i teamet som domänexpert. Då får den personen tillsammans med teamet göra åtaganden mot sprintmålen, och teamet har daglig tillgång till djup kompetens om problemdomänen. Den faktiske produktägaren kan nu samarbeta med teamet kring krav på hög nivå, alltså med en produktbacklog som har rätt abstraktionsnivå, medan teamet har den domänkompetens som behövs för att lösa detaljfrågorna.

Sprid kunskaperna i teamet

2008-08-21T18:39:00.000+02:00

Efter att ha läst om arbetsgrupper där medlemmarna jobbar lite för separerat från varandra för dra nytta av ett teams sanna potential frågar en anonym läsare:

"Det vore intressant att läsa lite tips på hur man når dit. Om man nu är en grupp där man är lite för specialiserade. Vad gör man för att sprida kunskaperna på ett bra sätt?"

Här är några handfasta tekniker som gör att kunskap i ett mjukvaruutvecklingsteam sprids. Men först lite kort om själva förändringen i sig.

Grunden i all förändring är att behovet av förändring är känt. Så, om inte alla i teamet känner till att och varför det är en bra idé att jobba tajtare tillsammans måste ni prata om det. Hur skulle ni veta om ni jobbade bättre tillsammans? Vilka faktiska aktiviteter skulle ni göra? Hur skulle det kännas? På vilket sätt skulle resultatet bli bättre? Vilka nackdeler skulle ni se? Hur skulle ni hantera dem?

Så, några konkreta saker ni kan göra.

Planera aldrig ensam. Klyschan är sann: planen är inget, planeringen är allt. Ett team planerar sitt arbete tillsammans dels för att skapa en bättre plan, dels för att man genom att samarbeta med planeringen ökar sannolikheten att planen kommer att efterlevas. Tänk efter. Vilken plan är du själv mest benägen att följa - den som du fått släppt i knät, eller den du själv varit med att utforma. Tänk också på detta: vilken plan tror du att du bäst förstår - den någon annan gjort, eller den du själv är medskapare till? Du vet svaren. Av dessa anledningar deltar hela teamet och produktägaren aktivt i såväl releaseplanerings- som sprintplanerings-workshops. Scrum-team är små, så hela teamet arbetar tillsammans under planeringen. Att dela upp sig i mindre grupper under planeringen är kontraproduktivt. Visst kan planering vara över snabbare, men till priset av fragmenterade bilder av helheten.
Använd visuell styrning. Visuell styrning handlar om att få upp planen på väggen, så att den blir extremt synlig och extremt lättillgänglig. Sprintbackloggen är en självklar kandidat för visuell styrning. Istället för ett Excelblad eller tjusigt webbverktyg sätter man upp de utvalda behoven från produktbackloggen på väggen, tillsammans med de aktiviter som behöver genomföras för att implementera dem. Delar man sedan upp tavlan med linjer i block som visar mängden aktiviteter som väntar, är påbörjade, respektive avslutade så får teamet en direkt inblick i om man arbetar effektivt tillsammans för att göra klart värdefulla funktioner, eller om flaskhalsar och isolerat arbete leder till att uppgifter blir gjorda men inga resultat nås.
Gemensamma designmöten. Sprintplanering, dagligt möte och sprintuppföljning är inte de enda tillåtna mötena i Scrum. Teamet bokar in alla möten de behöver för att arbeta effektivt tillsammans. Gör de det inte tar Scrum Mastern täten och förklarar varför gemensamma arbetsmöten är en smart grej att göra. Under ett gemensamt designmöte träffas en del av eller hela teamet för att arbeta med detaljplaneringen av något moment i sprinten. Självklart kör man även designmöten tvärfunktionellt, så att lösningen kan belysas från såväl programmerarnas, testernas och andras perspektiv.
Gemensamma granskningsmöten. Alla har nytta av att få ett eller flera par fräscha ögon som granskar ens arbetsresultat. Det behöver inte vara av någon från samma disciplin som en själv, tvärtom är det ofta nyttigt att försöka förklara vad man gjort och hur man tänkt för någon som inte är drabbad av samma bakgrund som en själv.
Parprogrammering. Inte direkt älskat av alla, om man ska uttrycka det milt, men vansinnigt effektivt när det väl tillämpas av personer som tror på värdet av att skriva kod tillsammans. Effekten är omedelbar: delad kunskap inte bara om hur koden fungerar, utan också om varför den ser ut som den gör.
Hjälp experter bli rådgivare. Även effektiva team kan kidnappas av en specialist. Det händer när en nischkompetens finns hos endast en eller två personer i teamet, och allt arbete inom det området måste gå genom experterna. Om dessa personer blir en flaskhals begränsas teamets resultat av hur mycket denna trånga sektor kan släppa igenom. Genom att hjälpa dessa personer att dels sprida sin kunskap, dels förklara för andra hur de kan jobba för att underlätta för experten kan effektiviteten i teamet öka.
Hjälps åt under demon. Under sprintuppföljningens första del, demon, turas teammedlemmarna om att demonstrera en sak som implementeras under sprinten. Övriga antecknar synpunkter från åhörarna under tiden.
Återblickar varje sprint. Ett team som har svårt att arbeta tillsammans, och finner sig glida isär i två eller fler faktiska delgrupper, eller kanske bara har individuellt arbete, lägger extra fokus på denna fråga under sprintåterblicken. Som ett minimum pratar man om problemet, och det räcker med att någon tycker att situationen hämmar teamet för att det ska vara ett problem. Kan man försöker man vrida och vända på problemet för att hitta något man kan göra för att få teamet att smälta ihop mer effektivt.

OK. Det var några handfasta tips att pröva om man finner sig i en arbetsgrupp som vill jobba mer samspelt tillsammans, som ett riktigt team. Det är också en lista som visar varför Scrum Master-rollen inte är en lätt syssla. Inget av tipsen i listan ovan är rocket science, likväl görs de ofta inte. Att förstå varför inte, och justera saker och ting så att de börjar hända är Scrum Masterns ansvar. Det betyder inte att det är förbjudet för andra att ta sig an dem - tvärtom. Ett av kännetecknen hos ett fungerande team är att det är ok för vem som helst att kliva fram och ta ansvar för förbättringar.

Sega möten: ett tecken på djupare problem

2008-08-15T14:27:00.002+02:00

Som en kommentar till det jag skrev om motstånd mot dagliga morgonmöten i "Pragmatisk eller dogmatisk? Progmatisk!", skriver Magnus Ljadas:

"En anledning till motstånd till morgonmöten, enligt min erfarenhet, kan vara att arbetet i projektet bedrivs väldigt specialiserat. Jag gör bara sånt som har med utskrifter att göra; du sysslar bara med webbformulär; och ingen av oss rör någonsin nånting som har med databasen att göra, för det är Staffans baby. Vi har liksom väldigt få naturliga beröringspunkter.

Stor fråga kanske, men hur tar man sig ur/bryter en sån situation?"

Verkligen en stor fråga, men vi prövar ett sätt att närma sig den.

En bra teknik är att utgå från att människor vars beteende man inte håller med om eller förstår sig på faktiskt beter sig så rationellt som möjligt, men självklart med utgångspunkt från deras egna aktuella modeller av hur verkligheten fungerar.

Tänker man så kan man i det här fallet fråga sig vilken modell av verkligheten man behöver ha för att tycka att det mest rationella är att dela upp arbetet så strikt mellan sig som personerna i gruppen Magnus beskriver gör?

Kanske tänker de att något eller några av följande argument är sanna.

a) Om man delar upp arbetet i strikta delar, med tydliga ansvarsområden, får man möjlighet att specialisera sig i en modul eller teknik, och då blir det lättare att verkligen lära sig den på djupet.

b) Man undviker konflikter när man råkar göra mindre bra ändringar i varandras kod och dokument, eftersom man bara gör ändringar i sina egna grejor.

c) Man vet vem man ska gå till när något går fel i en viss del.

d) Man slipper kommunicera med varandra hela tiden, så man kan jobba fokuserat på sina saker lättare.

e) En karriär byggs bäst på ett smalt expertområde. Att dela med sig av sin kunskap är att minska sina möjigheter att bli expert, och därmed att göra karriär.

f) Om man gör sin del som man ska har man gjort ett bra jobb och kan vara nöjd med sin insats.

För att gruppen ska vilja jobba mer tajt tillsammans behöver de byta ut sin nuvarande mentala modell av vad som är rationellt mot en alternativ modell.

En alternativ modell av verkligheten skulle kunna se ut så här.

a) Det är bra att ha mer eller mindre inblick i alla delar av systemet, så att man kan samarbeta lättare i teamet, och kanske till och med hoppa in och göra ändringar i fler delar än bara en enda som man specialiserat sig på. Det minskar risken vid till exempel sjukdom och ledighet, och är särskilt skönt när man själv är den som vill vara ledig.

b) Man undviker konflikter bättre om man är överens om att man har gemensamt ansvar för hela produktens kvalitet. Det är allas fel om det finns en defekt i systemet.

c) Det går snabbt att lösa problem om mer än en person behärskar en given del av produkten.

d) Man kommunicerar effektivare med varandra när man har bättre inblick i fler delar av systemet, eftersom det blir färre missförstånd.

e) En karriär byggs bäst på att ha deltagit i team som levererat lysande resultat, och på de relationer med nya personer i och utanför teamet som man därmed byggt upp.

f) Om man bygger en bra produkt tillsammans, som kunden och användarna gillar, då har man gjort ett bra jobb och kan känna sig nöjd.

En grupp som betraktar världen genom den alternativa modellen kommer att välja att jobba nära varandra. För den gruppen kommer morgonmöten att kännas användbara, eller, om de är verkligt effektiva, kanske till och med lite överflödiga.

Vad kan få en individ eller grupp att byta ut vad man tycker är en fungerande modell mot en helt ny?

Tja, en anledning kan vara att man en dag förväntas arbete i ett team som medvetet satts samman för att vara tvärfunktionellt, med uppdraget att bygga värdefull, testad och dokumenterad mjukvara var trettionde dag. Scrum sätter på detta sätt upp ramar som ska stötta teamet att själva upptäcka värdet av nära samarbete. Ibland händer det som av sig självt, ibland inte, därav Scrum Masterns ansvar att hjälpa andra förstå och lyckas med Scrum.

Pragmatisk eller dogmatisk? Progmatisk!

2008-08-13T19:25:00.003+02:00

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 vi inte ändringar utan att först ha reflekterat över om vi verkligen förstår konsekvenserna av de ändringar vi gör.

Ett exempel förtydligar.

Mats är Scrum Master för ett Scrumteam. Teamet är ganska litet, bara fem personer. Två personer som mest programmerar, men även hjälper till med test, två personer som mest testar, dels explorativt, dels med automatiserade testverktyg, och en domänexpert.

Sedan man började med dagliga statusmöten tycker Mats att han fått en mycket bättre insyn i projektet, men hans kollegor är inte lika nöjda. Alla teammedlemmarna är överens om att det skulle räcka med morgonmöten måndagar, onsdagar och fredagar. Mats har presenterat de argument han tycker talar för ett dagligt möte (det blir kortare, information sprids snabbare med mera), men han lyckas inte övertyga teamet. Mats sätter sig med teamet en halvtimme för att bestämma hur de ska göra.

Mats börjar med att gå igenom syftet med morgonmötet igen. Det visar sig att alla är överens om att man vill ha daglig koll på läget i projektet. Alla är också överens om att man ska uppdatera planeringsväggen varje dag, så att alla har en bra bild av vad som händer.

Teamet presenterar sina argument mot ett dagligt möte. Det här är inte första gången man jobbar tillsammans. Samtliga är seniora utvecklare, och gruppen har en effektiv dynamik. Man sitter tillsammans i ett stort rum, med egna avgränsade platser så att man får avskiljdhet, men så nära att man lätt kan byta information med varandra och fånga upp vad som händer. Teamet menar att man sedan länge har lärt sig att kommunicera frekvent om mål, uppgifter och hinder, och deras track record visar att det inte bara är prat.

Tillsammans bestämmer Mats och teamet sig för att vara progmatiska. Man har förstått värdet i ständig insyn i projektets status och kontinuerligt utbyte av information i teamet. Man tycker att ett dagligt möte utöver den fungerande och mogna kommunikation man redan har känns märkligt, som något man skulle göra "bara för att metoden säger det", och den känslan är man överens om är demotiverande. Man köper helt enkelt inte att en paketerad arbetsmetod skulle veta bättre än deras samlade erfarna omdöme.

Teamet och Mats beslutar att pröva att ha scrum-möten tre gånger per vecka under några sprintar framöver. Mats gör en notis i sin Scrum Master-dagbok. Först skriver han ned datumet, sen skriver han ned vilket beslut de tagit, varför, och vilket resultat de förväntar sig av det. Sist skriver han ned när han ska följa upp om det blev som de tänkte sig. Sen känner han sig helt nöjd med utkomsten. En av tankarna med Scrum var ju trots allt självorganiserande team, tänker han, medan han tillsammans med sina kollegor städar undan kaffekopparna från det gemensamma arbetsbordet i teamrummet.

Både Scrum Master och teammedlem?

2008-08-02T10:34:00.003+02:00

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 utmaningar. När ett projekt får upp farten kavlar folk upp ärmarna och kör så det ryker. Finns en deadline runt hörnet ökar trycket ännu mer.

Utvecklingsteamet i Scrum har som uppgift att arbeta tillsammans för att bygga produkten. De kommer att vara under tryck från både sig själva och omgivningen att få mycket gjort på kort tid. Produktägarens ansvar är att göra produkten till en framgång. Framgången hänger på att rätt funktionalitet kommer ut i rätt tid, till rätt kostnad. Både teamet och produktägaren kommer med andra ord att känna det fulla trycket av ett utmanande projekt.

Scrum Mastern är också med i matchen, men från ett lite annat perspektiv. På ett sätt kan man säga att Scrum Masterns jobb är att behålla ett nyttigt lugn när alla andra blir galna. Scrum Masterns roll är att hjälpa alla andra att uppnå sina mål med hjälp av Scrum. I den mån andra beter sig kontraproduktivt är det Scrum Masterns jobb att belysa detta på ett sätt som gör att en beteendeförändring kommer till stånd.

Genom att redan från början identifiera Scrum Master-rollen som separat från utvecklingsteamet och produktägaren kan vi i någon mån redan från början vara överens om att det är någons explicita ansvar att backa ett par steg när börjar gå undan, och betrakta situationen från en viss distans.

Så: kan man vara både Scrum Master och teammedlem på samma gång? Självklart, men här är några av konsekvenserna:

När organisationen som mest behöver någon som lugnt och rationellt kan observera en kaotisk situation, och styra mot en anpassning - en Scrum Master - är den personen med stor sannolikhet precis som alla andra upptagen med att släcka bränder.
Även om tempot i projektet för tillfället är lugnt och produktivt finns det alltid långsiktiga utmaningar att jobba med. Min erfarenhet är att det är lätt att försaka en av de roller man tagit på sig, av gammal ohejdad vana. En utvecklare som också är Scrum Master är förmodligen mer benägen att göra ett testskott på en ny intressant teknik, än att gå till företagets lokalchef och diskutera möjligheten att förbättra kontorslayouten.
Att växla mellan två uppgifter betyder inte att man kan lägga femtio procent av tiden på respektive uppgift. En del tid, ofta mer än man tror, går åt till att växla mellan och koordinera de olika uppgifterna.

Är det då alltid en dålig idé att vara både teammedlem och Scrum Master? Nej, jag vill inte vara så kategorisk. I några situationer har jag sett det fungera alldeles utmärkt. Det har varit i organisationer där ledningen gett sitt fulla stöd åt användningen av Scrum, och därför aktivt hjälpt teamet på alla sätt och vis. I den situationen är trycket mindre på Scrum Mastern att jobba med lång- och kortsiktig hindereliminering, och därför har en person kunnat bära både Scrum Masterns och teammedlemmens hattar.

Återblickslöshet får Scrum att stanna

2008-07-27T23:12:00.000+02:00

Jag höll en tvådagars Certifierad Scrum Master-kurs åt ett större svenskt tjänsteföretag. Flera i gruppen var särskilt intresserade av större projekt, eftersom man jobbade tillsammans i ett sådant, och inte verkade helt nöjda med hur det gick. Jag berättade så gott jag kunde om mina erfarenheter av att använda Scrum för samordning av arbete i flera team och med flera samtidiga produkter, men jag märkte att mina svar inte var särskilt tillfredsställande.

För att få mer information om vad som egentligen eftersöktes vände jag på steken, och kastade ut en motfråga: vad pratade ni om på återblicken i er senaste sprint?

Svaret blev undvikande. Man hade inte haft någon återblick i den senaste sprinten. Jag modifierade frågan en smula: vad brukar ni prata om på era återblickar?

Nu blev svaret nästan lite skamset. Man hade aldrig haft en återblick i projektet. Definitivt inget de borde skämmas för, men lika säkert något de skulle kunna dra mycket nytta av att ändra på.

Scrum är inte bara ett arbetssätt, det är också ett ställningstagande. Med Scrum tar vi ställning för åsikten att den kompetens som behövs för att lösa våra organisationers problem finns ute i organisationen, hos alla oss som tillsammans gör jobbet, och vår gemensamma uppgift är att dra så mycket nytta av vår kollektiva kunskap som vi bara kan. Scrum är utformat för ge återkommande möjligheter att stanna upp, försöka förstå problem och formulera lösningar till dem.

Scrum Master, produktägare, team och andra kan förstås eliminera problem när som helst, men det extra stöd Scrum ger oss är återblicken. Återblicken är ett fokuserat moment i arbetet som återkommer sist i varje sprint. Under återblicken tittar vi tillbaks på arbetet, försöker förstå vad som hänt, och beslutar om justeringar framåt, så att vi ska bli mer effektiva och mer nöjda nästa sprint. Genom att göra återblicken till en inbyggd del i arbetsrutinen vill minska risken att vi hoppar över den. Det ska vara naturligt att stanna upp en stund i slutet av varje sprint och granska såväl produkt som utvecklingsprocess, och planera förbättringar av båda.

Återblicken är för Scrum vad bensin är för en bil: nödvändig för framfarten.

Att ta bort återblickarna ur Scrum och sedan undra varför man inte lyckas lösa sina problem visar på ett tydligt problem som måste lösas före alla andra: först måste förståelsen för Scrum som lärandemetod finnas. Innan den finns kommer vi att fortsätta leta efter färdigpaketerade lösningar till våra unika problem istället för att utnyttja idéerna som redan finns i vår egen organisation.

Alla måste inte kunna allt

2008-07-26T22:26:00.000+02:00

"Tvärfunktionella team låter så bra, men i vårt företag är det inte så enkelt. I Scrums utvecklingsteam förväntas ju alla kunna göra allt, men våra utvecklare är inte vana testare, och våra testare kan inte programmera. Hur ska vi kunna använda Scrum?"

Idéen om tvärfunktionella team kan vara provocerande. Personer från helt olika discipliner ska plötsligt arbeta tillsammans på daglig basis för att bygga en produkt av hög kvalitet. Få av oss har förstås varit helt skyddade från kontakter med personer från andra specialiteter, men oftast kanske kontakten har skett vid mer eller mindre formella "överlämningstillfällen". Fasbaserade utvecklingsmodeller går ju ut på att varje funktion i företaget gör sin del så noggrant som möjligt, för att vid en given tidpunkt kunna lämna över sitt arbetsresultat till nästa funktion i företaget, ungefär som de tävlande i ett stafettlopp springer var sin sträcka så fort som möjligt, och gör en tydlig överlämning till näste löpare.

I Scrum springer vi inte stafett, vi spelar rugby. Vi arbetar med små team som bygger kompletta inkrement av högkvalitativ produkt, i (typiskt) månadslånga iterationer. För att varje iterations arbete ska kunna resultera i produkt av tillräckligt hög kvalitet vill vi ha ett team som innehåller all den kompetens som behövs för att bygga klar produkt. I mjukvaruutveckling betyder det att vi vill ha testare, programmare, domänexperter, och ofta andra typer av specialister, med i teamet. Detta kallar vi ett tvärfunktionellt team, eftersom personerna ofta kommer från olika funktioner, eller avdelningar, inom ett företag.

Vi brukar säga att medlemmarna i ett scrumteam inte har några roller. Det har de förstås, om inte kring specialiteter så kring vem som leder gruppen vid vilket tillfälle, vem som är gruppens talman och vem som är den tystlåtne strategen, och så vidare. Men, det vi som lär ut Scrum menar med att scrumteam inte har några roller är att vi lägger större tonvikt på att teamet fungerar som helhet än på att upprätthålla gränserna mellan traditionella specialistroller. I varje väl fungerande team hjälper nämligen medlemmarna varandra att uppnå teamets mål, även om det betyder att man får sträcka sig utanför sitt specialistområde eller sin personliga komfortzon för en stund. En för alla, alla för en.

När man går in i ett scrumteam tar man alltså av sig experthatten, och sätter på sig teamhatten. Det betyder emellertid inte att alla i teamet ska kunna göra allting lika bra. Produktutveckling är komplicerat arbete, och vi behöver specialister för att lyckas - men vi behöver specialister som kan samarbeta.

Visst vore det underbart om "alla kunde göra allt", men tills den drömmen blir sann är det samarbetsförmåga som är den viktigare nyckelkompetensen för medlemmar i ett Scrumteam.

God utvecklarpraxis är en del av Scrum

2008-07-21T22:27:00.011+02:00

En vanlig missuppfattning, och ibland en källa till dispyt mellan Scrum- och XP-anhängare, är att Scrum inte lägger någon vikt vid god utvecklarpraxis. I XP är det ju så tydligt: parprogrammering, kontinuerliga byggen, enhetstestning eller till och med att man driver programmerandet med testfall. Scrum tycks lite fattigt i jämförelse, här finns ju inga tvingande regler om hur man ska göra på detaljnivå.

Att Scrum inte beskriver hur utvecklingsteamet ska göra sitt jobb är inget misstag. Scrum utelämnar detaljerna, eftersom de beror på sammanhanget. Parprogrammering är till exempel en lysande idé, om inte användningen i ett givet fall resulterar i så mycket konflikter att det hela kostar mer än det smakar.

Scrum är ett ramverk, en tom struktur vars detaljer behöver fyllas i av användaren. Tack vare detta kan vi lätt förklara essensen i Scrum för nya användare, och dessa kan själva fylla i med det som behövs i deras specifika situationer. En sidoeffekt av detta är att den som inte vet vad som behöver fyllas i står sig rätt slätt.

Avvägningen står alltså, i ytterligheterna, mellan att göra en mer utförlig projektmetod som beskriver exakt vad som ska göras i varje givet fall, och att göra ett enklare ramverk som bara beskriver den övergripande strukturen och överlåter till användaren att fylla i detaljerna.

Scrum går alltså på den senare linjen. Rationals Unified Process är ett exempel på den förra, och här ser vi också riskerna med den mer utförliga approachen. Trots, eller snarare på grund av, att RUP innehåller sida upp och sida ned med bra information om mjukvaruutveckling så blir metoden oöverblickbar. Många som använder RUP har helt missat att det är en iterativ och inkrementell arbetsmetod, kanske för att man redan spenderat all sin uppmärksamhet på alla detaljer.

Även om Scrum inte beskriver detaljerna krävs det alltså att vi själva kan fylla i dem. De flesta som är insatta i lättrörlig utveckling kan nog skriva under på att seriös enhetstestning, kontinuerliga designförbättringar och frekvent integration är tekniker som man inte vill vara utan om man vill lyckas med att utveckla iterativt, inkrementellt och lättrörligt.

Redan när jag lärde mig om Scrum från Ken Schwaber 2003 tryckte han på vikten av god utvecklarpraxis. Vi frågade till exempel vad man gör om man märker att organisationen saknar tillräckliga rutiner för konfigurationshantering. Kens svar: sätt in det som hög prioritet på produktbackloggen.

Filosofen Voltaire får avsluta, för han har redan beskrivit vad det handlar om så bra som man kan hoppas göra:

"What harm can a book do that costs a hundred crowns?

Twenty volumes folio will never cause a revolution;

it is the little portable volumes of thirty sous that are to be feared."

Myers-Briggs Type Indicator

2008-07-20T13:20:00.007+02:00

MBTI, eller Myers-Briggs Type Indicator är ett system för att identifiera sina personliga preferenser, till exempel för att se om man lättare får ny energi från att interagera med andra, eller om man bättre tankar batterierna genom tyst reflektion på egen hand.

Varför skulle en Scrumanvändare vilja göra en sådan kartläggning? Dels för att man lär sig om sig själv, och självkännedom är aldrig dumt. Dels för att det gör interaktionen med personer som har andra preferenser mer begriplig, och därmed mer hanterlig. Båda dessa perspektiv är nyttiga för den som gillar Scrum.

Praktisk nytta är ledordet här. Min första reaktion när jag hörde om MBTI var minst sagt skeptisk. Jag är ingen stor favorit av att sortera in människor i kategorier. Det var först när jag fick lära mig mer om MBTI på AYE-konferensen som nyttan började sjunka in. Steve och Don som förklarade grunderna var noga med att förklara att ens MBTI-typ inte är någon livstidsdom eller ödesbeskrivning, utan en bild av vilka preferenser man har. Att man har vissa preferenser betyder som bekant inte att man inte kan bete sig på ett helt annat sätt i praktiken. Det preferenserna lär oss är däremot vilken typ av beteenden som ligger närmast till hands för oss. Att agera utanför våra preferenser kräver mer ansträngning från oss.

Som vid all förändring är första steget för att dra nytta av MBTI att börja med sig själv. Man kan göra mer djupgående eller enklare typer av MBTI-analyser. Jag har vid två tillfällen gjort varianter av en enklare analys, som båda landade i samma resultat. (ENTP, om någon är intresserad, men ett svagt E, mitt på gränsen mellan extrovert och introvert).

Även om skeptikern i mig känner en viss lukt av horoskop kring MBTI och de många varianter av personlighetsanalyser som finns på marknaden, så tycker jag att verktygen är användbara, eftersom analysen ofta verkar resultera i att de som gör den börjar reflektera över vilka deras preferenser egentligen är, vilket i sin tur leder till en förståelse för människors olikheter. Den typen av förståelse är precis vad ett team behöver för att bli riktigt effektiva.

Jag tror att de mest effektiva teamen är komponerade av människor med varierande preferenser, som är helt medvetna om sina skillander - så att man aktivt kan dra nytta av dem. Man kompletterar varandra på ett sätt som gör att teamet som helhet blir mer heltäckande.

Videotips: Ken Schwaber på Google i september 2006

2008-07-20T09:48:00.001+02:00

Ken Schwaber är den enskilda person som gjort mest för att sprida Scrum globalt. Han är en skicklig berättare och pedagog, och definitivt värd att lyssna på, som i den här videon där han talar i Googles TechTalk-serie i september 2006.

Tyst brainstorming

2008-07-19T23:00:00.000+02:00

Brainstorming är ett fascinerande koncept. Tanken är att en grupp tillsammans arbetar för att producera så många idéer som möjligt på ett tema. För att inte störa den kreativa processen finns en viktig förhållningsregel. Ingen kritik av idéer. Kritiken kommer senare. Min erfarenhet är att det är svårt att låta bli att kritisera under brainstormingen.

Möjligtvis, och jag skriver möjligtvis, kan det för personer med en extrovert läggning vara lättare att hantera kritik under brainstormingen. Är man bekväm med att tänka och prata samtidigt så är man förmodligen mer immun mot att folk avbryter och kritiserar under brainstormingen.

För personer med en mer introvert preferens kan utmaningen vara större. För det första kan brainstormingen i sig själv vara knepig för den som helst tänker för sig själv först, och sedan delar med sig av sina tankar. För det andra blir det inte bättre när någon avbryter den introverte, som äntligen uppmanat kraften att bidra med några idéer inför hela gruppen.

För att få en bättre balans mellan att tillfredsställa behoven hos personer med extrovert och introvert preferens brukar jag använda mig av tyst brainstorming.

I en tyst brainstorming får deltagarna under en känd tid tyst och på egen hand brainstorma idéer. Varje deltagare skriver själv ned sina idéer i en lista, eller direkt på post-its. När tiden är slut presenterar deltagarna sina idéer för varandra - använder man post-its klistrar man upp dem på till exempel en gemensam blädderblockslapp eller whiteboard. Behövs det kan man köra fler rundor på samma sätt.

Tyst brainstorming hjälper personer med introvert preferens att fokusera och förbereda sig under det tysta momentet, medan personer med extrovert preferens fortfarande har tillgång till den gemensamma presentationen och dialogen.

Effektiv användning av papper och penna

2008-07-19T16:29:00.014+02:00

Jag har svurit ett heligt löfte att aldrig igen delta i ett arbetsmöte där någon stackare sitter och försöker skriva in det som sägs i ett Excelblad som projiceras på väggen. Det går vansinnigt långsamt, och hela gruppdynamiken förändras från dialog till något helt annat - något styltigt, okreativt och tråkigt. Så, tills dess att någon byggt en elektronisk whiteboard som är lika effektiv för samarbete som gamla goda analoga verktyg, så kommer Scrum för mig att vara synonymt med whiteboards, blädderblock och post-its.

Det finns en hel del praktiska saker, billiga och kraftfulla, som gör arbetet med papper och penna mer effektivt. Är du Scrum Master kan du ta täten för att hjälpa övriga att lära sig detta.

Skaffa rätt sorts pennor. De flesta konferensrum är laddade med whiteboardpennor samt bläck- eller blyertspennor. Inga av dessa är effektiva för saker som ska upp på väggen så att alla kan se dem. Tunna pennor ger för tunn och svårläst text. Whiteboardpennor resulterar i uppsvällda hopflytande tecken. Lösningen: köp mellantjocka pennor. Så enkelt, och så effektivt. Med rätt pennor kan fler läsa vad som faktiskt står på lapparna vi sätter upp, och dessutom - och detta är en grymt viktig bonus - dessutom går det bättre att se vad det står när man fotar av sitt arbete vid dagens slut.
Texta stort och tydligt. Kan tyckas självklart, men de flesta av oss är mer vana att skriva i miniatyrskrivstil för oss själva på ett papper än med stora tydliga tecken på post-its som ska kunna läsas av alla i ett rum. Förklarar skillnaden genom att visa den. Skriv två lappar och sätt upp på väggen: ett bra exempel med stora tydliga tecken, och ett dåligt exempel med liten oläsbar text.
Skriv koncist, men med hela meningar. Vi överskattar ofta både vår egen förmåga att minnas våra idéer och andras förmåga att förstå dem. Att skriva "Testning" på en röd lapp och posta på väggen under en återblick kan kännas effektivt när man skriver den, men det är mycket mer effektivt att unna sig några extra ordklasser på lappen. "Testarbetet börjar ofta sent i sprinten, och hinns inte med till fullo", är begripligt för fler än lappskrivaren. Och återigen, när man fotar eller skriver av sina resultat får man något som faktiskt är begripligt även utanför workshopen.
Använd riktiga PostIts(TM) med extra starkt klister. Ibland får jag frågan om jag har generalagenturen för PostIts i Sverige, eftersom vi förbrukar så många i mina workshops. Det har jag tyvärr inte, men jag kanske borde ha det, eller åtminstone provision. Skämt åsido så är det otroligt kontraproduktivt att spara pengar på att köpa ful-post-its med dåligt klister för att spara några kronor på inköpssidan. Varje gång en klisterlapp lossnar och måste sättas upp kostar sekunderna workshopen står still lika mycket som ett paket riktiga Super Sticky PostIts.
Riv av post-its horisontellt. Det här är ett tips som jag fick lära mig av en kursdeltagare för länge sedan. När jag helt aningslös rev av en post-it och satte upp den på väggen hördes plötsligt ett rop i kurslokalen: - "Nej, nej, så där kan du inte göra". Han som ropat visade mig hur post-it-lappen, om man river av den från traven horisontellt, sitter mycket mer plant mot väggen när man klistrar upp den. Typiskt är annars att man rycker av lappen genom att ta tag i nederkanten, och dra av den i riktning upp mot klistringen, vilket gör att lappen böjer sig och pekar ut från väggen. Kan tyckas helt irrelevant, tills man inser att lappar som pekar mot taket är rätt svåra att läsa för de som deltar i workshoppen sittande.
Våga makulera. Det här är förmodligen en rest från skoltiden. Många har oerhört svårt för att makulera skrivna lappar. Istället för att bara riva sönder en lapp som blev dålig försöker man sudda, skriva över och skriva runt. Resultatet: en post-it sparad, till priset av att det blir helt omöjligt för övriga att läsa vad som står på lappen. Så vad är viktigast: att spara en bit papper eller komma överens om vad den där kniviga användarberättelsen egentligen gick ut på? Jag brukar be alla deltagare att ta en tom post-it, skriva ned någon godtycklig, men inte för kort, text. Därefter får alla hålla fram sina lappar för varandra. Jag förklarar sedan att lapparna inte blev så bra, så därför ska vi riva sönder dem. Jag ber samtliga att strimla sina lappar. Det har hänt att folk vägrat.
Ha en upptejpningsassistent. Som Scrum Master är man ofta den som leder workshops av olika slag, till exempel planering- och återblicksmöten. För att få lite flyt i arbetet är det bra att dela med sig av sysslorna. Låt inte tempot i workshopen gå ned medan du ensam river och tejpar upp blädderblockslappar ni skrivit på. Be en deltagare att kliva in som upptejpningsassistent, och kanske någon annan som avrivningsexpert.

Om bloggen

2008-07-19T14:48:00.010+02:00

Den här bloggen är till för dig som redan kan en del om Scrum och vill använda arbetssättet för att nå din organisation eller ditt teams fulla potential.

Det finns en hel del skrivet om Scrum, men det allra mesta är på engelska. Den här bloggen är på svenska, och här kommer det att finnas praktiska tips för dig som Scrum-användare, tillsammans med förklaringar kring varför tipsen ser ut som de gör.

Just varför-biten är viktig. Styrkan med Scrum är att man snabbt kan komma igång, och sedan förbättra gradvis. Det är också svårigheten med Scrum. Scrum är ingen manual som förklarar bästa praxis. Tvärtom. Scrum utgår från att vad som är bäst beror på sammanhanget. Svaret "det beror på" är tyvärr inte till så stor hjälp för den som vill lösa ett specifikt problem. Om vi däremot tar en titt på vad det beror på, så har vi ofta ett användbart tips. Det är min ambition när det gäller tips kring lite mer luddiga frågor på den här bloggen.

Jag som skriver bloggen heter Tobias Fors. Jag har arbetat med att använda, införa och lära ut Scrum sedan jag lärde mig arbetssättet av Ken Schwaber 2003.