Kreativ provokation

En metod för att främja kreativt tänkande är provokation. Tanken är att skapa en (förmodligen) orealistisk idé som i sin tur kanska kan ge upphov till en användbar idé. Det är viktigt att inte blockera sig själv genom att börja hitta problem med idéerna, utan fortsätt i rörelsen och försök hitta nya.

Några enkla metoder för att skapa provokation är

  • Vänd på något som vi tar för givet, t.ex ”Gör ett kylskåp som är varmt”
  • Överdriv, t.ex ”Alla har 100 telefoner”
  • Förvräng, t.ex ”Du röstar åt din granne”

Enkelt och användbart!

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.

Övning i att göra fel

Vi lär oss tidigt i livet att det är dåligt att göra fel och vi vill undvika det så långt som möjligt, så mycket att det hindrar oss att göra rätt genom att vi begränsar våra tankar och kreativitet. Inom improteatern tycker man inte bara att det är OK att göra fel utan till och med att det är bra eftersom det leder till nya och oväntade möjligheter. Det finns en övning där man tränar på att just göra fel för att det ska inte längre ska vara så läskigt.

The s-game

En grupp på ca 6 – 10 personer kan vara lagom, det är inte så petigt. Alla i gruppen ställer sig i två led och de två första spelar en enkel scen, det behöver inte vara så märkvärdigt det räcker om de bara pratar med varandra. De får varsin roll och en lokal, tex kund och bilmek på verkstaden och man väljer en bokstav som inte får användas, tex ”s”. Så fort någon säger ett ord med den förbjudna bokstaven i jublar alla och den som gjorde fel ställer sig sist medan nästa person i kön tar över.

Se även Att ha fel

Att ha fel

Hur känns det att ha fel? Precis som att ha rätt enligt Kathryn Schultz. Och visst stämmer det att det först är när vi inser att vi har fel som det känns jobbigt, fram tills dess kändes det prima – som om vi hade rätt! Det betyder att vi kanske ska vara lite försiktiga med att lite på den känslan och hitta andra sätt att försäkra oss om att vi gör rätt.

I vårt samhälle lär vi oss tidigt att vi är duktiga när vi har rätt och att det är dåligt att ha fel. I verkligheten har vi ganska ofta fel och det vore förmodligen bättre att lära sig acceptera det än att må dåligt varje gång.

Intressant är våra reaktioner när någon har en annan åsikt än vi själva, dvs när vi riskerar att ha fel. Våra försvarsmekanismer för att fortsätta att ha rätt är välutvecklade:

  • Först antar vi att den andre är okunnig och saknar information. Vi delar glatt med oss av denna för att den andre ska förstå.
  • Har den andre samma information som vi men fortfarande har en annan åsikt utgår vi från att det är en idiot, han/hon fattar helt enkelt inte.
  • Om vi vet att den andre både har information och är smart finns det bara ett alternativ kvar – han djävlas med oss! Förvränger verkligheten för att uppnå sina egna syften!
Vi har svårt att se möjligheten att det faktiskt går att ha en annan uppfattning baserat på samma information och det gör det svårt för oss att ta in andras åsikter.

Här kan man se Kathryn när hon talade på TED.

Produktägare är en ledarroll

Ett ganska vanligt problem som jag sett i företag som försöker införa scrum är att det saknas tydliga mål för utvecklingsteamet. Teamet är experter på att omvandla en story till funktionalitet men de behöver förstå vad målet är, var de ska. Det är svårt (eller omöjligt?) att få en grupp utan gemensamt mål att röra sig i rätt riktning och lösa sina uppgifter. Målen sätts av produktägaren och det främsta verktyget är bra stories.

Som produktägare är det superviktigt att göra en bra sprintplanering, det är ditt gyllene tillfälle att sätta mål, motivera och engagera. Dålig sprintplanering ==> stor risk att sprinten går dåligt. Ett riktigt bra team kan möjligen hjälpa upp situationen en del men som produktägare har du ett stort ansvar. Om du är en produktägare som kommer inglidande på sprintplaneringen med andan i halsen och har med dig en packe risiga stories från en halvdålig backlog ska nog fundera över om det inte går att göra på ett bättre sätt!

Självorganiserande team och effektivitet

Om man låter en grupp människor tillsammans lösa ett problem som dom vill, kommer de organisera sig på något sätt som är lämpligt för uppgiften och de individer som är med i gruppen. Sättet att organisera sig kommer vara olika för olika grupper och olika problem och det kommer förmodligen förändras över tid när gruppen utvecklas. Detta kallas självorganisation. I ett fungerande självoganiserande team finns de kommunikationsvägar och relationer mellan individer som är nödvändiga för att lösa problemet, det löser sig av sig själv så att säga.

Motsatsen till självorganiserande team är en hierarkisk organisation, dvs man organiserar sig som en pyramid med en chef ovanför och någon form av undersåtar under. Kommunikationsvägarna i en hierarkisk organisation går framför allt uppåt och neråt men i mindre utsträckning på tvären.

Om man mäter hur effektivt grupper med de två typerna av organisation löser problem kommer men se en del intressanta fenomen. Det visar sig att den hierarkiska gruppen snabbt kommer igång och blir effektiva, det finns en chef/ledare som kan peka med hela armen och få alla att börja jobba. Det sjävorganiserande teamet däremot kommer ha fullt upp med att bygga relationer och hitta roller vilket gör att de är trögare i starten. På längre sikt är dock förhållandet det omvända – det hierarkiska teamets effektivitet planar snart ut och det är mycket svårt att komma förbi den nivån, medan det självorganiserande teamets effektivitet inte har någon tydlig övre gräns utan fortsätter att öka med tiden.

Vad beror det på? Man kan tänka sig att snabb och effektiv kommunikation samt att ha rätt person på rätt plats är viktigt för effektiviteten. I en herarki måste dessa faktorer designas av någon överordnad person medan den funktionen så att säga är distribuerad över hela det självorganiserade teamet, ser man ett problem så löser man det.

Hur stort ska ett team vara? De mätningar som jag sett visar att 5 – 7 personer ger störst effektivitet per person. Man kan alltså inte skala upp ett självorganiserande team till så många personer, istället måste man hitta något sätt att få flera team att arbeta tillsammans. Mer om detta i ett kommande inlägg.

Tittar man på scrum är detta precis vad man vill uppnå, ett självorganiserande team. I scrum-världen brukar man också säga att ett team ska vara ca 7 personer och det stämmer ju bra med observationerna för ett maximalt effektivt team. Det här är alltså en av de faktorer som gör att scrum är ett effektivare sätt att arbeta på än traditionella lösningar.

Prata om dina idéer

På TED finns det ett lysande föredrag av Matt Ridley; ”When ideas have sex”, denna ständiga källa till inspiration!

Man kan fundera på när man tjänar på att inte prata med andra om sina idéer? Ibland kan det säkert vara nödvändigt att skydda en idé av tex patentskäl, men förmodligen gör det oftast mer skada än nytta. Min inställning är att en en idé sällan är den slutgiltiga, färdiga, ultimata lösningen på ett problem utan den mår bra av att knådas på och vidareutvecklas. Då tror jag att det är bättre att få nytt bränsle och infall från andra än att stänga in den i mitt eget huvud eller i en liten grupp. Fråga är också om vi har råd att inte utveckla våra idéer så långt det går?

Bilden av när ett system är färdigt

Under ett samtal igår med en kollega blev det tydligt hur lätt det är att prata om varandra när man har olika bild av det man pratar om. Min kollega har en bakgrund i ”klassisk” systemutveckling men är intresserad av agil utveckling och vet ungefär hur man gör. Vi pratade om ditten och datten runt utveckling men snart kändes det som det skavde i våran kommunikation och jag insåg att vi har helt olika bild av när ett system är klart.

Min bild av klassisk systemutveckling är att det finns en beställare som vill ha ett system, man skriver (i bästa fall) krav, bygger systemet, testar att det gör som man tänkt sig och driftsätter det. Klart! Efter driftsättning går man in i en förvaltningsfas då ny funktionalitet ska klämmas in om det går. Om man tittar på hur användbart systemet är under den här tiden så är det faktiskt oanvändbart (ingen affärsnytta) fram till dess att det levererats och driftsats, dvs när det är färdigt. Under förvaltningen finns det en oro för att det inte ska gå att bygga på ny funktionalitet eftersom det inte var planerat för detta från början. Det finns en tydlig punkt när systemet är klart.

I det agila sättet att resonera säger man istället att systemet alltid (i alla fall efter varje iteration) ska vara i så bra skick att det går att leverera, dvs all funktionalitet som hittills implementerats ska vara testad, dokumenterad osv. I varje iteration lägger man till lite ny funktionalitet som gör systemet lite bättre (adderar affärsnytta). Kunden kan när den så önskar produktionssätta systemet med den funktionalitet som finns just nu. I någon mening betyder det att systemet hela tiden är färdigt (frågan är bara vilken funktionalitet som implementerats), alternativt kan man säga att systemet aldrig är klart (det går alltid att lägga till mer funktionalitet). Att lägga till ny funktionalitet i ett senare skede är inget exceptionellt utan görs på samma sätt som under den initiala utvecklingen, utvecklingstakten varierar bara över tiden. Det finns kanske en början men inte nödvändigtvis något tydligt slut, bilden av när systemet är klart är mycket mer dynamisk.

Av förklarliga skäl blev det lite snurrigt i diskussionerna när vi hade så olika bild av hur det går till. Alltså; se till att ni har samma underliggande modell när ni diskuterar något!

Säg ja, skapa kreativitet!

Det finns massor av tekniker för att på ett strukturerat sätt skapa idéer och vara kreativ. Den absolut enklaste och som du dessutom kan börja använda rakt av är att helt enkelt alltid svara ”ja!” på alla förslag.

En vanlig reaktion när jag föreslår detta är något i stil med ”Det går ju inte! Förslaget kan ju vara något som jag inte vill göra eller inte tycker om!”. Min tanke är att bara för att man börjar med att säga ja betyder det inte att man faktiskt behöver fortsätta att säga ja, man kan ändra sig. Efter det initiala ”ja”-et kan man börja ställa frågor och diskutera förslaget och kanske sluta i ett helt annat beslut. Poängen är självklart att du uppmuntrat den som levererade förslaget att komma med fler, du har skapat förutsättningar för kreativitet. Man kan fundera på vad alternativet är? I bästa fall lyckas du leverera någon form av neutralt svar men mer troligt något som uppfattas som negativt och som kräver övertalning.

Om du inte tror att det här är viktigt så är det ju enkelt för dig testa, säg ja en dag och se vad som händer.