← Essäer

Praxis för användning av ett personligt betyg för varje teammedlem i kontexten Scrum och SAFe

I den här artikeln planerar jag att berätta hur vi i vår praktik beräknar och tillämpar ett personligt betyg för varje teammedlem i Scrum under arbetet enligt ramverket SAFePersonlig blogg.

5 min läsning
TelegramOriginal
Praxis för användning av ett personligt betyg för varje teammedlem i kontexten Scrum och SAFe

I den här artikeln planerar jag att berätta hur vi i vår praktik tillämpar ett personligt betyg för varje teammedlem i Scrum under arbetet enligt ramverket SAFe

Förmodligen håller många med om att (särskilt i Ryssland) våra människor ganska ofta försöker arbeta (leverera slutprodukten inom ramen för sina kompetenser eller genom att skaffa nya) mindre och få mer betalt. I takt med företagets storlek verkar möjligheterna för detta växa direkt proportionellt. Med detta arbetar som regel olika HR-nära personer, som på alla sätt försöker bygga ett korrekt motivationssystem. Här hör också OKR:er och så vidare. I allmänhet verkar allt detta syfta till att balansera belastningen för var och en inom företaget och till komfort för alla berörda grupper av personer/team i företaget. I den här artikeln delar jag med mig av ett mått som jag själv har hittat på och tillämpar i teamet. Det gör det, som jag tycker, möjligt att komplettera HR- och OKR-insatserna för balansering av belastningen inom ett specifikt team eller att se obalansen, omvänt. Dessutom kan det mycket väl skalas upp till ett team av team, jag ser inget särskilt problem med det.

Således är det för mig som Scrum Master ibland ganska uppenbart att belastningen i teamet inte är balanserad, någon arbetar för två, någon gör ingenting (detta är extremformerna och, naturligtvis, ett allvarligt problem, men detta mått visar också inte bara extremformerna). En sådan situation hände mig och jag började fundera över vilket mått som skulle kunna belysa detta problem tydligt. Till slut utmynnade det i ett personligt betyg för varje teammedlem.

Innan jag beskriver själva måttet skulle jag också vilja nämna en mycket viktig, enligt min mening, idé. För närvarande är jag helt säker på den.

Mått bör byggas på de data som du ändå får. Att ta fram ett mått ska inte tvinga teamet att systematiskt lägga mer tid och anpassa sin process för värdeleverans efter själva måttet. Mer om detta ska jag försöka berätta i en av de följande artiklarna.

Så, ett exempel på ett konkret fall. Naturligtvis använder vi en tavla för att flytta User Stories genom statusar från DOR (Definition Of Ready) till DOD (Definition Of Done). Den är virtuell för oss (dvs. finns på internet via en länk. Teamet är också distribuerat och standuper sker via företagets Skype just med tavlan uppkopplad.

Det är bekvämt för en teammedlem att sätta sig själv som deltagare i en User Story, så att man vid användning av filtret för sig själv snabbt kan lämna kvar bara de historier som hen deltar i för tillfället (oftast använder vi detta filter på standuper).

Image

Här skulle jag också vilja förtydliga: det betyder inte att denna teammedlem inte kan delta i andra historier (om till exempel någon av teammedlemmarna på standupen ber om hjälp, kan hen mycket väl bli deltagare i en ny historia eller omvänt, om hen känner att hens deltagande inte behövs, kan hen sluta vara deltagare i någon historia.

Således, för att beräkna betyget för varje teammedlem, behöver vi titta på hur många SP varje teammedlem påverkar. I vårt fall påverkar Arkadij 29 SP (historier 1, 2, 5, 6), Tatjana påverkar 33 SP (Deltar i alla historier), Vasilij 23 SP (historier 1, 3, 5, 6).

Stängt (DOD uppfyllt) har Arkadij 5 av 29 SP, Tatjana 6 av 32 SP, Vasilij 5 av 23. Med sorteringen har jag kämpat ganska länge och kommit fram till följande formel för att jämföra två teammedlemmar (team[i] - en teammedlem och team[j] - en annan teammedlem):

Image

Enligt denna sortering får vi det aktuella betyget för teammedlemmarna i följande form.

  • 1:a plats. Vasilij (Uppfyllt 5 av 23)
  • 2:a plats. Arkadij (Uppfyllt 5 av 29)
  • 3:e plats. Tatjana (Uppfyllt 6 av 32)

Nu ska vi generera all data för sprinten. Låt oss föreställa oss att sprinten varar 5 arbetsdagar.

  • Dag 1

    Image

    Image


    1:a plats: Vasilij (nedbränt 0 av 23)
    2:a plats: Arkadij (nedbränt 0 av 29)
    3:e plats: Tatjana (nedbränt 0 av 32)
  • Dag 2

    Image

    Image


    1:a plats: Vasilij (nedbränt 0 av 23) dynamik(1->1)
    2:a plats: Arkadij (nedbränt 0 av 29) dynamik(2->2)
    3:e plats: Tatjana (nedbränt 0 av 32) dynamik(3->3)
  • Dag 3

    Image

    Image


    1:a plats: Vasilij (bränt 5 av 23) dynamik(1->1->1)
    2:a plats: Arkadij (bränt 5 av 29) dynamik(2->2->2)
    3:e plats: Tatjana (bränt 5 av 32) dynamik(3->3->3)
  • 4:e dagen

    Image

    Image


    1:a plats: Vasilij (bränt 8 av 23) dynamik(1->1->1->1)
    2:a plats: Arkadij (bränt 8 av 29) dynamik(2->2->2->2)
    3:e plats: Tatjana (bränt 9 av 32) dynamik(3->3->3->3)
  • 5:e dagen

    Image

    Image


    1:a plats: Vasilij (bränt 23 av 23) dynamik(1->1->1->1->1)
    2:a plats: Tatjana (bränt 24 av 32) dynamik(3->3->3->3->2)
    3:e plats: Arkadij (bränt 21 av 29) dynamik(2->2->2->2->3)

Genom att använda denna metrik kan man alltså samla personlig statistik för varje teammedlem och hjälpa dem att dra rätt slutsatser. Här ser vi till exempel att Vasilij planerade sin tid mycket väl från början (dvs. vid sprintplaneringen kom han överens med teamet om den arbetsmängd som han sedan faktiskt utförde.) Men samtidigt, kunde han på något sätt ha hjälpt andra teammedlemmar? Kanske inte, men det är värt att fundera över den frågan inför retrospektivet.

Hos Tatjana och Arkadij är problemet allvarligare. Det är uppenbart att de redan från början vid sprintplaneringen kom överens med teamet om att delta i alla stories och i praktiken inte kunde uppfylla åtagandena. Även orsakerna är värda att fundera över inför retrospektivet. Kanske bör man planera mindre för sig själv, kanske utöka kompetenserna för att hinna med allt planerat, andra lösningar är också möjliga.

På så sätt kan vi samla statistik inte bara för hela teamet och inte bara för en sprint, utan även för enskilda medlemmar i DEV TEAM över hela tiden och använda denna information för att ständigt förbättra teamet.

Avslutningsvis vill jag särskilt uppmärksamma det faktum att innan denna metrik används i teamet måste det redan finnas en tillräckligt hög tillitsnivå hos större delen av teamet. Jag skulle också rekommendera att lägga stor vikt vid det primära – frånvaron av övertid och en bekväm verksamhet.

Vi fokuserar på korrekt prognostisering av resultatet, inte på motivation att arbeta övertid för att ta 1:a plats. I slutändan syftar denna metrik till att förbättra planeringsförmågan hos varje enskild teammedlem.