Innehållsförteckning
- Förord
- Vilket problem är det vi försöker lösa?
- Hur hade vi löst detta manuellt?
- Vem blir glad för det vi just nu håller på med?
- Ska vi fixa symptomet, gå runt det eller ta bort problemet?
- Vad är en annan lösning på det här problemet eller ett annat sätt att gå runt det?
- När vi gör det här valet, vad är det vi väljer bort?
- Vilka frågor har vi inte ställt än?
- När, var och hur kan vi se om det blivit bättre?
- Hur skulle underbart se ut?
- Hur ska vi dema detta?
- Är det här fakta eller känsla?
- Hur vet vi efteråt att detta var ett bra möte?
- Hur ser asymmetrin ut?
- Hur kan jag hjälpa till att nå dagens mål?
- Vad skulle Pippi ha gjort?
- Om mig
- Notes
Förord
Den här boken är helt enkelt en liten samling av frågor som kan vara värda att ställa i olika situationer när vi håller på med team- och/eller utvecklingsarbete. Frågorna är till för att väcka diskussioner som tillför värde till det vi håller på med och för att förhindra att vi går i många av de fällor som vi trots allt ofta hamnar i. Varje kapitel tar upp en fråga, hur vi kan ställa den och vilken diskussion som kan föras runt den.
Jag har ett ganska kort “attention span” och har svårt att hålla koncentrationen över en längre tid. Därför har jag en förkärlek till att läsa korta böcker och gärna sådana som har kapitel som är upp till 10 sidor långa. Valet när jag skriver en egen bok faller därför också på att skriva en kort bok med korta avsnitt - som förhoppningsvis i sin isolation är användbara.
En del av frågorna är tänkta att ge oss en lite annorlunda tvist på hur vi tänker just nu medan andra är tänkta att helt omkullkasta vilken riktning vi rör oss i för tillfället. Båda två kan vara användbara oavsett i vilket läge vi befinner oss och ska ses som olika verktyg att ta till.
Man måste inte läsa boken i någon speciell ordning för de olika kapitlen bygger inte på varandra över huvud taget. Läs precis som du vill!
Detta är bara några frågor som man kan använda sig av. Självklart finns det tusentals andra frågor och jag hoppas dessa inspirerar dig att komma på dessa och börja använda dem i din vardag. Om man väl kommer på att det är nyttigt att fråga så kommer resten av bara farten - det är i alla fall min förhoppning med boken.
Och om någon undrar om fem av frågorna är “Varför” så är svaret nej.
Vilket problem är det vi försöker lösa?
Ofta hamnar man i ett läge där man ganska snabbt går in i en lösningsdiskussion. Men om vi då inte har rätt problemställning framför oss, hur vet vi då att vi löser rätt problem? Fel problem löst på rätt sätt ger oss inte mycket mer värde än träning på att skapa bra lösningar. Då är det i stället bättre att lösa rätt problem på fel sätt, kanske lite långsammare eller mindre effektivt. Eller rätt problem på rätt sätt.
Frågan kan också användas om en diskussion avviker från det syfte den från början hade. Det kan självklart hända att diskussionen efter att ha avvikit från den första vägen nu är helt rätt, men genom att ställa oss frågan så kan vi åtminstone ta ett aktivt beslut om så är fallet. Då tar vi också verkligen ett medvetet beslut att fortsätta i den riktningen. Om vi istället vill gå tillbaka till diskussionen där den avvek från vägen så är det bra om vi gör det så snart som möjligt utan att slösa mer tid.
Hur hade vi löst detta manuellt?
När vi ska utveckla en viss funktionalitet och inte riktigt kan sätta fingret på hur det ska fungera så kan vi ställa oss frågan hur det hade kunnat göras med t ex papper och penna eller på annat manuellt sätt. Då behöver vi ställa oss ett antal frågor längs vägen och får se problemet ur en annan synvinkel och med andra begränsningar som kan hjälpa oss att hitta våra ramar.
Kanske är det också ett sätt att kraftigt förenkla saker som vi annars hade komplicerat, bara för att det går med dagens systemstöd och digitalisering. Att hålla saker så enkla som möjligt sänker kostnaden både för utveckling och underhåll av ett system, så länge det fungerar bra med omkringliggande funktionalitet och system.
Vem blir glad för det vi just nu håller på med?
Att ha mål och syfte med det vi jobbar med är viktigt. En del av detta är att veta vem vi gör något åt. Eller ännu mer riktat, “vem blir glad för det vi just nu håller på med?”. För mig handlar detta till en stor del om förutsättningar för empati, att veta om och lära känna den som använder den produkt eller tjänst som vi utvecklar. Om vi har verklig empati för vår tänkta användare kommer vi också att ta beslut med detta i grunden och låta dessa vägleda oss mot en förhoppningsvis bättre användarvänlighet och användbarhet. Inte bara teknisk excellens.
Så ställ denna fråga, ta reda på svaret och börja resan mot att verkligen känna empati för era användare.
Ska vi fixa symptomet, gå runt det eller ta bort problemet?
Allt jobb vi gör handlar väl egentligen om att lösa något slags problem eller uppfylla ett behov? Det kan t ex vara ett behov som finns hos en kund eller ett problem som ligger internt som behöver angripas för att lösa detta behov. Eftersom det här är en så stor del av vad vi gör varje dag så fokuserar vi självklart också på att lösa just problem. Eller rättare sagt, vi jobbar troligen mest med att lösa symptom som uppstår på grund av djupare problem som vi har. Alla symptom måste heller inte lösas utan en del kan istället rundas. Eller så kan vi gå hela vägen och ta bort problemets grundorsak och då ofta även det synliga symptomet. Så vi har hela skalan att arbeta med och måste inte alltid välja den lösning som sitter som närmaste reflex, d.v.s. att bara fixa själva symptomet.
När vi identifierar ett symptom eller ett problem kan vi därför ställa oss frågan “Ska vi fixa symptomet, gå runt det eller ta bort problemet?”
Om vi ställer oss frågan och har diskussionen om vad symptomet är, vad grundproblemet är och vad det har för konsekvenser om de kvarstår så kan vi sedan ta ett informativt medvetet beslut vilken väg vi ska välja.
Det kan också vara bra att se hur många liknande saker som dyker upp då det kanske inte är någon idé att ta bort ett symptom med låg påverkan som bara inträffar en gång. Då ska man snarare gå runt det. Men om det istället är något som händer ofta eller som har allvarlig påverkan, då vill vi verkligen gå till botten med det hela och ta bort grundproblemet.
Vad är en annan lösning på det här problemet eller ett annat sätt att gå runt det?
Ofta hittar vi en lösning på ett problem och är nöjda med det. Det kanske vi också ska vara men ibland ska vi utmana oss själva lite mera och fråga oss “Vad är en annan lösning på det här problemet eller ett annat sätt att gå runt det?”
Om vi alltid låser in oss på första bästa lösning försitter vi chansen att utforska en större del av lösningsrymden. Vi tappar en del av vår experimentanda och kommer troligen inte att komma på en lika bra lösning som vi hade gjort om vi övervägt flera alternativ. Om vi har två olika lösningar eller sätt att gå runt problemet så kanske en mix av dessa två utgör det slutliga resultatet. De olika förslagen som vi tagit fram förstärker alltså varandra och ska inte ses som bittra konkurrenter.
Detta tankesätt ska dock inte få oss att analysera sönder saker istället för att skapa snabba experiment. Vi ska både utnyttja snabba experiment samt en större bredd av idéer och uppdatera lösningen efter hand.
När vi gör det här valet, vad är det vi väljer bort?
Vi gör val och tar beslut hela tiden när vi jobbar i organisationer och team. Ja, även som individer. Vi tar ett beslut och i en del fall så har vi grundat det på fakta, alla är med eller åtminstone inte emot och vi antecknar beslutet och dess grund om det behövs. Har vi kommit så långt med våra beslutsprocesser så kan vi vara ganska nöjda, för det är längre än många team och organisationer kommer.
Men… men det finns ytterligare en fråga som vi kan ställa oss som kan hjälpa oss att bli ännu bättre. Vi kan fråga oss “När vi gör det här valet, vad är det vi väljer bort?”
För när vi väljer en sak väljer vi automatiskt bort allt annat och bland detta “allt” finns troligen ett par bra alternativ och troligen ett bättre alternativ. Vi har inte tid att gå till botten med alla alternativ så ofta är det bra att komma till ett relativt snabbt beslut, testa det i praktiken och ändra beslutet om det inte blev som väntat (eller bättre).
Även om vi har detta tankesätt så kan vi frigöra nya idéer genom att ställa oss den öppnande frågan om vi har fler svar i den outforskade lösningsrymden som vi borde tänka på just nu. Bara för att vi hittar fler lösningsförslag behöver vi inte fullfölja dem, men vi tar ett aktivt beslut med den informationen till hands.
Vilka frågor har vi inte ställt än?
Om en diskussion hamnar i en återvändsgränd kan man lätt tro att man uttömt alla alternativ för att komma vidare. Då kan ett sätt att försöka hitta ut ur gränden vara att ställa sig frågan “Vilka frågor har vi inte ställt än?”
För om vi verkligen kört fast, då är det förmodligen en annan väg vi måste ta. Just den vägen kanske går att hitta via en annan fråga, istället för att försöka hitta ännu flera svar på de frågor vi redan ställt. Precis som i många andra avseenden i livet behöver vi ibland ta ett steg tillbaka för att komma två framåt.
När, var och hur kan vi se om det blivit bättre?
Inom både äldre och nyare arbetssätt har en framgångsfaktor varit att identifiera och genomföra förbättringar för att hela tiden bli bättre på det vi gör och göra bättre saker. Nu när utvecklingsfarten och hjulen snurrar snabbare än någonsin är det än mer viktigt att göra detta på ett effektivt och produktivt sätt. Vi är ganska bra på att ta fram vad vi vill förbättra och ofta ganska duktiga hur vi ska genomföra det konkreta förbättringsförslaget.
Det vi inte är så bra på är att följa upp och mäta resultatet av vår förändring. Om vi inte gör detta för att veta om vi ska behålla eller kasta bort förändringen tar vi heller inte något medvetet beslut om förändringen var bra eller inte. Den kanske stannar kvar trots att den inte var så bra eller den kanske försvinner trots att den gav värde.
Frågan vi ska ställa oss när vi beslutar om en förändring eller experiment är “När, var och hur kan vi se om det blivit bättre?” Detta ger oss tre konkreta saker att hänga upp uppföljningen på och gör det lättare att också göra den.
Hur skulle underbart se ut?
När vi sitter och funderar över ett problem eller en lösning så finns det många saker som begränsar oss. En sådan sak är att vi ser lösningen nära vår nuvarande situation eller något som vi tidigare sett. Vi kommer då att missa chansen att se resten av lösningsrymden som är i stort sett oändligt stor. Även om vi inte kan komma på oändligt många och bra lösningar kan vi åtminstone sträcka oss till att titta efter “Hur skulle underbart se ut?”
Denna fråga leder oss in på ett positivt mindset som kanske knuffar undan en del av de begränsningar som vi sätter på oss själva och vår situation. Även om vi förmodligen inte kommer att gå vidare och implementera Underbart så kommer det att ge oss en annorlunda input, en målbild att sträva efter och någonting att längta efter.
Det kan handla om hur vårt system ska se ut eller fungera, hur det ska kännas att vara på en dag på jobbet eller hur våra processer ska fungera. Frågan fungerar i alla dessa fall och kan bidra till att man lyfter blicken den lilla bit som behövs för att se bortom krönet som vi ofta fastnar på när vi tänker i våra vanliga banor.
Hur ska vi dema detta?
När ett team utvecklar något i iterationer brukar de avsluta varje iteration med att visa upp den nya funktionalitet som de byggt. Detta kallas ibland lite slarvigt för demo. Det är helt enkelt en ny version av produkten som antingen kan släppas på marknaden eller som behöver fler funktioner eller bättre kvalitet för att få komma ut.
När man påbörjar en iteration och ska utveckla något kan det ibland vara svårt att sätta fingret på hur man kan testa att det är färdigt, d.v.s. klart att ges till användarna. Då kan vi fråga oss frågan “Hur ska vi dema detta?”, d.v.s. visa upp för våra beställare och/eller användare för att de ska kunna verifiera om det är vad de vill ha.
Ett team kan ha hamnat i fällan att vara uppdelade på utvecklare och testare och då händer det ibland att utvecklarna tagit fram en ny funktion som testarna inte vet hur de ska verifiera. Antingen är det tekniskt svårt eller så är det inte en så påtaglig funktionalitet man byggt. Om man då från början har ställt oss frågan hur vi ska lägga fram detta på demo kan vi dels sätta rätt omfattning och bygga på ett sådant sätt att vi verkligen kan testa och visa upp på demon.
Vi bygger med andra ord in kvalitetssäkring när vi bygger vår produkt, vi testar inte in den i efterhand.
Är det här fakta eller känsla?
När vi ska ta beslut i vår organisation eller team behöver vi någon slags input och kriterier att ta själva beslutet på. Ibland har vi gjort en förstudie, “proof of concept” eller experiment för att få fram ett underlag. Men oberoende av vilket underlag vi har så tas ibland beslutet av den som har störst makt i rummet eller via någons starka känsla. Ingen av dessa är speciellt bra ur ett vetenskapligt perspektiv och om vi framhåller oss själva som rationella varelser är det kanske inte åt det hållet vi vill gå.
Så när det är dags att ta ett beslut och vi lägger fram argument kan vi fråga oss “Är detta fakta eller känsla?” Om det är en känsla, ska vi då använda den? Om vi ändå väljer att göra det, gör det ändå medvetet och var överens om vilka grunder som beslutet tas på.
Frågan kan egentligen ställas i vilken diskussion som helst där man som individ känner att man själv eller någon annan använder känslor som argument och ställer dem mot fakta eller sak. Det kanske är så att känslan ska väga tyngst, men återigen behöver vi vara medvetna om att det är det valet vi gör.
Vi har som personer ganska lätt att lyssna på känslor och bortse från fakta, vilket kan vara både en styrka och en svaghet. Men använd då frågan och hjälp er själva att hantera problemet och använda rätt verktyg vid rätt tillfälle.
Hur vet vi efteråt att detta var ett bra möte?
Om vi har en organisation som inte är rätt uppsatt så kommer vi att ha ganska mycket möten för att lösa de problem vi har med informationsöverföring och beslutsfattande. Det bästa sättet att lösa detta är troligen i de flesta fall att göra om organisationen till att arbeta i smidigare värdeflöden samt decentraliserade beslut och därav minska behovet av många möten. Nu är detta inte möjligt att göra alls på vissa ställen och inte på kort sikt på andra så vi får istället ta till andra knep - t ex förbättra de möten vi har.
Ett traditionellt och ganska fastslaget sätt att driva bra möten har länge varit att ha en agenda och följa den. I agendan finns mötets syfte och mål och hur man ska förbereda sig. Detta kan vara en bra början men jag vill slå ett slag för ytterligare en sak som kan vara bra att ta till.
Ta några minuter i början på mötet och diskutera frågan “Hur vet vi efteråt att detta var ett bra möte?” och anpassa mötet efter denna diskussion. Det ger alla chansen att komma med synpunkter på vad de vill få ut av möten och inte minst att klargöra vad gruppen eller teamet vill uppnå med mötet. Inte bara vad en viss individ vill uppnå. Genom att se framåt och föreställa sig att mötet blev bra öppnar vi upp för positivt tänkande och kan visualisera de bra beteenden och förlopp som vi vill se under mötets gång. Det ger oss en mycket bättre möjlighet att utgången också blir bättre, dvs att vi når fram till både målet och att mötet som i sig blev bra.
Använd också en stund i slutet av mötet till att reflektera över hur mötet gick. Vad gick bra och vad gick mindre bra? Vad ska vi ta med oss till nästa möte och vad ska vi förbättra? Att ställa sig frågan är inte något som vi behöver göra varje möte, men väl så ofta att vi utforskat den och kanske även kommit till en platå där den inte längre hjälper oss att bli bättre.
Hur ser asymmetrin ut?
Få saker i vår vardag är symmetriska. När man tittar på risk kontra belöning för en viss aktivitet eller satsning så ligger troligen risken eller belöningen klart högre viktat. Detta är också något som vi kan fråga oss oftare när vi tittar på t ex hur lång tid en aktivitet kan tänkas ta eller hur mycket något kommer att kosta oss.
Ställer vi oss frågan “hur många saker kan få detta att gå snabbare och hur många saker kan få detta att gå långsammare?” har vi åtminstone börjat undersöka saken. Relativt ofta är det vår magkänsla som avgör detta, d.v.s. vi lägger ett ankare på säg X timmar (eller kronor) och lägger på / drar av t ex 25 % för att ha ett spann att röra oss inom. Men ofta är det inte lika stora chanser att uppgiften går snabbare som risker att den går långsammare.
Ganska få saker kan få något att gå snabbare än planerat men risken att det ska gå långsammare är nästan oändlig. Av dessa oändligt många saker har nästan alla en mycket liten sannolikhet, men eftersom det finns så många kommer troligen ett par att hända i alla fall. Där av bildas en asymmetri som vi borde ta hänsyn till.
Ytterligare en sak som späder på asymmetrin är att saker kan ta som snabbast noll tid men som långsammast nästan oändligt. Detta gör att flera av de saker som ligger i den asymmetriska svansen kan leda till en oproportionerlig kostnad.
Hur kan jag hjälpa till att nå dagens mål?
Om man som Scrum master, coach eller ledare jobbar mer med teamet än i teamet så känner man kanske inte alltid att man gör konkret nytta. Då kan man behöva ställa frågan hur man kan hjälpa övriga i teamet att gå i land med dagens mål och förhoppningsvis kunna göra något som hjälper teamet. Så ställ frågan “Hur kan jag hjälpa till att nå dagens mål?”, t. ex. på ett teammöte eller i ert teamrum.
Jag tror också att den frågan är bättre att ställa som teammedlem än att bara uttrycka att man inte har något att göra. Det senare uttrycket är något negativt men frågan är framåtriktad och med en positiv underton. Det kan också sätta tonen för de svar man får och i förlängningen hur mycket man kan bidra till teamets mål.
Vad skulle Pippi ha gjort?
Som en sista utväg om vi inte alls vet vad vi ska göra i en situation och inte har något att förlora kan vi ställa oss frågan “Vad skulle Pippi Långstrump ha gjort?”
Denna fråga stammar från böckerna där Pippi1 kan göra saker som ingen annan kan och går långt utanför ramarna för vad som är möjlig och rimligt. Och tror på sig själv när hon gör det. Det är kanske just därför som hon lyckas. Det är också därför vi kan ställa oss frågan, för att komma bortanför de ramar som hållit oss tillbaka från att lösa det problem vi för tillfället sitter med.
Om mig
Jag, Björn Tikkanen, är “Utvecklaren som aldrig släppt kodandet men som nu mest och helst jobbar med agilitet i team och organisationer.”
Jag är en agilist, Scrum master, agil coach och utvecklare med bred kunskap inom systemutveckling vilket gör att jag ser både kundens och de utförande personernas behov och jobbar utifrån detta.
På senare tid har jag jobbat mer och mer med team och sett hur frågor kan hjälpa till och hur viktigt det är att jobba med en kultur där det är OK att fråga i stort och smått. Detta vill jag fortsätta att utbilda och utveckla mig inom och att skriva små böcker som denna är ett steg på vägen.
Mitt eget företag heter pragmatiX och för mig är det en bra plattform att göra det jag tycker om, hjälpa individer och organisationer som vill ha hjälp och putta ett fåtal andra som kanske inte ens frågat i rätt riktning.
Jag vill dessutom bidra till ett öppet och generöst samhälle och lägger därför gärna ned lite extra tid för att kunna bjuda på mina erfarenheter och kunskaper.
Notes
1I en första version av den här boken var det Chuck Norris som var huvudperson i frågan med tanke på de memes som finns på internet om hans bravader. Men efter att ha tänkt lite så bytte jag snabbt över till Pippi som är en klart bättre positiv rollmodell, både för att hon är kvinna och för att hon är mindre våldsam.↩