Sprid kunskaperna i teamet

Efter att ha läst om arbetsgrupper där medlemmarna jobbar lite för separerat från varandra för dra nytta av ett teams sanna potential frågar en anonym läsare:

"Det vore intressant att läsa lite tips på hur man når dit. Om man nu är en grupp där man är lite för specialiserade. Vad gör man för att sprida kunskaperna på ett bra sätt?"

Här är några handfasta tekniker som gör att kunskap i ett mjukvaruutvecklingsteam sprids. Men först lite kort om själva förändringen i sig.

Grunden i all förändring är att behovet av förändring är känt. Så, om inte alla i teamet känner till att och varför det är en bra idé att jobba tajtare tillsammans måste ni prata om det. Hur skulle ni veta om ni jobbade bättre tillsammans? Vilka faktiska aktiviteter skulle ni göra? Hur skulle det kännas? På vilket sätt skulle resultatet bli bättre? Vilka nackdeler skulle ni se? Hur skulle ni hantera dem?

Så, några konkreta saker ni kan göra.

1. Planera aldrig ensam.  Klyschan är sann: planen är inget, planeringen är allt.  Ett team planerar sitt arbete tillsammans dels för att skapa en bättre plan, dels för att man genom att samarbeta med planeringen ökar sannolikheten att planen kommer att efterlevas. Tänk efter. Vilken plan är du själv mest benägen att följa - den som du fått släppt i knät, eller den du själv varit med att utforma. Tänk också på detta: vilken plan tror du att du bäst förstår - den någon annan gjort, eller den du själv är medskapare till? Du vet svaren. Av dessa anledningar deltar hela teamet och produktägaren aktivt i såväl releaseplanerings- som sprintplanerings-workshops. Scrum-team är små, så hela teamet arbetar tillsammans under planeringen. Att dela upp sig i mindre grupper under planeringen är kontraproduktivt. Visst kan planering vara över snabbare, men till priset av fragmenterade bilder av helheten.
2. Använd visuell styrning. Visuell styrning handlar om att få upp planen på väggen, så att den blir extremt synlig och extremt lättillgänglig. Sprintbackloggen är en självklar kandidat för visuell styrning. Istället för ett Excelblad eller tjusigt webbverktyg sätter man upp de utvalda behoven från produktbackloggen på väggen, tillsammans med de aktiviter som behöver genomföras för att implementera dem. Delar man sedan upp tavlan med linjer i block som visar mängden aktiviteter som väntar, är påbörjade, respektive avslutade så får teamet en direkt inblick i om man arbetar effektivt tillsammans för att göra klart värdefulla funktioner, eller om flaskhalsar och isolerat arbete leder till att uppgifter blir gjorda men inga resultat nås. 
3. Gemensamma designmöten. Sprintplanering, dagligt möte och sprintuppföljning är inte de enda tillåtna mötena i Scrum. Teamet bokar in alla möten de behöver för att arbeta effektivt tillsammans. Gör de det inte tar Scrum Mastern täten och förklarar varför gemensamma arbetsmöten är en smart grej att göra. Under ett gemensamt designmöte träffas en del av eller hela teamet för att arbeta med detaljplaneringen av något moment i sprinten. Självklart kör man även designmöten tvärfunktionellt, så att lösningen kan belysas från såväl programmerarnas, testernas och andras perspektiv.
4. Gemensamma granskningsmöten. Alla har nytta av att få ett eller flera par fräscha ögon som granskar ens arbetsresultat. Det behöver inte vara av någon från samma disciplin som en själv, tvärtom är det ofta nyttigt att försöka förklara vad man gjort och hur man tänkt för någon som inte är drabbad av samma bakgrund som en själv.
5. Parprogrammering. Inte direkt älskat av alla, om man ska uttrycka det milt, men vansinnigt effektivt när det väl tillämpas av personer som tror på värdet av att skriva kod tillsammans. Effekten är omedelbar: delad kunskap inte bara om hur koden fungerar, utan också om varför den ser ut som den gör.
6. Hjälp experter bli rådgivare. Även effektiva team kan kidnappas av en specialist. Det händer när en nischkompetens finns hos endast en eller två personer i teamet, och allt arbete inom det området måste gå genom experterna. Om dessa personer blir en flaskhals begränsas teamets resultat av hur mycket denna trånga sektor kan släppa igenom. Genom att hjälpa dessa personer att dels sprida sin kunskap, dels förklara för andra hur de kan jobba för att underlätta för experten kan effektiviteten i teamet öka. 
7. Hjälps åt under demon. Under sprintuppföljningens första del, demon, turas teammedlemmarna om att demonstrera en sak som implementeras under sprinten. Övriga antecknar synpunkter från åhörarna under tiden.
8. Återblickar varje sprint. Ett team som har svårt att arbeta tillsammans, och finner sig glida isär i två eller fler faktiska delgrupper, eller kanske bara har individuellt arbete, lägger extra fokus på denna fråga under sprintåterblicken. Som ett minimum pratar man om problemet, och det räcker med att någon tycker att situationen hämmar teamet för att det ska vara ett problem. Kan man försöker man vrida och vända på problemet för att hitta något man kan göra för att få teamet att smälta ihop mer effektivt.

OK. Det var några handfasta tips att pröva om man finner sig i en arbetsgrupp som vill jobba mer samspelt tillsammans, som ett riktigt team. Det är också en lista som visar varför Scrum Master-rollen inte är en lätt syssla. Inget av tipsen i listan ovan är rocket science, likväl görs de ofta inte. Att förstå varför inte, och justera saker och ting så att de börjar hända är Scrum Masterns ansvar. Det betyder inte att det är förbjudet för andra att ta sig an dem - tvärtom. Ett av kännetecknen hos ett fungerande team är att det är ok för vem som helst att kliva fram och ta ansvar för förbättringar.