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!

29 december, 2008

Blädderblockstips

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.

08 december, 2008

Som man mäter får man svar

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.

27 oktober, 2008

Dialog, inte diskussion

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?

20 september, 2008

Rätt arbetsmängd är avgörande

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

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

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

07 september, 2008

Vad sprintplanering och glassinköp har gemensamt

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

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

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade att göra sitt bästa för att uppnå sprintmålet. Om planeringen tar längre tid är risken större att vi nöjer oss med det vi har och startar sprinten på ett vagt åtagande - en dålig start för effektivt samarbete.

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

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

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

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

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

30 augusti, 2008

Proxy-produktägare förtar effekten

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.

21 augusti, 2008

Sprid kunskaperna i teamet

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.

  1. 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.
  2. 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. 
  3. 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.
  4. 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.
  5. 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.
  6. 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. 
  7. 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.
  8. Å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.

15 augusti, 2008

Sega möten: ett tecken på djupare problem

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.

13 augusti, 2008

Pragmatisk eller dogmatisk? Progmatisk!

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.

02 augusti, 2008

Både Scrum Master och teammedlem?

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

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

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.

En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida 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.

27 juli, 2008

Återblickslöshet får Scrum att stanna

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.

26 juli, 2008

Alla måste inte kunna allt

"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.

21 juli, 2008

God utvecklarpraxis är en del av Scrum

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."

20 juli, 2008

Myers-Briggs Type Indicator

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

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.

19 juli, 2008

Tyst brainstorming

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

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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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. 
  7. 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

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.