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.

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.

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.

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.

Gruppintelligens

Går det att mäta en grupps intelligens och vad är det i så fall?

Måttet på intelligens för en individ beskriver i princip dess förmåga att lösa en rad problem av varierande typ. Detta mått går utmärkt att föra över på en grupp där man istället mäter hur bra gruppen kollektivt löser problem, alltså går det bra att mäta en grupps intelligens.

Frågan om vad som påverkar gruppens intelligens dyker raskt upp. Är det summan av individernas intelligens? När man mätt gruppintelligens har man funnit följande:

Svag korrelation:

  • Motivation
  • Sammanhang
  • Group satisfaction (vad är ett bra svenskt ord?)
  • Individernas intelligens

Stark korrelation:

  • Medeltalet av individernas förmåga att läsa andra människors reaktioner och känslor
  • Jämnhet inom gruppen att delta i konversationer (alla pratar ungefär lika mycket)
  • Andelen kvinnor (man tror att detta egentligen är kopplat den första punkten)

Vad kan vi lära oss av det här? Jag förmodar att om vi vill skapa intelligenta grupper ska vi titta på social kompetens och förmåga till kommunikation. Kod-primadonnor som är fantastiska på att programmera men saknar social förmåga gör alltså nödvändigtvis inte att en grupp blir bättre på att lösa sina problem.

Professor Thomas W. Malone forskar inom området.