Dilemma dello Scrum Team

Premessa

La metodologia agile SCRUM

La metodologia di gran lunga più diffusa è SCRUM, che nasce addirittura alla fine degli anni ’80 dall’esperienza di Ken Schwaber e Jeff Sutherland (due dei 17 firmatari del Manifesto Agile).

SCRUM prende il nome dalle mischie del rugby, dove tutti gli uomini spingono insieme nella stessa direzione. Questo è il principio alla base di SCRUM: fare in modo che tutti i membri del team lavorino coordinati verso il medesimo obiettivo.

Scrum Team

--------------------------------------------------------------------------------------------------------------

Dilemma Scrum Team

Se l'azienda da una parte utilizza una organizzazione Classica e gerarchica per alcuni aspetti della vita aziendale (ad esempio distribuzione bonus e benefit) mentre da un'altra parte utilizza una metodologia Agile Scrum per il conseguimento degli obiettivi allora all'interno dello Scrum Team potrebbe predominare una "politica non cooperativa".

Mentre incentivando l'intero Scrum Team (in proporzione al ruolo) per il raggiungimento degli obiettivi allora si avrebbe una condivisione del merito e del rischio creando un politica fortemente cooperativa.

Dal punto di vista dell'azienda sarebbe a costo zero nel senso che i bonus / benefit forniti sarebbero equivalenti a quelli attuali, quello che cambierebbe è la condivisione.

• politica cooperativa: "politica incentivante dello Scrum Team", assegnando un bonus a tutto lo Scrum Team, in funzione del ruolo, in base al raggiungimento degli obiettivi del gruppo.

predomina su una:

• politica non cooperativa: "politica incentivante del singolo/i membro dello Scrum Team" (PO, Scrum Master, Developer) assegnando un bonus in base ad obiettivi personali.

Dilemma Scrum Developer

In questo articolo si dimostrare questa ipotesi

• politica cooperativa: "politica incentivante del Developer Team", assegnando un bonus a tutti in base al raggiungimento degli obiettivi del gruppo.

predomina su una:

• politica non cooperativa: "politica incentivante del singolo/i membro del Developer Team", assegnando un bonus al Developer che realizza più Story Point).

In questa puntata della serie Silicon Valley viene introdotto il concetto di Scrum.

Politiche aziendali per incentivare i Developer

Analizziamo le seguenti politiche aziendali in relazione ai Developer dello Scrum Team.

1) Politica cooperativa: i bonus sono riconosciuti in relazione al raggiungimento degli obiettivi del gruppo. I bonus non devono essere assegnati in relazione ad obiettivi personali.

• Nel team si instaura un rapporto collaborativo poiché il membro del proprio Team non è visto come un avversario per il raggiungimento dell’obiettivo.
• I membri del gruppo mantengono una velocity bene o male constante nei vari sprint.
• Si utilizzano pratiche dell’Extreme Programming come il Pair Programming e si crea affiatamento.
• Si ha una maggiore condivisione dell’Informazione.

2) Politica non cooperativa: i bonus sono riconosciuti in base al maggior numero di Story Point realizzati dal Developer.

• Nel team si instaura un rapporto poco collaborativo.
• Difficilmente vengono utilizzate pratiche dell’Extreme Programming come il Pair Programming.
• Più facilmente il Developer si concentra sullo sviluppo delle proprie Storie che si è assegnato e non fornisce un grande supporto agli altri membri del team.
• Esiste una minore condivisione dell’Informazione.

Sia nella (1) Politica cooperativa che nella (2) Politica non cooperativa si conoscono le mosse dell'avversario in relazione al numero delle storie prese in carico. Però non si conosce il “grado di collaborazione con l’altro membro del team”.  

Politica Non Cooperativa

Ciascun Developer decide quanto aiutare o meno l’altro al fine di massimizzare la propria strategia.

Ad ognuno di loro vengono date due scelte: collaborare, oppure non collaborare. Collaborare vuol dire aiutare l’altro nello sviluppo della sua Storia

• Se solo uno dei due collabora ed aiuta nello sviluppo l'altro, chi ha collaborato realizza 3 Story Point mentre l'altro realizza 8 Story Point.
• Se entrambi aiutano nello sviluppo l'altro, entrambi realizzano 7 Story Point.
• Se nessuno dei due collabora, entrambi realizzeranno 5 Story Point.

 Questo gioco può essere descritto con la seguente bi matrice:

La miglior strategia di questo gioco non cooperativo è (non collabora, non collabora) perché non sappiamo cosa sceglierà di fare l'altro. Per ognuno dei due lo scopo è infatti di massimizzare i propri Story Point; ed avremmo per ciascun Developer:

Non Collaborando         5 o 8  Story Point

Collaborando                3 o 7 Story Point

La strategia Collabora è strettamente dominata dalla strategia Non Collabora.

Eliminando le strategie strettamente dominate si arriva all'equilibrio di Nash, dove i due Developer Non Collaborano e realizzano 5 Story Point.

Il risultato migliore per i due ("ottimo paretiano") è naturalmente di collaborare (7 Story Point invece di 5), ma questo non è un equilibrio.

Supponiamo che i due si siano promessi di collaborare. Adesso ciascun Developer si domanda se effettivamente la promessa sarà mantenuta dall'altro; se un Developer non rispetta la promessa e l'altro sì, il primo avrà il bonus aziendale.

C'è dunque un dilemma: collaborare o non collaborare. 

Conclusione

Bonus

1)     Dal punto di vista dell’azienda certamente la migliore soluzione è quella (collabora, collabora);

Se ne deduce che assegnare premi individuali nel gruppo potrebbe comportare l’instaurarsi di un ambiente poco cooperativo.

2)     La miglior politica per l’assegnazione dei bonus ai Developer è quello di assegnarlo a tutto il DevTeam in base al raggiungimento degli obiettivi di gruppo:

• numero di rilasci in Produzione
• rilascio di funzionalità molto importante per il Business
• ecc..