Hej Bloggen! Först av allt så är jag glad för att jag fått många positiva reaktioner kring nyheten om att jag startat en blogg och det första inlägget jag gjorde. Tack för det och det sporrar naturligtvis att blogga vidare!
I denna post tänkte jag behandla detta med tvärfunktionalitet. Det går att vända och vrida på det på flera sätt och jag tar några av dem här. Det är ett djupt ämne och meningen är inte att skriva en roman om ämnet så jag nöjer mig med delar som jag tycker är viktigst
Tvärfunktionalitet går att dela in på minst 3 olika nivåer:
- Individer
- Team
- Team of Teams - dvs flera team
Om vi börjar med individer så finns det ett relativt känt begrepp som kallas "T-shaped Individials". Det innebär att en individ har djup kunskap inom ett område men kan även två andra områden relativt bra. Detta illustreras med hjälp av bokstaven T.
Som exempel kan en individ vara riktigt bra på att utveckla kod men kan även testa kod såväl som skriva krav. Personligen brukar jag undvika att etikettera individer som till exempel utvecklare eller testare utan enbart prata om teammedlemmar. Det är min rekommendation att du gör också. Prata om attribut av ett team mer än roller i teamet.
Denna typ av individer (eller personer) som kan flera områden är bra eller snarare nödvändigt att ha i ett team. Det har flera viktiga funktioner. Ett av dem är att teamet blir mer robust om det finns ett överlapp mellan teammedlemmarna i deras kunskaper. Om någon är borta så finns det fler personer som kan göra jobbet. Silotänket försvinner i förmån för tvärfunktionalitet. Om någon skulle kalla dig "Silokrossaren" så är det en stor komplimang! :)
En annan minst lika viktig är att samarbetet mellan personer och inte minst pararbete möjliggörs på bättre sätt, det leder i sin tur till bättre kvalitet. Jag har sett utvecklingsteam använda något som kallas "Mob Programming" vilket stimulerade detta riktigt bra. Då utvecklar hela teamet tillsammans och det stimulerar naturligtvis detta med tvärfunktionalitet.
Om du är i en miljö där flera team samverkar så rekommenderar jag även att sikta på ett överlapp mellan teamen. Dvs att du har mer än ett team som kan ett område eller domän. Detta av samma skäl som ovan. Din organisation blir mer robust och det främjar samarbete mellan team.
"Så menar du att alla skall kunna allt? Det går ju inte!" - Det är en fråga och påstående som inte är helt ovanliga när ämnet om tvärfunktionalitet diskuteras.
Svaret är "nej" på den frågan, det handlar istället om överlapp. I samband med att jag gick "Train the Trainer" utbildningen för Phoenix Project DevOps Simulation (länk i botten på sidan) så nämnde Paul Wilkinson (utbildaren) en princip han kallade 1:3, 3:1 metoden. Så vad innebär det?
Jo, det kan förklaras med följande exempel
- I ett team: En (1) person skall kunna göra tre (3) olika arbetsuppgifter, tre (3) personer i teamet skall kunna göra samma (1) arbetsuppgift
- Flera team: Ett (1) team skall kunna arbeta i tre (3) olika domäner, tre (3) team skall kunna arbeta med samma (1) domän
Detta är något jag också rekommenderar alla mina nyvunna bloggläsare att sträva emot. Sannolikt innebär det ett aktivt förändringsarbete då det inte är helt ovanligt att organisationer har komponentteam, dvs ett team är specialiserat på en komponent eller domän, men inget annat team kan samma sak.
Det är även rimligt att ta avstamp i hur er Roadmap ser ut och analysera vilka områden växer/krymper över tiden och var behövs mer/mindre kompetens. Med det i ryggen kan små inkrementella förändringar göras istället för ett stort lappkast som är betydligt sämre alternativ.
Jag har sett denna tvärfunktionalitet fungera väldigt bra, men min upplevelse är att det inte kommer av "sig självt". Det är något man måste jobba på!
Nä, nu får det räcka. Hejdå bloggen för denna gång!
Länkar