Less is more

Jag har ett projekt hemma där jag samlar in data från vårt värmesystem som sedan kan visas i diverse grafer via en websajt. Jag har tidigare använt en gammal laptop som webserver men tänkte att jag skulle se om det går att använda en raspberry pi istället. Raspberry pi är en enkel och billig dator jämförbar med en mobiltelefon i kapacitet och avsevärt mycket långsammare än laptopen.

Inte helt oväntat gick det för sakta för att vara användbart. Vad gör man då? Ena vägen är den uppenbara, byt tillbaks till den gamla fungerande laptopen. Den andra, vägen jag valde, är att se om det inte går att lösa problemet på något annat sätt. Efter lite om-design visade det sig att det fungerar utmärkt, användarupplevelsen är till och med bättre än den var tidigare!

Vad är nu sensmoralen av detta? Jo, begränsningar kan driva fram kreativitet. Genom att ta bort något var jag tvungen att hitta nya lösningar som faktiskt gjorde att helheten blev bättre än det jag hade innan. Obegränsade resurser skapar inte nödvändigtvis kreativitet.

Ordning och reda

Den här artikeln handlar om poängen med att ha ordning och reda. Min tanke är att ju mer symmetri och ju färre överraskningar det är desto bättre. Det minskar belastningen på vårt arbetsminne och minskar risken för misstag, speciellt under stress.

I ett exempel från levande livet fanns fyra testmiljöer och en produktionsmiljö. På det stora hela var miljöerna ganska lika med avseende på konfiguration men skiljde sig åt i prestanda. Två av test-miljöerna användes för test i teamen och de andra två för integrationstest.

I produktionsmiljön fanns fyra noder, två för publika applikationer och två för interna med failover mellan noderna för redundans. Till noderna fanns tre olika databaser kopplade. Testmiljöerna för integrationstest hade samma upplägg medan teamens testmiljöer bara hade en nod (av kostnadsskäl) som alla applikationer kördes på.

Alla nodnamn, databaskopplingar osv fanns väl dokumenterat och nedskrivet på en wiki där man klart och tydligt kunde se vad olika resurser hette. Alla förutsättningar fanns alltså för att det skulle bli rätt när något skulle uppdateras.

Så långt inget speciellt konstigt. Det jag tycker är intressant med det här fallet är namngivningen av noder och databaser och vad det ledde till. Av historiska skäl (förmodar jag) var namnen inte alltid logiska. Några exempel:

  • I produktion hette noderna prod1, prod2, prod3 och prod4 med interna appar på prod1 och 2 samt externa på prod3 och 4. I integrationstestmiljö 1 fanns samma symmetri (test1-test4) medan man i integrationstest2 (test5-test8) valt att kasta om noderna som interna och externa appar fanns på. Noderna test7 och 8 hade interna appar medan test5 och 6 hade externa.
  • Databasservrarna hade postfix i form av _dev, _test och _prod för att visa vilka miljöer de höre till. Själva databaserna hade en ”2″ på slutet av namnet för att visa att de hörde till miljö 2, dvs team-testmiljö2 eller integrationstestmiljö2. Om integrationstestmiljö 1 hade en databas som hette ”Kalle” hade integrationstestmiljö 2 en databas som hette ”Kalle2″. Märkligt nog fanns en databas som användes av en ”2″ miljö som hade 1 på slutet. Dessutom fanns en databasserver som inte följde mönstret och hade ett avvikande namn.

Egentligen var det inte så många avvikelser men jag tror att det fanns minst en i varje miljö utom i produktion.

Vad blev resultatet? Konkreta exempel på när det blivit fel under en vecka är att databasen som hörde till en ”2″ miljö blev uppdaterad i tron att den hörde till ”1″ miljön och att en lastbalanserare konfigurerades fel mot integrationstestmiljö2 eftersom noderna var omkastade. Inga allvarliga problem som inte gick att lösa, men det gick åt några timmar och skapade förvirring.

Vi människor är bra på att se mönster och symmetrier, det är en av våra styrkor. Låt oss då inte jobba mot den här egenskapen utan utnyttja den istället. Gör det lätt att göra rätt! Även om det var fullt möjligt att titta på wikin och se vad en resurs hade för namn så ökade det den kognitiva belastningen på ett onödigt sätt. Arbetsminnet, som redan är en bristvara hos utvecklare, måste lagra ännu lite mer data. Effekten blir fler fel och tröttare människor, förmodligen inte något någon eftersträvar.

Att underlätta kommunikation

Hos den kund där jag för tillfället sitter har man skrivbord med en skiva i bakkant av skrivbordet, dvs så det blir som en liten vägg bakom bildskärmen. Skivan är så hög att man inte ser över den utan att ställa sig upp. Lokalens utformning är sådan att vi mer eller mindre är tvingade att ha skrivborden i två rader med tre skrivbord bredvid varandra i varje rad.

Kommunikationen i teamet fungerade inte så bra så vi bestämde oss för att ta bort skivorna. Nu kan alla se alla och agera på de signaler som kommer från de andra i teamet.  Vi har visserligen gjort andra förändringar också men jag tror att det upplevda avståndet mellan individerna minskat och därmed ökat kommunikation och viljan att hjälpa varandra. Under alla omständigheter fungerar teamet mycket bättre idag.

Intressant nog tycker jag också att kommunikationen med det andra teamet, som sitter i samma lokal, också förbättrats. Förmodligen beror detta också på att vi har bättre visuell kontakt även med dom, men kanske också på att individerna i båda teamen blivit bättre på att vara  team-medlemmar.

Inom en snar framtid ska vi byta till smalare skrivbord vilket borde minska avståndet än mer. Framtiden får utvisa om det gör någon skillnad.

En bättre användning av frågorna på dagligt scrum

Läser man en bok om scrum (i princip vilken som hellst) så står det att frågorna man ska svara på när teamet har dagligt scrum är:

  • Vad gjorde jag igår?
  • Vad ska jag göra idag?
  • Har jag några hinder?

Resultatet är att i väldigt många team går man ett varv runt teamet och varje person svarar på frågorna. Klart!

Vad kan vara fel med det?

Problemet är att den första personen måste tala om vad han/hon planerar att göra under dagen utan att ha någon förståelse av hela teamets situation. Hur ska man då kunna ta ansvar för helheten?

En bättre lösning är istället att först gå ett varv och låta alla svara på frågorna som beskriver det nuvarande läget, dvs ”Vad gjorde jag igår?” och ”Har jag några hinder?”. Efter det kör man ett varv till och nu är det enkelt för alla att se vad som är viktigast och svara på frågan ”Vad ska jag göra idag?”.

Det här sättet att arbeta uppmuntrar till samarbete och motverkar individualism.

Har halva befolkningen fel?

Självorganiserande team och teamarbete är något som är näst in till självskrivna byggstenar när man pratar om agila arbetssätt. Själv brukar också jag predika det självorganiserande teamets lov. Halleluja!

Men så en dag såg jag ett TED-talk av Susan Cain: ”The power of introverts”. Det handlar om att mellan 1/3 och hälften av befolkningen befinner sig på den introverta halvan av en skala som går mellan introvert och extrovert. En introvert person är inte blyg, hämmad eller liknande, utan fungerar bättre och får fler av sina kickar i sitt eget tankelandskap, till skillnad till extroverta personer som hellre vill interagera med andra. Susan säger att normen idag är att personer förutsätts vara extroverta och att vi skapar utbildning, öppna kontorslandskap osv baserat på denna norm, fast det passar en stor del av befolkningen dåligt. Introverta personer gör alltså ett bättre jobb om de får sitta och fundera i lugn och ro på sin kammare.

Intressant blir det om man applicerar den här kunskapen på våra agila metoder. Vad i våra arbetssätt passar introverta personer sämre? Spontant dyker saker som team, sprintplaneringar osv som vi gör tillammans, upp i mitt huvud. Är det så att scrum tex, egentligen bara fungerar bra på den halva av befolkningen som är extroverta? Är det i så fall bra att tvinga in de introverta personerna i det arbetssättet? Ska bara extroverta personer vara med och jobba agilt? Kan vi hitta ett annat sätt att arbeta som passar alla bättre eller borde vi hitta en speciell arbetsmetod för introverta personer?

Många frågor och få svar. Jag tycker dock det är intressant och det skulle kunna förklara varför en del personer faktiskt inte tycker att det här med scrum är något vidare, eller att en del team verkar ha svårt att lyfta? Det här är ett område som kräver mer grävande!

Kreativitet och struktur

Jag är intresserad av kreativitet och vad som gör att vi kommer på nya idéer. När jag pratar om kreativitet så tänker jag inte på galna konstnärer som gör tokiga saker utan processen att hitta nya idéer, egentligen helt oberoende vad det är för problem som ska lösas. För mig sker den mesta kreativiteten i vardagen utan att vi egentligen tänker på det, när vi löser problem på jobbet, hemma eller vad det kan vara.

Jag är också intresserad av improvisation och känslan av att skapa något här och nu utan att veta var vi är på väg eller ens om det kommer att gå bra. Jag har hållit på en hel del med improviserad dans (Lindy Hop) och även improvisationsteater. Gemensamt för de båda är att som deltagare har man ingen aning om vad som kommer hända de närmaste minuterna, man är bara övertygad om att det kommer gå bra. Dessutom är man övertygad om att det kommer vara roligt och berikande. Improvisation är så klart inget annat än kreativitet i realtid. Hur kommer det sig att det fungerar?

En viktig faktor är att det finns ett ramverk som skapar struktur och begränsningar. I Lindyn finns bla en uppsättning steg och rörelser som man förväntas använda sig av, det finns ett språk man kommunicerar med mellan förare och följare och andra strukturer som sätter en ram. Inom denna ram är det sedan fritt att improvisera. Inom impro-teatern finns också en rad begränsningar som man bestämmer runt en scen. Det kan tex vara vilka personer som är med i scenen eller andra regler som sätter yttre gränser för hur skådespelarna får agera. Poängen med de här begränsningarna är att det är de som gör det möjligt att improvisera, dels för att deltagarna vet ungefär vad de kan förvänta sig av varandra men framför allt för att det gör det enklare att vara kreativ.

Jag vill alltså hävda att det är lättare att vara kreativ om det finns begränsningar än om alla alternativ är öppna. Jag tror också att detta gäller generellt när vi behöver vara kreativa, inte bara inom dans och teater. Tittar man tex på mjukvaruprojekt där man använder någon agil metod, så är en user story något som skapar ett ramverk och det borde alltså i så fall främja kreativitet. Ur den synvinkeln är alltså syftet med en user story inte bara att beskriva en funktion, utan den bör också vara formulerad på sätt som gör att det går att vara kreativ när den implementeras.

Intressant är också att ett sätt att vara kreativ på är att ifrågasätta, vända och vrida på begränsningarna. Ibland är bästa lösningen på ett problem att ändra på själva problemet.

Medmänsklighet

Medmänsklighet och empati är något som de flesta tycker är bra och som vi gillar hos våra medmänniskor, men som vi kanske mest ser som en egenskap bland många andra. Det verkar dock vara mer än så.

Chade-Meng Tan, Jolly Good Fellow på Google (= head of personal growth) menar att medmänsklighet är roligt och ger lycka, dvs att vi som individer mår bra av att visa medmänsklighet mot andra. På Google har man tagit fasta på det här och bygger sitt företag runt denna tanke, man ser ett mönster som upprepar sig. En liten grupp anställda brinner för något som de börjar arbeta med, fler och fler blir intresserade och om det blir stort nog blir det officiellt och kommer ut i världen. Detta är inte nödvändigtvis applikationer som går att sälja utan kan tex vara olika sociala projekt så som att samla in pengar för att bygga ett sjukhus i en avlägsen del av Indien, utbildning eller katastrofhjälp.

Det låter ju trevligt att personalen kan lägga tid på att vara medmänskliga, men hur tjänar man pengar på det? Tan menar att medmänsklighet leder till

  • effektiva ledare – ledare som är ödmjuka och arbetar för något större (”greater good”). Detta är, enligt James Collins (Good to great), receptet på den typ av ledare som har förmågan att förändra ett företag från ”goof” till ”great”.
  • inspirerande anställda – inspirerande anställda inspirerar varandra vilket leder till en god spiral av inspiration, kreativitet och initiativ och därmed ett effektivt företag.
För att utveckla ett företag mot medmänsklighet anser han att man ska
  • bygga en kultur som inspirerar till något större
  • främja självbestämmande
  • stötta de anställda i sin personliga utveckling

I en RSAnimate-film pratar man också om att empati är våran starkaste drivkraft, men att vi kanske idag byggt vårt samhälle och organisationer så att vi inte utnyttjar detta på ett bra sätt. Forskning visar att människan är skapad som en social varelse som vill tillhöra en grupp och känna tillgivenhet, inte som agressiva och egoistiska individualister.

Dalai lama lär ha sagt: ”If you want others to be happy, practice compassion. If you want to be happy, practice compassion.”

TED-talk med Chade-Meng Tan

RSAnimate – The empatic civilisation

Evolutionär utveckling

Jag pratade med en kollega här om dagen om iterativ utveckling. Jag insåg att vi hade helt olika bild av vad det är. För mig betyder det att vi hela tiden försöker förbättra det system vi bygger genom att lägga till mer och mer funktionalitet i små iterationer. I varje iteration tittar vi på senaste lösningen och utvärderar om den blev bra genom att klämma och känna på den. Blev det inte bra så gör vi om det, dvs vi har en feedback loop som hela tiden leder till ett förbättrat resultat. Min kollega däremot var helt med på den första delen, att ta små steg framåt, men återkopplingen saknades. Och så är det nog i många projekt, man har på förhand planerat vad som ska göras i varje iteration och därmed slagit sönder feedback loopen.

Jag undrar om inte ”evolutionär” utveckling skulle kunna vara ett bättre uttryck som också skulle kunna peka på att det bara är de livskraftigaste lösningarna som överlever?

Arbetsgrupper och faser

Man har gjort modeller som beskriver hur arbetsgrupper utvecklas och när de är effektiva. Två av dessa är FIRO (Fundamental Interpersonal Relations Orientation av Will Schults), utvecklad under Koreakriget och IMGD (An Integrative Model of Group Development av Susan A. Wheelan) som UGL byggs runt. Om man applicerar modellerna på ett scrumteam kan man dra en del slutsatser om hur man bör agera i olika situationer. Jag ska inte försöka mig på en komplett beskrivning av modellerna men ska försöka göra en tolkning.

Gemensamt för båda modellerna är att gruppen utvecklas genom ett antal faser, i FIRO finns 3 medan IMGD har 5. Min bild är att de två första faserna är ungefär samma i modellerna medan IMGD har delat upp FIROs tredje fas i två. IMGD har dessutom en extra avslutningsfas som inte behandlas i FIRO men som kan vara intressant att beakta när man delar upp ett team. Faserna är enl IMGD:

  1. Tillhörighet och trygghet – individerna är artiga och försöker orientera sig bland de andra. Gruppen behöver en styrande ledare som sätter tydlig mål.
  2. Opposition och konflikt – gruppen försöker förstå mål och skapa kultur och struktur vilket leder till konflikter. Ledaren fungerar som stöd och coach.
  3. Tillit och struktur – relationerna börjar präglas av tillit. Roll- och arbetsfördelning samt mål börjar falla på plats och kommunikationen fungerar. Ledarens roll är mindre framträdande.
  4. Arbete och produktivitet – intensivt och effektivt arbete. Roller är klara och kommunikationen öppen, ingen energi behöver läggas på konflikter. Ledaren är en expertresurs.
  5. Avslut – i ett fungerande team ger och får man feedback samt utvärderar vad man gjort vilket hjälper individerna att arbeta effektivt i andra grupper.

Enligt modellen kommer gruppen utvecklas genom faserna i ordning (det finns inga genvägar) och om man lägger till eller tar bort medlemmar eller utsätter gruppen för andra stora förändringar riskerar man att den backar till en tidigare fas.

Det är först i fas 3 och framför allt 4 som ett team är effektivt och det är alltså där vi vill vara så mycket som möjligt. En slutsats är att man ska vara försiktig med att förändra teamets sammansättning och andra förutsättningar. En suboptimering jag sett alltför ofta är organisationer som flyttar personer mellan teamen varefter belastningen ändras i olika projekt. Förmodligen når dessa team aldrig fas 3 och 4 utan är kvar i de mindre effektiva faserna 1 och 2.

Det finns en risk att en grupp fastnar i någon av faserna och kan behöva hjälp att komma vidare och där kan ledaren hjälpa till. Jag har använt begreppet ”ledare” ovan och man kan fråga sig vem det är i tex scrum. Jag skulle vilja påstå att det är en kombination av scrummastern, som tar de mer coachande delarna och produktägaren som står för mål och mening.

Sammanfattningsvis behövs arbetsro för att ett team ska bli effektivt, det tar ett antal sprintar innan saker faller på plats. Försök hitta en lunk där teamet kan hitta en skön rytm.

Mer om IMGD

Checklistor

Ett verktyg som borde användas mer är checklistor. Det är billigt, enkelt och effektivt. Syftet med en checklista är att påminna om alla steg som ska utföras så man inte glömmer något, inte beskriva hur man gör. Checklistan ska alltså användas av en expert och inte vara en komplett beskrivning för nybörjaren.

Checklistan utvecklades av flygindustrin under tidigt1900-tal efter en olycka då en testpilot glömde ta bort en spärr på rodren före start varpå han störtade och dog. Man insåg hur lätt det är att glömma ett enkelt handgrepp, även om man är expert och vet att det ska göras och hur stora konsekvenserna kan bli. Sedan dess är checklistor an viktig del av flygets säkerhetsarbete, de används varje gång man flyger.

Checklistor är användbara inom alla områden och har visat sig vara fantastiskt effektiva, ett exempel är sjukvården. Under 2007-2008 gjorde WHO ett experiment där man införde checklistor för operationer. Listan består av 19 punkter, varav 3 är 2 minuters pauser för att skapa reflektion. Punkterna är inte bara av medicinsk karaktär utan handlar också om kommunikation. Checklistan testades på 8 sjukhus runt jorden, både i I- och U-länder och resultatet är minst sagt imponerande: komplikationerna minskade med 36% och dödsfallen med 47%. Det är årtiondets effektivaste ”behandling”!

I en grupp kan checklistor leda till att teamarbetet och diciplinen förbättras. Bla beror det på att kommunikationen förbättras och att det ger alla (t.ex en sköterska i ett kirurg-team) en möjlighet att ifrågasätta ”stjärnans” (kirurgen) agerande.