Pratica dell'uso del rating personale di ogni membro del team nel contesto di Scrum e SAFe

In questo articolo ho intenzione di raccontare come, nella nostra pratica, applichiamo il Rating personale di ogni membro del team in Scrum durante il lavoro secondo il framework SAFe

Probabilmente molti saranno d'accordo sul fatto che (soprattutto in Russia) le nostre persone abbastanza spesso cercano di lavorare (consegnare il prodotto finale nell'ambito delle proprie competenze o tramite l'acquisizione di nuove) il meno possibile e di guadagnare di più. Con la dimensione dell'azienda le possibilità per questo, sembra, crescano in modo direttamente proporzionale. Di questo, di regola, si occupano vari addetti alle risorse umane, che in ogni modo cercano di costruire un sistema di motivazione corretto. Qui rientrano anche gli OKR e così via. Nel complesso, sembra che tutto questo sia finalizzato all'equilibrio del carico di ciascuno all'interno della corporazione e al comfort di tutti i gruppi di interesse/team della corporazione. In questo articolo condividerò una metrica che ho ideato personalmente e che applico nel team. Essa permette, come mi sembra, di integrare gli sforzi degli HR e degli OKR nell'equilibrio del carico all'interno di uno specifico team o di vedere lo squilibrio, rispettivamente. Inoltre, può benissimo scalare anche al team di team, non vedo particolari problemi in questo.

Così, a me come Scrum Master a volte è abbastanza evidente che il carico nel team non è equilibrato, qualcuno lavora per due, qualcuno non fa nulla (queste sono forme estreme e, naturalmente, un problema serio, ma questa metrica mostra anche non solo le forme estreme). Mi è capitata una situazione del genere e ho riflettuto su quale metrica avrebbe potuto evidenziare chiaramente questo problema. Alla fine, si è tradotto nel rating personale di ogni membro del team.

Prima di descrivere la metrica stessa, vorrei anche sottolineare un'idea molto importante, a mio avviso. Al momento ne sono assolutamente certo.

Le metriche devono essere costruite sulla base dei dati che già ricevete. Ottenere una qualche metrica non deve costringere il team a spendere sistematicamente più tempo e ad adattare il proprio processo di consegna del valore alla metrica stessa. Ne parlerò più in dettaglio in uno dei prossimi articoli.

Dunque, un esempio di un caso concreto. Naturalmente, usiamo una board per spostare le User Stories attraverso gli stati da DOR (Definition Of Ready) a DOD (Definition Of Done). Da noi è virtuale (cioè situata su internet a un link. Il team è anche distribuito e gli standup si svolgono tramite Skype aziendale proprio con la trasmissione della board.

Al membro del team è comodo mettersi come partecipante di una User Story, così che usando il filtro su se stesso si possano rapidamente lasciare solo le storie a cui partecipa in quel momento (il più delle volte usiamo questo filtro negli standup).

Qui vorrei anche dare una spiegazione: questo non significa che tale membro del team non possa partecipare ad altre storie (se, per esempio, allo standup qualcuno dei membri del team chiede aiuto, può benissimo diventare partecipante di una nuova storia o viceversa, se sente che la sua partecipazione non è richiesta, può smettere di essere partecipante di qualche storia.

Così, per calcolare il rating di ogni membro del team, dobbiamo vedere su quanti SP influisce ogni membro del team. Nel nostro caso Arkadij influisce su 29 SP (storie 1, 2, 5, 6), Tat'jana influisce su 33 SP (partecipa a tutte le storie), Vasilij su 23 SP (storie 1, 3, 5, 6).

Chiuso (DOD completato) per Arkadij 5 su 29 SP, per Tat'jana 6 su 32 SP, per Vasilij 5 su 23. Con l'ordinamento ho faticato abbastanza a lungo e sono arrivato a questa formula di confronto tra due membri del team (team[i] - un membro del team e team[j] - un altro membro del team):

Secondo questo ordinamento otterremo il rating attuale dei membri del team nella forma seguente.

• 1° posto. Vasilij (Completato 5 su 23)
• 2° posto. Arkadij (Completato 5 su 29)
• 3° posto. Tat'jana (Completato 6 su 32)

Ora generiamo tutti i dati per lo sprint. Immaginiamo che lo sprint duri 5 giorni lavorativi.

• 1° giorno
  

  

  
  1° posto: Vasilij (bruciato 0 su 23)
  2° posto: Arkadij (bruciato 0 su 29)
  3° posto: Tat'jana (bruciato 0 su 32)
  
• 2° giorno
  

  

  
  1° posto: Vasilij (bruciato 0 su 23) dinamica(1->1)
  2° posto: Arkadij (bruciato 0 su 29) dinamica(2->2)
  3° posto: Tat'jana (bruciato 0 su 32) dinamica(3->3)
  
• 3° giorno
  

  

  
  1° posto: Vasily (bruciati 5 su 23) dinamica(1->1->1)
  2° posto: Arkady (bruciati 5 su 29) dinamica(2->2->2)
  3° posto: Tatiana (bruciati 5 su 32) dinamica(3->3->3)
  
• 4° giorno
  

  

  
  1° posto: Vasily (bruciati 8 su 23) dinamica(1->1->1->1)
  2° posto: Arkady (bruciati 8 su 29) dinamica(2->2->2->2)
  3° posto: Tatiana (bruciati 9 su 32) dinamica(3->3->3->3)
  
• 5° giorno
  

  

  
  1° posto: Vasily (bruciati 23 su 23) dinamica(1->1->1->1->1)
  2° posto: Tatiana (bruciati 24 su 32) dinamica(3->3->3->3->2)
  3° posto: Arkady (bruciati 21 su 29) dinamica(2->2->2->2->3)
  

Pertanto, utilizzando questa metrica è possibile accumulare statistiche personali di ogni membro del team e aiutarlo a trarre le giuste conclusioni. Ad esempio, qui vediamo che Vasily ha pianificato il proprio tempo in modo molto accurato fin dall'inizio (cioè durante la pianificazione dello sprint ha concordato con il team il volume di lavoro che ha poi effettivamente svolto.) Ma, allo stesso tempo, avrebbe potuto in qualche modo aiutare gli altri membri del team? Forse no, ma vale la pena riflettere su questa questione prima della retrospettiva.

Tatiana e Arkady hanno un problema più serio. È evidente che fin dall'inizio, durante la pianificazione dello sprint, hanno concordato con il team di partecipare a tutte le storie e di fatto non sono riusciti a rispettare gli impegni. Anche sulle cause vale la pena riflettere prima della retrospettiva. Forse vale la pena pianificare meno per sé, forse ampliare le competenze per riuscire a portare a termine tutto il pianificato, sono possibili anche altre soluzioni.

Pertanto, possiamo accumulare statistiche non solo per l'intero team e non solo per uno sprint, ma anche per singoli partecipanti del DEV TEAM per tutto il tempo e utilizzare queste informazioni per il miglioramento continuo del team.

In conclusione, vorrei richiamare particolare attenzione sul fatto che prima di utilizzare questa metrica nel team deve esserci già un livello di fiducia sufficientemente alto nella maggior parte del team. Inoltre, consiglierei di porre grande enfasi su ciò che è primario: l'assenza di straordinari e un'attività confortevole.

Ci concentriamo sulla corretta previsione del risultato, non sulla motivazione a fare straordinari per occupare il 1° posto. In definitiva, questa metrica è finalizzata al miglioramento della capacità di pianificazione di ogni singolo membro del team.