Roll Around in a Cyber Cart

I just came across a completely wonderful comment by Lisa Crispin, on Johanna Rothman’s blog. I’ve just read it, and already I love it. I can’t put my finger on why, but for some reason it makes me happy. It probably has to do with my fascination for the concept we used to call cyberspace (ever since I read MIT architecture professor Michael Benedikt’s “Cyberspace – First Steps” in 1994). The discussion on Johanna’s is regarding telecommuting, and Lisa shares a story of how she achieves virtual presence:

My team set up a rolling cart for each remote team member, with a laptop, webcam, Skype and mic. My webcam displays on the laptop, and my team members roll ‘me’ around to whoever I’m pairing with, or to meetings (rolling through the halls saying hi to people is fun!) I can control the webcam to look for people.

Född: A l f r e d

Den 11:e juni 2009 föddes mitt andra barn! Kärleken var enorm från första stund. Obskrivbart. Han älskar att äta och kan även tänka sig att sova, fast bara lite grann, ibland. Det första jag tänkte när han kom ut var: “Han är så lik sin storasyster”. Han luktar underbart och skriker jättehögt och jag älskar honom bortom ord.

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?

8 Steps to Getting Feedback

Forget everything you know about agile, about any methods, about any kind of tool you’ve mastered. If there’s only one thing you should do, it has to be this: ask for feedback.

It doesn’t matter what you do or how you do it. If you don’t stop and ask the people you work with for feedback, you’ll never know exactly how bad you did until its too late.

It’s not complicated to get feedback, but it can be hard on you. Here is one way to do it.

First of all, you find a person who can provide you with some feedback. It helps if this is a person you trust. To this person, you present your desire for learning about how you’re doing, and ask if that person is willing to give you some feedback. If the answer is yes, you make sure you sit down in a comfortable environment where you both feel safe and relaxed. Then you ask for feedback on how you’re doing with something.

You could word it like this: “How do you think I’m doing when it comes to the TPS reports?” Then you sit silent and wait. And wait. You will always get feedback, even if the person you’re asking says nothing at all.

When you get the feedback, you might be tempted to think that you’re both done. You’re not. You might be tempted to blurt out a defense, because what you’ve just been told seems so offensive. Don’t. Instead, when you’ve heard what the other person thinks, stay silent. Think. Think about what that feedback might mean. Quietly formulate your interpretation of what that feedback really means, then tell it to the other person and ask if your interpretation is correct. Then go quiet again.

Either the person will say that your interpretation is correct, in which case you can say you’ve received the feedback. Or the other person will correct your interpretation. If this happens, you listen and think some more. Then you present your interpretation of the feedback again, this time incorporating the corrections you just received. Then you listen again, and repeat the process until your feedback giver tells you that you’ve understood things correctly.

Note that even complete silence can be treated this way. Silence as a response to a direct question is a kind of feedback, which you can try to interpret. If you do, it becomes doubly important to check your interpretation with the other person, because it now comes solely from within your own head.

If this procedure seems cumbersome, that’s only because it is. It’s not as slow as it seems when its broken down like this, however. Communicating clearly is hard work. We almost always go wrong in some way when we try to communicate with someone else, and it’s often due to the fact that we think we’ve understood the other person, when in reality we haven’t.

Do I always do it like this? No, and neither will you. In fact, if you’re like me, you’ll do like this far too seldom. Sometimes, we simply lack the energy to go through all the work that’s needed to communicate well. For me, that means I’m least likely to get good feedback when I most need it. It’s at times like those that I get into trouble, and that’s why I have to keep reminding myself that feedback can be scary, but that’s just because I don’t ask for it often enough.

To summarize:

  1. Find a potential feedback giver
  2. Ask for help
  3. Find a suitable environment
  4. Ask: How am I doing [with regard to something specific]?
  5. Listen.
  6. Think.
  7. Present your interpretation of the feedback.
  8. Repeat 5-7 until you get to hear you’ve understood correctly.
Will you give me some feedback? Was this post helpful to you?

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

A Visible Pile of Favorite Fieldstones

I’m a programmer at heart, even though I no longer program professionally. Why? Because I love to program. It gives me satisfaction. So, from time to time, I have to think up little hobby projects that are simple enough for me to handle, but engaging enough to still my lust for coding for a few hours. Here’s my latest one.

As a writer, my intuitive style of writing has always been to just sit down and start writing. From time to time, I suddenly boot up my Mac, fire up a plain text editor and start writing. Shortly thereafter, I have an article ready.

Sounds great, right? The problem is that it happens very infrequently. In fact, it happens so seldom that I’m still a pretty inefficient writer. If I was efficient, I would have published my first book by now, for example.

So, to increase my efficiency, I try to use Jerry Weinberg’s fieldstone method. In its essence, it is very simple. You make sure you always have pen and paper nearby to capture thoughts, ideas, quoutes, facts and other pieces of data and information that come your way. You work regularly to structure these “fieldstones”, and in the end use them to build your final text.

The method gets its name because, apparently, this is pretty much like building a fieldstone wall. When you build such a wall, you don’t go around looking for the next perfect stone that will fit right into the wall. Instead, you gather all stones that might be useful. Then, once you have a reasonable pile to work from, you build the wall using the stones. Without this method, you would probably be looking for the next perfect stone forever. Or at least for too long, like I do with my writing-only-when-inspired style of writing.

To be clear, using the fieldstone method does not mean writing about things I don’t feel inspired by. In fact, this is probably Jerry’s main lesson in his book about the method – Weinberg on Writing: The Fieldstone Method. Write only about things you want to write about is a piece of advice that makes perfect sense to me. For me, the fieldstone method is a way of making sure I have the stuff I need right by my side whenever I feel the inspiration coming on, like it just did when I decided to write this blog post.

Here’s my current inspiration. For handling my fieldstones, I use a tool called Dropbox for backup and synchronization. Dropbox makes sure I have my fieldstones handy on any computer I log on to. I write in a plain text editor, TextMate. However, today I realized that my collection of text snippets could use a bit more transparency. They lie there in their folder, all silent and waiting, and I sometimes forget that I need to wake them up from time to time and shuffle them around and improve them a bit. So I decided to pretend to be a programmer again for a short time.

I recently installed GeekTool, which I use to show Twitter postings from people that I follow right on my desktop. It occured to me that I would like my fieldstones to communicate with me in the same way. I want them to show up on my desktop, so that I am reminded of and inspired by them. My idea was to write a little script that could process my fieldstone collection, find the most recently changed files, then find the most recently added headlines in those files, and post them on my desktop. I mark up my texts with Textile, a very simple markup system. Headlines for example, always start with the h1, h2, h3 or h4 tag, followed by a dot and a space. I typically add a timestamp as the last part of the headline. So, it shouldn’t be too hard to filter out the most recent headlines and show them in a neat little desktop feed.

While programming this script, I started looking at my fieldstones with more awareness of how I structure them. I discovered that I use headlines without timestamps quite often. Because of this, I changed my mind and decided that simply listing the ten most recently edited fieldstone files was quite enough. While doing this, I also learned that something in my solution doesn’t handle Swedish characters well. For now though, my on-screen list is good enough, even though å, ä, ö, and some other esoteric characters are garbled. It reminds me of which files I’ve been working on most recently. A small thing, but I think it will help me find more fieldstones that fit well with the writing I’m most focused on right now.


#!/usr/bin/env ruby -wKU

require 'find'

fieldstone_folder = "PATH_TO_MY_FOLDER_ON_DROPBOX"
files_to_show = 10

fieldstone_files = []
recent_files = []

Find.find(fieldstone_folder) do |path|
  if FileTest.file?(path)
    fieldstone_files << [path, File.ctime(path)] unless /Fieldstones.tmproj/.match(path)
  end
end

by_change_date = Proc.new {|x, y| y[1] <=> x[1]}
paths_only = Proc.new {|i| i[0]}

recent_files = fieldstone_files.sort(&by_change_date).first(files_to_show).collect(&paths_only)

recent_files.each do |path|
  match_file_name = /#{fieldstone_folder}(.*)(?=\.txt)/
  file_name = match_file_name.match(path)[1]
  puts file_name
end

My Most Loved Mac Software

The Mac universe is filled with cheap (or free) little pieces of wonderful software. Here are some that I would not want to work without:

  • Quicksilver. Whenever someone asks me why I don’t just use Spotlight, I know that they still haven’t discovered Quicksilver’s ability to shuffle around files. Quicksilver is so seamless and useful that I feel handicapped whenever I push Ctrl+Space on a Mac without Quicksilver installed.
  • TextMate. A lovely text editor, which I use both for writing (I collect fieldstones using Jerry Weinberg’s “fieldstone method” and organize them in a TextMate project) and for manipulating text. For example, I sometimes export a list of people from our sales system. It usually comes out as a comma separated list of values. In TextMate, it’s easy to create a simple macro to wash away everything I don’t need, and keep only – for example – email addresses.
  • Dropbox. Speaking of gathering fieldstones. Because I wanted to access my fieldstones both from my Mac Powerbook and from my Linux machine at home, I set them up on a Dropbox account. Dropbox is very transparent, and simply shows up as a regular folder on both machines. Anything I drop in my Dropbox folder on one machine is automatically synchronized to the other machine as soon as I turn it on. Simply lovely.
  • 1Password. Remembering passwords is a nuisance. With 1Password, the need to remember them pretty much goes away. The program stores my passwords in an encrypted file, and automatically brings them up and fills out login forms when I tell it to. 1Password integrates even with the Safari 4 Beta I’m using. Whenever I want to login somewhere, I just click the “1P” button, and it digs out the right username and password combination for the site I’m currently on. Once in a while, I switch over to Firefox. When I do so, 1Password tags along and helps me out there too, since it integrates with that browser as well.
What makes these particular programs so great? Below are some of the properties I associate with these successful pieces of software.
  • Transparent. They never pop and disturb me, and when I use them, they simply do what I want them to do without any hassle.
  • Specialized and Useful. They aim to help me with some specific thing, and do it very well. They also solve actual problems.
  • Elegant. They do what they do with style. Because of this, I like them even more than I would if they where ugly but useful.
  • Fitness. These are all examples of software that integrates seamlessly with the system it lives in. For the developer, this could be less than positive if Apple decides the functionality fits in so well that it ought to be integrated into the operating system itself. Apple: if you do – buying the software from the people who made it or hiring the developers is the only right thing to do. We’re talking about software that is so good that it helps sell the Mac itself.
What’s your favorite Mac software, the kind you wouldn’t want to work without?

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?