Fortsätt till huvudinnehåll

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.

Kommentarer

Populära inlägg i den här bloggen

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…