Tankar om rollerna i Scrum

Jag skriver på en bok med arbetsnamnet “Nyckeln till Scrum”. Min erfarenhet säger mig att de som lyckas bäst med Scrum är de som inte bara kan metodens praktiska steg, utan som också förstår varför den är utformad som den är. Beväpnad med den förståelsen öppnar sig också vägen framåt, möjligheten att gå bortom Scrum. Det här är ett avsnitt som handlar om roller, som kanske kommer med i boken.

Enligt ordboken på min Mac härstammar ordet ”roll” från det inte längre använda franska ordet ’roule’, som syftade på den rulle med papper som skådespelarens roll stod skriven på.

Till skillnad från andra modeller beskriver Scrum bara några få roller. Tre stycken, närmare bestämt: produktägaren, scrum mastern och utvecklingsteamet. Vi har inga speciella roller för de som deltar i utvecklingsteamet, utan nöjer oss så.

Varför behöver vi roller överhuvudtaget?

Det handlar om förenkling. Över tiden kan vi lära oss att närmast intuitivt agera inom ramen för en viss roll, eller bete oss på ett visst sätt i vårt samarbete med en person som verkar i en viss roll. Vi behöver inte hänvisa till en lång lista som beskriver ansvar och befogenheter. Vi vet vad som gäller, helt enkelt.

Roller som verktyg är ett dubbeleggat svärd. De förenklar, men kan också förenkla för mycket. När du hör att jag arbetat som projektledare associerar du vissa beteenden och mandat med det. Du kanske kan tänka dig ungefär vad jag jobbade med, vilka typer av utmaningar jag brottades med och vilken sorts beslut jag fick ta. Tyvärr har du förmodligen fel. Inga två projektledarjobb är lika varandra.

En fara med namngivna roller är att vi tror att vi vet vad som gäller när vi egentligen inte vet. Eftersom vi tror att vi vet ställer vi inte frågor om rollerna. Vi beter oss som om vi vore överens och blir förvånade när problem uppstår, eftersom vi var så säkra på att vi förstått varandra.

Samma utmaning finns när det gäller rollerna i Scrum. På pappret ser de tydligt definierade ut, men i praktiken är det inte är fullt så enkelt.

När jag undervisar i Scrum brukar jag dela ut varsin specialgjord kortlek till grupperna på kursen. På varje kort står ett ansvarsområde eller en fråga. Jag ber grupperna dela upp korten i tre högar, en för varje roll i Scrum, så att rätt kort ligger på rätt roll. Jag förklarar att de är klara när de är helt överens om sorteringen. Det blir de aldrig.

På ett av korten står ”Kan du förklara den övergripande arkitekturen?”. Gruppen vrider och vänder på argumenten för att lista ut vem som egentligen borde besvara denna fråga. Det brukar bli jämnt skägg mellan produktägaren och utvecklingsteamet. Några hävdar bestämt att det är utvecklingsteamet som borde ta denna fråga. Andra är lika säkra på att det är produktägaren. Det brukar sluta med att man får lägga kortet åt sidan.

När vi efteråt går igenom övningen frågar jag deltagarna om de kan definiera ordet arkitektur. Utan undantag visar det sig att de som tycker att produktägaren borde fått frågan anser att arkitektur handlar om produkterbjudandets olika delar, som produktägaren självklart måste behärska för att kunna förklara produkten. De som röstar på utvecklingsteamet tycker istället att arkitektur handlar om den rent tekniska lösningen, som teamet ansvarar för. Olika definitioner leder till olika syn på ansvarsområdena.

Flera frågekort är svåra att placera eftersom de beror på vilken kompetens som finns var. En fråga lyder: ”Exakt hur är det tänkt att den här dialogrutan är tänkt att fungera?” Somliga svarar snabbt utvecklingsteamet. Produktägaren ska ju inte vara inne och pilla i detaljer, och naturligtvis har vi antingen en separat gränssnittsexpert med i teamet, eller minst en utvecklare som behärskar området bra. Andra protesterar. Deras utvecklingsteam består av programmerare som inte behärskar gränssnittsutveckling, och ser det därför som självklart att produktägaren är den man går till för denna typ av frågor. Ytterligare andra menar att frågan handlar om situationen när teamet inte kan komma överens, och arbetet blir lidande för att ett beslut inte tas. De menar att det är produktägarens jobb att kliva in och ta beslutet. Vid ett tillfälle påpekade någon att det kanske handlar om utveckling av ett gränssnitt för en operatörspanel i ett kärnkraftsverk, och att produktägaren därför är med och bestämmer även om de minsta detaljerna, eftersom de är en sådan avgörande framgångsfaktor för produkten.

Det är sällsynt att någon helt missförstått någon av Scrums roller – ändå blir tolkningarna helt annorlunda. Sammanhanget avgör tolkningen. Vi är inte ute efter den enda sanna tolkningen, vi är ute efter den tolkning som passar bäst, utan att göra våld på rollens grundläggande skrivelse.

En fördel med att inte skriva rollbeskrivningar med extrem detaljskärpa är att de blir brett användbara. Nackdelen, om man får säga så, är att vi måste tänka efter mer själva. Vi måste sätta in rollen i sitt sammanhang, och se vad som händer då. Vi måste applicera metoden i vår kontext, lite på samma sätt som skådespelaren måste tolka sin roll utifrån den scen han står på och den pjäs han spelar. Det finns inte en sann Hamlet, lika lite som det finns en färdig definition av vad det innebär att vara produktägare, scrum master eller medlem i ett utvecklingsteam. Allt vi får är papperet med rollen på, sen är det upp till oss att på darriga ben stappla ut på scenen och agera.

Vilka är dina erfarenheter av namngivna roller på jobbet?

Att lära sig tillsammans – Agila Sverige 2009

På konferensen Agila Sverige 2009 gjorde jag ett blixttal på temat lättrörlighet och lärande, med titeln “Att lära sig tillsammans”. Konferensarrangörerna filmade alla tal, och mitt har nyligen blivit publicerat. Bäddar in det här nedan.

Lära sig tillsammans – Tobias Fors from agilasverige on Vimeo.

Svensk bok om Scrum på gång

På AYE-konferensen häromveckan nämnde jag i förbifarten för Jerry Weinberg att jag håller på att skriva en bok, och att jag kommit ganska långt med den, även om den är långt ifrån klar. Jag följer Jerrys råd att helt enkelt först skriva den bok jag själv vill skriva, för att sedan se om den är publicerbar. Skulle den aldrig komma ut har jag ändå lärt mig enormt i processen, och i dessa dagar är det ju heller inga problem att publicera den som en PDF på nätet som alternativ lösning.

Jag vet sedan tidigare att Jerry tycker att det är dags att marknadsföra sin nya bok långt långt innan den är redo för tryckning. Eftersom kongruens är ett nyckelord för honom agerade han i enlighet med vad han lär ut, och passade på att berätta om min kommande bok i en fullsatt workshop på konferensen. Det var lite överraskande förstås, men helt OK. Varför inte berätta om det? Eller vänta, jag har massor med anledningar (“någon knycker idén”, “den kanske aldrig kommer ut, och då får jag skämmas”, “man ska inte räkna pengarna innan smöret är sålt” och “jag som inte ens kan komma ihåg ordspråk rätt, hur ska jag kunna skriva en hel bok”). Men alla de anledningarna känns som svepskäl, så jag struntar i dem och skriver glatt vidare.

Vad boken ska handla om? Lättrörlig utveckling med Scrum, såklart, eftersom det är det jag ägnat mig åt i snart sju år. Det finns många andra böcker på temat, men jag tycker att det saknas en lättläst bok på svenska, som dessutom hittar rätt balans mellan teori och praktik.

Min bok ska ge praktisk handledning, men framför allt hjälpa dig som läsare att förstå varför ett visst sätt att bete sig kan vara mer effektivt som ett annat.

Jag vill hjälpa dig att komma vidare även när grundreglerna i Scrum visar sig svårare att leva upp till än du först trodde. Jag vill dessutom immunisera dig som läser boken mot metodövertro. Inget verktyg går att använda till allt, men det kan ändå vara användbart att lära sig det. Så även med Scrum.

Boken ska den vara lättläst också, nämnde jag det?

Vad vill du absolut ha med i en svensk lättläst bok om lättrörlig utveckling med Scrum? Du borde berätta om detta för mig i kommentarsfältet härnedan!

Att lära sig tillsammans – Agila Sverige 2009

Det här är mina presentationsbilder från mitt blixttal på Agila Sverige 2009, som handlade om lärande, och hur vi kan använda förståelse för läroprocessen för att lära oss bättre tillsammans.

Agila Sverige 2009, (första halvan av) Dag 1

Idag tog jag tåget till Stockholm för att delta på Agila Sverige 2009 Agila Sverige är en två dagar lång konferens som är billig att delta på, eftersom den sponsras av några företag, däribland Citerus. Arrangemanget sköts av några flitiga eldsjälar inom agilerörelsen i Sverige, som ska ha flera stora tack för detta. Besökarantalet tror jag låg på runt 180 personer.

Förmiddagen var idag, precis som förra året, vigd åt blixttal. Med det menas 10 minuter korta tal som oftast är lika innehållsrika som ett mycket längre tal, men betydligt mer uthärdliga.

Här är mina anteckningar från de presentationer jag lyssnade på idag (det var två spår som man kunde jogga fram och tillbaks mellan).

Maria Thelin

Först ut var Maria Thelin, som delade med sig av några uppenbarelser hon fått när hon jobbat med att införa Scrum i större organisationer de senaste åren. Hon inledde med att förklara att hon skulle kunnat kalla presentationen “hur man skapar en oagil agil metod”, och nämnde några utmaningar hon stött på: sponsorer som backar ur, att man underskattar förändringen som krävs och en ovilja att förändra sina befintliga arbetssätt.

Maria frågade sig varför det egentligen är så svårt att uppnå den flexibilitet och leveranshastighet som företag är ute efter. Svaret blev att befintliga beroenden i organisationen förhindrar förändring. Maria menade att om dessa beroenden får kvarstå, så är risken stor att man skapar sig en oagil agil metod, och att agile förutsätter att beroendena inte finns kvar, och även att agile utgår från att vi har en bra objektorienterad arkitektur och använder saker som TDD.

– – –

Mina reflektioner: alla organisationer har sina befintliga mönster, som är mer eller mindre svårförändrade. Om vi vill förändra dem måste vi börja med att förstå dem. Visst är det frusterande att det är som det är, men det är som det är för att det var som det var. Det finns en historia bakom dagens situation, och den historien handlar ofta om gårdagens lösningar. Någon har kämpat lika hårt som vi gör nu för att förändra organisationen, och resultatet är det vi ser idag.

Visst känns det som om man vill göra revolution ibland, men revolutioner tenderar att följas av en kontrarevolution: om några år kommer någon annan att slita sitt hår över de lösningar vi fick till stånd i vår revolution. Hur tråkigt det än kan låta tror jag själv mer på en långsam och målmedveten förändring mot ett attraktivt mål.

Scrumreflektion: en av anledningarna till att jag gillar Scrum, och kanske ett skäl att andra inte gillar Scrum, är att det är ett ramverk som inte gör några anspråk på att vara en slutlig lösning. Många verkar fortfarande se Scrum som otillräckligt, när själva poängen är att varje process för mjukvaruutveckling är otillräcklig. Vi måste alltid fylla på med lösningar som fungerar i vår kontext, och vi måste alltid arbeta med att hela tiden öka vår förmåga.

De flesta av oss börjar inte från ett tillstånd där vi har perfekt kunskap om objektorienterad design eller där vi vet hur man löser konflikter mellan människor. Det spelar ingen roll: vi måste ändå planera och följa upp vårt arbete, och där kommer Scrum in. Vill vi sen lyckas på en konkurrensutsatt marknad måste vi dessutom bli bättre väldigt snabbt, och jag tror att det var det Marias presentation tog fasta på: frustrationen över att det nästan alltid känns som om det går för långsamt. Marias råd är väl värda att repetera: förklara vad det innebär att börja jobba lättrörligt, eller sänk förväntningarna på resultatet direkt.

Ola Ellnestam – Jag vill ha förbättring men ingen förändring

Ola Ellnestam körde sin presentation utan slides och med hjälp av skrivkort som stöd för minnet. Han förelästa om vårt förhållande till förändring. Vi vill gärna ha förbättringar, men helst utan att behöva genomgå förändringsarbetet. Det underbara exempel på hur det inte går till som fick mig att garva var: “Tjenamors, jag är din nya kondis, får jag klättra in i din kropp”. Underbart! Humor som stöttar budskapet i presentationen är alltid välkommet.

Efter humorn följde Ola upp med att testa vår förändringsbenägenhet. Han vill veta när vi ändrade vår frukost senast, och lät oss göra en övning som var väldigt lik en jag lärt mig från Jerry Weinberg. Jerry brukar låta folk korsa händerna fel och fråga hur det känns. Ola lät oss korsa armarna fel och utmanade oss att sitta så, så länge vi orkade. Jag gav upp direkt. Faktum är att jag vet inte om jag ens lyckades korsa armarna fel, det var svårt. Bra övning.

Ola påminde oss om att “ständiga förbättringar” också betyder “ständiga förändringar”, och exemplifierade mycket tydligt med hur drygt det vore om vi till exempel bytte valuta nån gång i veckan. Ganska smärtsamt. Värt att tänka på för den som jobbar med förändring i någon form.

Måns Sandström – Evolution på jobbet

Måns Sandström från nystartade Adaptiv drog fram Darwin och påminde oss om att variation och selektion ger evolution. Måns argumenterade för att vi är bra på selektion (som när vi väljer Oracle, SAP eller Scrum), men fruktar variation. Han illustrerade fenomenet med ett citat från verkligheten: “Har vi nu skrivit ned exakt hur vi gjorde, så att vi kan göra det igen på exakt samma sätt?”

Uppmaningen från Måns var att omfamna variation, till exempel genom att pröva något nytt i varje iteration, ett tips han snappat upp från Mike Cohn (som för övrigt kommer till Sverige i höst för att hålla kurser).

– – –

Mina reflektioner: Absolut! Vi behöver bli bättre på att våga pröva nya sätt, och fortsätta så. Risken med att standardisera är att vi driver ut all möjlighet till att göra nya upptäckter. Samtidigt är det viktigt att inte drabbas av standardskräck: standarder har definitivt sin plats. Tricket är att våga kasta ut dem och ersätta dem med nya så fort de inte duger längre, eller så fort det finns ett bättre sätt att göra saker och ting. Förslag: låt team etablera sina egna standarder, och granska sin egen efterlevnad. Hjälp dem att se hur deras egna standarder kan göras mer effektiva.

Niklas Björnerstedt – Strategier för smidig utrullning (i replacementprojekt)

Niklas, som efter tolv år i Norge började med att be om ursäkt för sin norska brytning (en sorts Dolpheffekt får man väl säga) berättade om sina tankar kring produktionssättning. För Niklas är smidighet (som man kallar agile i Norge) starkt förknippat med förmågan att sätta i produktion ofta. Scrums mål att vi ska ha potentiellt levererbar produkt i slutet på varje sprint tyckte han var ett dåligt surrogat för riktig produktionssättning. Bara genom sann produktionssättning får vi äkta feedback.

Konceptet minimal deployable entity är ett begrepp som Niklas myntat, inspirerad av idén om minimal marketable features (Denne, Huang). En MMF handlar om att fråga sig vad som skulle ge kunden mest värde. En MDE handlar om hur man minimerar risk i projektet.

Efter denna inledning berättade Niklas om sina tankar kring hur man minimerar sina MDE:er. Principer + mönster = strategier, var den formula han presenterade, och följde upp med några exempel.

Ett exempel på en princip var principen om begränsad produktionssättning. Om man vill ha den riktiga feedback man får från en riktig produktionssättning kan man leverera ut till ett fåtal användare. 6-8 användare kan enligt Niklas räcka för att få bra återkoppling. Det handlar alltså inte om att skicka ut en version till en testgrupp, utan om en faktisk lansering till en begränsad krets.

Niklas ska berätta om sina principer och mönster på Agile 2009, och hoppas jag, publicera dem på något sätt, men jag minns inte vad han sa om just detta.

– – –

Mina reflektioner. När vi i Scrum pratar om att ha potentiellt leverbar produkt i slutet på varje sprint är det just för att vi vill kunna skeppa ut något till produktion tidigt. Visst kan det tänkas vara bättre att ha helt releasebar produkt varje sprint, men ofta är det inte görbart, och kanske inte alltid heller helt önskvärt. Jag kan tänka mig situationer (t.ex. vid nyproduktsutveckling) där det är en bättre strategi att fokusera på andra saker de första sprintarna än förmågan att produktionssätta. Skjuter man på det för länge skjuter man sig såklart lätt i foten, dock.

När det gäller risk är det viktigt att komma ihåg att det finnas minst två stora riskgrupper när vi bygger nya mjukvarusystem. Dels risken att vi bygger fel produkt, dels risken att vi bygger produkten på fel sätt. En riskhantering som vi gör med Scrum är att snabbt provtrycka processen genom att köra igenom den från ax till limpa (alltså från krav till potentiellt leverbar produkt). En annan är att vi bygger produkten i körbara inkrement, så att vi har möjlighet att inspektera dem och se om vi är på väg att bygga rätt produkt. Rätt produkt handlar om marknadsrisk. Att bygga på rätt sätt handlar om teknisk risk. Niklas metod att produktionssätta tidigt kan angripa båda dessa risker, eftersom vi dels upptäcker om vi utvecklar på ett sätt som leder till en levererbar lösning, och dels ser om lösningen löser problemen (genom den feedback vi får när vi produktionssätter).

Om man kopplar ihop Olas presentation med Niklas får man en intressant vinkling. Det finns mycket att tjäna på att produktionssätta tidigt, men också många utmaningar. Att ge kunderna en ny version varje vecka kan nog bli tufft – men med Niklas princip att göra begränsade driftssättningar kommer vi ju betydligt närmare en bra lösning. Gäller bara att hitta de där första villiga kaospiloterna.

Joakim Holm – Samarbete och allt vi gör för att förhindra det

Joakim tog sin an samarbete som fenomen, och serverade en kavalkad av saker som kan förhindra det. Organisatoriska gränser, rumslig separation, separation i tiden, specialisering och resursutnyttjande avhandlades under presentationen.

Avslutningen på presentationen innehöll ett exempel på ett fascinerande samarbete. När Apollo 13 fick problem klev astronauterna över i den för gruppen underdimensionerade landningsenheten. Väl där fick man såklart problem med koldioxid. Nere på jorden sattes då ett specialteam ihop med uppdrag att lösa problemet. Det gjorde man, och det resulterade i att astronauterna själva kunde bygga en liten mojäng som filtrerade luften ombord.

– – –

Mina reflektioner. Jocke är dead on. Samtliga av de problem han tog upp är oerhört allvarliga för mjukvaruutveckling, och det har att göra med stora kunskapsinnehåll vårt jobb har. Så fort vi börjar separera oss måste vi jobba mer med att överföra externaliserad kunskap mellan individer, vilket är en form av “kall” kunskap. När vi, som klyschan lyder, arbetar på samma sida – nära varandra, med samma mål, på samma plats – kan vi överföra kunskap genom att observera varandra, ha snabba utbyten och helt enkelt lösa problem på mer kreativa och effektiva sätt. Det är anledningen till att iterationer och tvärfunktionella team är en så intressant kombination.

Anders Ivarsson – Retrospektiv

Anders öppnade med att beskriva hur många känner inför retrospektiv. Man tycker att det lätt blir en negativ eller anklagande stämning, att det bara blir prat och att man tar upp samma problem om och om igen.

Anders tipsade om att få in mer variation i retrospektiven, att byta facilitator och att pröva nya tekniker för retrospektiven. Han rekommenderade också att man inte ska försöka söka en lösning under retrospektiven.

– – –

Mina reflektioner. Jag känner igen mig i Anders erfarenheter. Däremot är jag inte helt säker på att jag förstått det här med att undvika att söka lösningar. Jag köper att man inte ska vara för het på gröten när det gäller lösningar, men samtidigt ser jag en risk i att skippa lösningsarbete helt och hållet. Visst, allt kan inte lösas på ett retrospektiv, men en del saker kanske går att komma överens om redan där. Behöver fundera mer på detta känner jag.

(Paus)

Bollade lite med Esther Derby som kan del om retrospektiv. Hon håller med om att alltför många börjar med lösningar, och skriver att hon vill att hon vill att team ska ha dataunderlag och förståelse för problemen först, och sedan jobba med lösningar i mån av tid. Jag frågade om hon tycker att det finns några skäl att skippa lösningar helt, men hon kom inte på några. Tvärtom kan lösningsarbetet göra att retrospektiven känns mer hjälpsamma. Jag håller med.

Tobias Fors – Att lära sig tillsammans

Min egen presentation var en 10-minutersvariant av den presentation jag gjorde på 30 minuter på Softhouse Öresund Agile för några veckor sedan. Det var betydligt roligare att göra den på 10 minuter, inte minst för att jag fick prata snabbt, vilket jag alltid gör ändå, och älskar. Långsamt prat söver mig, om det inte är extremt intressant, i vilket fall jag kan lyssna på hur släpiga talar som helst. Nästan.

Reflektioner på min egen dragning: borde fokusera på chefens ansvar för lärandeprocessen, och kanske på något ännu tydligare sätt utmana publiken att gå ut och leta rätt på allt kunnande som redan finns i deras organisationer. Det grämer mig att så mycket kapacitet får gå outnyttjad. Om Sverige ska kunna bli ett världsledande mjukvaruland måste vi vara världsledande på att bygga ta till vara lärande i våra organisationer.

Peter Tallungs – Utmaningar och möjligheter för den agila rörelsen

(Börjar bli lite trött i ögat, så nu blir jag mer kortfattad)

Peter Tallungs klev fram som en förebild med en slide stack som bara var två bilder hög: en presentationsbild, och ett framväxande diagram som väl illustrerade hans poänger.

Peter argumenterade för att vi som jobbar med agile måste våga kliva ut och se bredare på saker och ting, åtminstone sträcka oss ut och innefatta verksamhetsutveckling. Han slog ett slag för att plocka fram det goda ur “lite äldre metoder” och utnyttja det. Enligt Peter har agilerörelsen fastnat i en låda med dimensionerna “programmering”, “endast en applikation”, och “nyutveckling”. I verkligheten har verksamhetsutvecklingen idag, enligt Peter, flyttat in i IT-systemen, vilket gör oss som utvecklar dem till affärsutvecklare.

– – –

I viss mån är jag benägen att hålla med Peter – det är lätt att ha en för smal syn på saker och ting. Samtidigt är det kanske det som gjort agile så framgångsrikt. Att försöka täcka alla flanker resulterar ofta i lösningar som blir överkrångliga. Omvänt ger möjligheten att fokusera på en del av problemet en enkelhet och tydlighet som behövs när man ska bygga komplexa produkter. Tanken med Scrum är ju just att försöka skapa en situation där team kan vara produktiva.

Men visst, självklart måste vi höja blicken och expandera våra visioner för det här med lättrörlighet. Gör vi inte det blir det bara ännu en “programmeringsmetod” med begränsat genomslag.

Chris Hedgate – Medvetenhet är det första steget till förbättring

Chris öppnade med en sjukt snygg seriestrip som jag hoppas att han publicerat någonstans på nätet. Han hade tydligen låtit någon rita den baserat på en sann historia Chris hört talas om. Han fortsatte med att berätta om den frustration många känner efter att ha försökt, förgäves, att initiera en förändring. “Jag har köpt alla böcker och gett mitt team att läsa, men ändå händer inget”, som man kan få höra.

Chris förklarade en fyrastegsmodell över kompetens. Vi kan vara omedvetet inkompetenta, medvetet inkompetenta, medvetet kompetenta, och omedvetet kompetenta. Beroende på var vi befinner oss har vi helt olika behov. Den som vill jobba med förändring behöver känna till detta, så att man kan anpassa sitt stöd för individen, enligt Chris.

Omedvetet inkompetenta behöver inspiration. Medvetet inkompetenta behöver kunskap. Medvetet kompetenta behöver öva. Omedvetet kompetenta behöver reflektion.

– – –

En helt lysande dragning, som passade perfekt för mig. En teoretisk modell kombinerad med praktisk applicering av den. Jag försökte bygga upp mitt tal på samma sätt, men jag tycker att Chris lyckades mycket bättre. Jag frågade Chris på lunchen hur man vet var någon befinner sig, eller om man ens kan veta det. Vi kom inte fram till något just då. Ett läromål för framtiden för mig.

Lena Norman – En fyrarummare för förändring

Min Citeruskollega Lena Norman höll en intressant dragning om förändring. Hon ritade upp Claes F Janssens modell som beskriver förändring som en passage genom en lägenhet med fyra rum. Det börjar bli sovdags på allvar för mig nu, så jag återberättar inte modellen här, utan väntar snällt på att Lena ska skriva ihop en sammanfattning själv, hehe. Den finns även beskriven här.

– – –

Lenas presentation var givande, eftersom den gav ett nytt perspektiv på en process jag tänker på på ett helt annat sätt. För mig verkade Janssens modell nämligen väldigt lik Satirs förändringsmodell, som jag lärt mig av Steven Smith och Jerry Weinberg. Styrkan med fyrarummaren kanske kan vara den väldigt visuella bilden av att passera genom en lägenhet. Ska läsa mer om den och jämföra med det jag kan om Satirs modell.

Fredrik Hedman – PEJL + PENG + SCRUM

Fredrik tog upp att det finns många Scrum Masters, men inte så många produktägare. Som produktägare har han själv känt behovet av att komplettera Scrum med andra modeller. Fredrik tyckte också att produktägaren är den viktigaste rollen i Scrum, vilket motsades av någon i publiken som ropade att alla roller är lika viktiga.

– – –

Det är en vanlig uppfattning att Scrum är en komplett modell av hur utveckling går till. Så är det inte. Tvärtom behöver man fylla Scrum med det som behövs i just den egna situationen. Att komplettera Scrum med t.ex. PENG-modellen för nyttokalkylering är alltså ingen dum idé. Själv brukar jag dock bli mer försiktig när man börjar prata om att plocka in projektstyrningsmodeller. De leder ofta tanken tillbaks till ett sekventiellt arbetssätt. Men visst, allt funkar om man gör det med måtta och eftertanke. Även Scrumprojekt har en startfas, även om vi vill att den inte ska vara en sexmånaders förstudie.

Torbjörn Kallin – Problemfokuserande retrospektiv

Även Torbjörn tog fasta på att retrospektiv kan bli för lösningsfokuserade. Han föreslog att vi helt enkelt förbjuder lösningsdiskussioner på retrospektiv. Torbjörn visade också ett exempel på en typ av 5-varför-användning, för att illustrera hur man kan gå djupare och hitta ett problems rotorsaker

– – –

Åter denna rädsla för lösningar. Problemet är inte att vi pratar lösningar, problemet är att vi pratar om lösningar utan att ha en förståelse för vilket problem de angriper. Förslaget att eliminera lösningsdiskussioner känns för mig som ett exempel på en lösning som angriper ett symptom, snarare än en rotorsak.

Jag tror att retrospektiv, eller återblickar, som slutar med lösningsarbete känns mer produktiva än de som inte gör det.

Humanova – Hur man dödar konflikter med verbal judo

I den här presentationen bjöds vi på lysande presentationsteknik. Fredrik Fleetwood och en kollega vars namn jag inte antecknat och som inte finns med i programmet av någon anledning visade oss ett exempel på en produktiv och en mindre produktiv konversation. Deras modell för at göra detta såg ut så här:

Kontakt (känslor) -> Dialog (fakta) -> Gemensam lösning (framtid)

I korthet: särskilt i en stressad situation tjänar vi på att börja med känslorna. Om vi inte hanterar dem i början av den kontakt blir det nästan omöjligt att gå vidare med annat.

– – –

Reflektion: en inspirerande presentation. Så tydligt det blev tack vare rollspelet. Mästarklass. Pedagogiskt. Roligt.

Joakim Sundén – Så använder vi lean i vårt Scrumteam

Joakim berättade om hur man använt visuell styrning med enkla medel i ett team, och kombinerade detta med att presentera utvada leanprinciper.

– – –

Reflektion: bra verktyg, viktiga saker, men för mig inte så mycket nytt.

Open Space

Efter lunchen var det open space. Jag deltog bara i en session innan jag åkte tillbaks till Uppsala för att simma med min dotter – det missar jag inte!

Jag upptäckte att jag blev besviken över att det öppningen av forumet inte skedde i en cirkel. Det borde ha varit görbart trots den stora gruppen. Nu blev det en stor folkmassa som bara riktade sin uppmärksamhet mot de som stod på scenen. På något sätt kändes det inte så open spejsigt att börja med att titta på varandras nackar. Men, men, agendan såg ut att ha blivit knökfull ändå, så kanske ingen skada skedd. Dock intressant att så många som aldrig skulle kompromissa med agile så lätt kompromissar med “givens” i open space.

Visuell styrning med kanban (2): Enkla, kraftfulla verktyg

I det förra inlägget skrev jag om bakgrunden till att jag börjat arbeta med visuell styrning med kanban. Det här inlägget ger en första titt på verktygen vi kan använda.

Utöver ett uppdrag att slutföra och kunskap om hur kanban fungerar behövs följande för att komma igång med en egen kanbantavla:

  • En rymlig whiteboard med tillhörande pennor
  • Post-its i olika färger
  • Pennor som det går att skriva tydligt på post-its med (vanliga bläck eller blyertspennor ger så tunn skrift att det blir svårt att läsa vad det står när man står en bit från whiteboarden)

Att jobba med en kanbantavla (för till exempel sitt drifts- eller supportteam) handlar om att synliggöra sitt arbete så att man istället för överbelastning kan ha rätt mängd arbete igång, och därmed få fler saker klara snabbt och med rätt kvalitet.

Vi använder post-its (eller något annat flyttbart) för att dokumentera vad vi jobbar med – en sak per lapp. Målet är inte att dokumentera varenda liten sak som görs. Tvärtom funkar det hela bäst om man på lapparna skriver ned små nyttiga delresultat, snarare än aktiviteter.

Arbetets aktuella status visar vi genom att placera våra lappar på rätt ställe på whiteboarden. På den har vi nämligen ritat upp vår grupps arbetsprocess, så att lapparna kan sättas i kolumner som visar de olika steg arbetet går igenom, från ax till limpa.

Vi vet att kanbantavlan börjar fungera när vi med en snabb blick kan se vilket arbete som väntar, vad som pågår, och vad som gjorts klart. Från dag till dag kan vi lapparna röra sig över tavlan, från en kort prioriterad lista, genom de olika stegen i arbetsprocessen, på väg mot leveransklara resultat.

En whiteboard och post-its kanske verkar vara primitiva vertyg? Det stämmer, och det är helt avsiktligt. De är nämligen också mycket kraftfulla.

Genom att använda dessa enkla verktyg gör vi det lätt att anpassa vår process när vi märker att det behövs – det kostar bara lite suddande, omritande och lappflyttande. Med andra ord hindras inte våra förbättringsambitioner av att verktyget inte hänger med i svängarna (något som i min erfarenhet händer oftare än vad som är önskvärt). Med andra ord: Ingen hittar den optimala arbetsprocessen på första försöket. Verktygen finns till för att stötta processen. Därför måste det vara lätt att justera verktygen.

När synligheten är stor är det också lättare för var och en att veta var man kan hjälpa till. Gruppen får tydliga signaler när den behöver samarbeta för att lösa problem. Hur klyschigt det än kan låta så är ett team mer än summan av sina medlemmar. En grupp som lär sig samarbeta effektivt, till exempel med hjälp av en kanban-tavla, har tagit ett steg på vägen mot att bli ett effektivt team. Ett team låter inte sina medlemmar kämpa ensamma, det kliver in och hjälper individen att komma vidare och växa. Alla verktyg som kan hjälpa oss att komma närmare det idealet är värda en andra titt.

Använder du visuell styrning med enkla verktyg? Vad är dina bästa tips?

Kom på kurs: Certifierad Scrum Master, augusti 2009

Gör som flera hundra andra redan gjort: kom på CSM-kurs med mig i Stockholm. Det här är kursen för dig som verkligen vill _förstå_ Scrum. Själva Scrumsnurran är ju inte så svår att rita upp, men varför ser modellen ut som den gör, och var sitter hävstängerna som verkligen får Scrum att funka? Kursen för dig som gillar att fatta med andra ord.

Jag använder inga PowerPoint-slides på min kurs. Pedagogiken bygger på en varvning av kortare föreläsningsmoment och interaktiva (och roliga!) övningar kring olika aspekter av att jobba lättrörligt med Scrum. Hängiga ögonlock är extremt sällsynt. Om du blir trött är det för att vi jobbar hårt tillsammans, inte för att du sövs av en surrande projektor och min svada. Nej tack säger vi till sånt tråk.

När vi frågar deltagarna hur sannolikt det är att de skulle rekommendera kursen för en vän eller kollega svarar nästan samtliga 7, 8 eller 9, på en skala från 1-9, där 9 betyder mest sannolikt. Snittet från den senaste kursen jag höll (i Malmö för två veckor sedan) var 8.0.

Hoppas vi ses där!

http://www.citerus.se/csmaug09

Visuell styrning med kanban (1)

De senaste åren har jag jobbat med att hjälpa team och organisationer att förstå och använda Scrum. Jag har jobbat en hel del med produktutvecklande företag, och det är i utvecklingsarbete Scrum verkligen kommer till sin fulla rätt. Samtidigt består arbetet med att lansera mjukvaruprodukter av så mycket mer än bara själva utvecklingen. Drift, support och marknadsföring är några exempel på aktiviteter som är avgörande för framgång.

Förra hösten åt jag lunch med en branschkollega på en restaurang i Uppsala och vi pratade om hur det gick för deras utvecklingsteam, som nyligen börjat använda Scrum. Det gick utmärkt. Arbetet var fokuserat och tydligt, och man hade lyckats genomföra ett komplext projekt framgångsrikt.

Samtidigt kände man på driftssidan att man ville ha ett lika engagerande och tydligt sätt att styra och följa upp sitt arbete. Jag berättade om något jag studerade just då – visuell styrning med kanban. Så vitt jag kunde se var de bakomliggande principerna sådana vi känner igen från Scrum, även om de praktiska handgreppen ibland ser lite annorlunda ut. Vi kom överens om att försöka få till ett kort och fokuserat samarbete för att få till en kanbanlösning för deras driftsgrupp. På så vis skulle även de kunna dra nytta av tankarna bakom Scrum.

Kanban är japanska, och betyder till vardags helt enkelt skylt eller tavla. Inom tillverkningsindustrin har begreppet däremot fått en mer specifik betydelse. Där betyder kanban ett signalsystem som styr flödet i produktionen. Jag är absolut ingen expert på industriell produktion, men jag kan göra ett försök att förklara systemet som jag förstått det.

Här är ett konkret exempel. En person som arbetar med att montera en komponent för en viss maskin behöver en mängd olika delar för att kunna göra sitt jobb. Hur många av varje? Det skulle man kunna försöka styra med ett avancerat datorsystem som prognosticerar behoven framöver. Eller så använder man kanban.

I ett kanbansystem signalerar varje del i en produktionskedja sitt behov av nytt material från ett föregående steg genom att tydligt flagga upp behovet. Rent praktiskt kan signaleringen ske genom att en låda med delar tömts, och därför skickas för påfyllning tillsammans med ett litet instruktionskort – en kanban – till den som kan fylla på lådan. Lådan fylls, och skickas tillbaks till beställaren. På samma sätt fortsätter beställningarna “bakåt” i produktionsledet. Fördelen? Processen styrs efter behov istället för efter spekulativa prognoser. Kanban blir därför en nyckelteknik i Just-in-Time-processer.

Så vad har kanban att göra med till exempel drift av mjukvara? Vi kan inspireras av metoden för att styra och följa upp arbetet i till exempel en driftsgrupp på ett sätt som är både tydligt och enkelt.

Våra kanban blir helt vanliga post-it-lappar som vi flyttar på en whiteboard. Whiteboarden designar vi för att ge en helikopterbild av arbetsprocessen. Resultatet: ungefär samma som när vi sätter upp sprintbackloggen på väggen och får en visuell sprintbacklogg, men anpassat för den typ av situation som till exempel ett drifts- eller supportteam befinner sig i. En vanlig invändning mot Scrum från denna typ av grupper är att det är svårt att få till iterationer, eftersom man arbetar så reaktivt med plötsligt inkommande saker. Mot det kan man förstås invända att man då borde fokusera på att eliminera så många oväntade saker som möjligt, och det är väl rätt i teorin. I praktiken måste man förstås ända styra arbetet under tiden, och varje sätt att få mer fokus och lite lugn och ro kanske gör det lite lättare att faktiskt börja eliminera rotorsaker till problem. Kanban kan vara ett sådant verktyg.

Med kanbantavlan blir det lättare för samtliga i arbetsgruppen att se vilket arbete som väntar, vad som pågår, och vad som är på väg att göras klart. Gruppen får också lättare att ta på sig rätt mängd arbete vid varje givet tillfälle, något som är viktigt inte bara för att undvika utbrändhet, utan också av mer kortsiktigt ekonomiska skäl. Man får helt enkelt mer klart om man undviker att överbelasta sig, och kvaliteten på arbetet blir högre.

För gruppens intressenter (t.ex. mottagare av de arbetsresultat gruppen levererar) finns också fördelar, som att det blir lättare att se status på arbetet. När synligheten ökar minskar ofta stressen. Det är helt enkelt svårare att bli stressad när man känner att man har koll på läget. När stressen minskar ökar lugnet, och vi fattar som regel bättre beslut när vi är lugna än när vi är uppjagade.

I nästa bloggpost tänkte jag skriva lite om hur det kan se ut rent praktiskt.

Känner du till en arbetsgrupp som skulle vilja dra nytta av fördelarna med att jobba lättrörligt, men som inte riktigt känner att Scrum passar perfekt? Hur gör de för att få bästa möjliga delaktighet och tydlighet?

Svensk mjukvaruutveckling i SvD

Härligt! Lite uppmärksamhet på mjukvaruutveckling i Svenska Dagbladet. Tomas Augustsson har skrivit en artikel som bland annat tar upp den utmaning det innebär att vara chef i en mjukvaruutvecklande organisation.

Flera av de som arbetar med mjukvara pratar om att de högsta cheferna på företagen kom fram när det var hård­varan, själva apparaten, som var det avgörande. Nu har en del av cheferna svårt att förstå de annorlunda villkoren för mjukvaruutveckling.

Det blir viktigare och viktigare att vi lär oss vad som styr framgång och motgång i utvecklingsprojekt, eftersom en större och större del av de produkter vi tar fram består av mjukvara.

Vi ser hur mjukvaruinnehållet fördubblas var artonde månad, säger Sten Minör som är ansvarig för Sony Ericssons strategi när det gäller mjukvara.