Less is more

Posted on by
Svara

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.

web-ROTI

Posted on by
Svara

Jag brukar mäta nyttan med de möten jag håller med hjälp av ROTI (Return On Time Invested). Det är en enkel metod för att förstå om ett möte är bra, om det behöver förbättras eller rent av inte borde hållits över huvud taget. Det hela går ut på att alla deltagare efter mötet får gradera hur stor nyttan var på en skala från 1 till 5.

  1. Totalt meningslöst!
  2. Dåligt, jag hade kunnat använda den här tiden bättre
  3. OK, jag fick ut så mycket av mötet att det motsvarar tiden det tog
  4. Bra, gav mer nytta än det tog tid
  5. Fantastiskt, jag kunde inte använt tiden på ett bättre sätt!

Rent praktiskt kan man gå till väg på lite olika sätt, själv brukar jag rita en linje på white boarden där alla får sätta ett kryss där de vill.

Exempel på ROTI på white board

Ett annat sätt kan vara att låta alla hålla upp 1 – 5 fingrar. Medelvärdet kan vara bra att logga om man vill se hur återkommande möten, tex retrospectives eller sprintplaneringar utvecklats över tiden. Det är också bra att borra i högsta och lägsta värdet för att förstå vad som gjorde att de personerna upplevde mötet som mer och mindre nyttigt. Ett problem med att mäta ROTI på en tavla är att den som sätter första krysset kommer påverka de efterföljandes åsikt. För att testa om det blir någon skillnad har jag och några kolegor satt ihop en web-app där man gör sitt val utan att se de andras röst. Den finns på webroti.com och är gratis att använda. Första versionen är ganska enkel men om intresse finns kan den vidareutvecklas.

Ordning och reda

Posted on by
Svara

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

Posted on by
Svara

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

Posted on by
Svara

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.

Mindfulness

Posted on by
Svara

Jag zappade förbi ett program på TV igår som bestod av utdrag ur föreläsningar om hjärnan. Bland annat var det ett avsnitt med Åsa Nilsonne om mindfulness.

Enligt Åsa finns det tre grundstenar i mindfulness; medveten närvaro, medkänsla och att ta ansvar för sina handlingar i nuet. Jag började fundera lite runt hur det här passar ihop med programmering och utveckling. Det som framför allt fångade min uppmärksamhet var ett resonemanget runt att ta ansvar för sina handlingar i nuet. Det hela gick ut på att vi kan egentligen inte förändra vår historia eller kontrollera vår framtid utan bara nuet. Det är här och nu som vi kan påverka på riktigt och att vi måste ta ansvar för hur vi väljer att agera i nuet. Om vi vill förändra något hos oss själva så är det nu vi kan göra det, väljer vi att skjuta upp det tills i morgon har faktiskt inget förändrats.

När jag hörde det här associerade jag till utvecklare som inte tar ansvar för sin kod här och nu. Som inte skriver unit-tester, som inte refaktoriserar, som skriver allmänt slaskig kod osv. Jag tror det handlar mycket om att ta ansvar för nuet och insikten att det förändrar både historien och framtiden. Nuet är trots allt morgondagens historia och genom att göra rätt idag skapar vi förutsättningar för att kunna förändra vår kod i framtiden. Det verkar vara någon form av mognadsfråga; en del inser att problemet inte är att skriva kod som gör det den ska rent logiskt, det svåra är alla de andra egenskaperna.

Om mindfulness leder till att man mår bättre och är nöjdare med livet, skulle man kanske kunna tänka sig att vårt sätt att skriva kod också påverkar hur vi mår? Jag tycker i alla fall att det känns bättre att koda ordentligt.

 

 

 

Har halva befolkningen fel?

Posted on by
Svara

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!

Fokusera på mål istället för problem

Posted on by
Svara

Jag var på konferensen Agila Sverige nyligen. En av många intressanta diskussioner som dök upp handlade om att fokusera på rätt saker; mål (eller möjligheter om man så vill) istället för problem. Joakim Ohlrogge (@johlrogge) var inne på spåret att undvika alla former av negativa konstruktioner, både i hur man arbetar, kod osv. Lite exempel på rätt och fel

  • Hjälpa fattiga bönder i sydamerika att konvertera sin odling från coca-plantor till kaffe är ett bra sätt att stoppa knarkflödet till USA. Att bomba odlingarna med avlövningsmedel är dåligt.
  • Patterns är bra, anti-patterns är dåligt.
  • hasElements() är rätt, !isEmpty() är fel
  • Var nyligen på Post-hotellet i Göteborg. Där finns det gott om skyltar som säger vad man inte får göra men klart färre som säger vad som är OK. Fel!

Han menade kort sagt är det bättre att förstärka det positiva än att stoppa det negativa. Allt blir roligare, det går fortare mot målet och det blir bättre.

Jag kan inte annat än hålla med. Jag får lite olika associationer runt det här.
Först tänker jag på impro-teater där man pratar om att inte blockera. Där handlar det mycket om att se till att allt man gör ska leda vidare framåt och dessutom ge andra möjlighet att komma vidare.
Ur en beteende-vetenskaplig synvinkel skulle man nog säga att det är mycket effektivare att förstärka ett bra beteende när det inträffar än att försöka hindra ett dåligt.

Med fokus på problem så tror jag att det finns en risk att vi jobbar så här

  1. Identifiera alla problem
  2. Lös eller hantera problem
  3. Spring mot målet

Med målfokus hoppas jag att det blir mer av

  1. Identifiera målet
  2. Hur kommer vi snabbast dit?
  3. Spring

Med för stort fokus på problemen tror jag att det finns risk att vi löser problem i onödan som vi egentligen kunde ignorerat. Nu menar jag inte att vi ska sluta att fundera över risker helt men det skulle kanske inte göra något att tänka mer på målet och möjligheterna.

 

Ett evolutionärt förhållningssätt

Posted on by
Svara

Ju mer jag tänker på begreppet ”evolutionär utveckling” desto bättre gillar jag det. Många av de principer som finns i agil utveckling passar bra in kan jag tycka. Iterationer och prototyper är klockrent och även att fokusera på de problem som finns här och nu.

Evolution har lyckats skapa ganska fantastiska kreationer, det borde vara en princip som är värd att låta sig inspireras av.

Kreativitet och struktur

Posted on by
Svara

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.