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.

Hur tränar man gruppintelligens?

Om nu en grupps intelligens framför allt bestäms av hur bra individerna är på att kommunicera och ta in varandras reaktioner, hur kan man träna det? Ett ställe som jag hittat är improvisationsteatern. Det låter kanske svårt och tungt att ge sig in i men faktum är att det är raka motsatsen!

När man går en kurs i impro (i alla fall de lägre nivåerna) gör man övningar i grupp som till stor del handlar om att jobba med just att ta in andra och inte prata i mun. Man tränar också på att inte blockera sina egna eller andras idéer och vilket utvecklingsteam skulle inte tjäna på det? Dessutom är det fantastiskt roligt, mest som att leka faktiskt.

En del blir spontant ganska oroliga när man nämner impro-teater, men enligt en garvad impro-lärare som kört företags-arr med impro, påstår att han under sina 15 år bara stött på en eller ett par personer som efteråt inte tyckt det varit roligt. Jag har gått en del kurser och tycker personligen att det varit otroligt utvecklande och roligt. Jag tycker också att det fungerat bra i de grupper jag provat att köra enstaka övningar i eller som haft en heldag på en teater.

Så oavsett om du vill utvecklas själv eller tycker att din grupp behöver lyftas så ring närmaste impro-teater!

Om gruppintelligens

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.