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.
