MVP agile (lettore / programmatore più prezioso)

Recentemente sono stato coinvolto in un progetto agile (usando scrum) in cui il management ha avuto l'idea che il team avrebbe nominato uno "MVP" sviluppatore e un "MVP" QA alla fine di ogni sprint, votato dal squadra. L'MVP riceve quindi una piccola ricompensa monetaria e un pranzo gratuito, nonché un trofeo da mostrare sulla sua scrivania. Finora abbiamo avuto due sprint con questo sistema di ricompense in atto.

Il bene che vedo da questo è il seguente:

• Sono stati corretti più bug (che è ciò che i vertici aziendali vogliono vedere, un cambio di numero nella direzione che vogliono)
• L'MVP di ogni "squadra" viene riconosciuto e ottiene una spinta all'autostima (o è una spinta all'ego?)

Ho notato alcune cose che considererei lati negativi nel fare una cosa del genere (almeno dal punto di vista degli sviluppatori):

• Ci sono alcuni sviluppatori che sono così preoccupati del numero che la qualità delle correzioni dei bug è diminuita. Le correzioni in un'area stanno causando regressioni in un'altra.
• Ci sono alcuni sviluppatori che stanno raccogliendo bug "più facili / più veloci" per aumentare il loro conteggio. Potrebbe essere un male qui immagino.
• I difetti con priorità più alta (che per la maggior parte del tempo sono correlati a "più difficili / più lunghi da correggere") diventano in realtà una priorità inferiore.
• I difetti di blocco non vengono risolti in modo tempestivo, poiché di solito richiedono più tempo e richiedono un maggiore coordinamento con il QA.
• L'aspetto del team all'interno del team Dev è stato perso. L'aspetto del team di Dev e QA che lavorano insieme non è migliorato, ma non è cambiato molto da prima.
• Lavorare al di là di correzioni di bug, o lavorare verso quel numero, non è facilmente riconoscibile / monitorato.

Credo che ciascuno dei "cattivi" di cui sopra possa essere affrontato in una certa misura, a seconda di come la squadra gestisce ciascuno.

La mia domanda è, quindi, qualcuno ha tirato fuori qualcosa del genere, dove riconosci un MVP per sprint? In tal caso, cosa pensi abbia contribuito a quel successo?

Agile enfatizza lo sforzo di squadra , non lo sforzo degli individui. Quindi no, questo approccio non è chiaramente agile.

Piuttosto che incoraggiare la collaborazione del team, questo incoraggia i membri di ciascun team a concentrarsi sul proprio risultato. Può persino portare i membri a evitare di aiutarsi a vicenda (o peggio), il che a lungo andare impedirà al team di migliorare.

Suggerisco di premiare la squadra nel suo insieme se hanno fatto un buon lavoro.

Penso che sia un buon esempio di -bad- gamification applicata. Il problema è che i tuoi programmatori hanno potenzialmente avuto una motivazione intrinseca nel risolvere i problemi e vincere le sfide (trovare e correggere bug difficili) E, dal momento che hai implementato Scrum, nel lavorare come TEAM. In altre parole, potenzialmente volevano fare un buon lavoro.

Ora, almeno per alcuni di essi, questa motivazione intrinseca o parte di essa è stata sostituita da una motivazione estrinseca consistente in titoli ("MVP della settimana") e premi (importo monetario e pranzo libero), che sono spesso parte della meccanica di gioco di un processo gamified.

La gamification può essere applicata con successo sul lavoro, ma è necessario fare molta attenzione a sfruttare la motivazione intrinseca / estrinseca. La motivazione estrinseca deve alimentare l'autodeterminazione affinché la motivazione diventi intrinseca. Tuttavia, ciò che è accaduto qui è il contrario, i programmatori "giocano il gioco" per vincere .

Quello che potresti fare per risolvere questo problema è chiedere alla direzione di modificare un po 'le regole:

• assegnare punti corrispondenti alla difficoltà e alla priorità dei biglietti. Fallo in modo che sia molto più interessante, dal punto di vista dei punti, correggere un bug difficile da trovare / riprodurre.
• dare punti per risolvere i problemi in modo cooperativo (di nuovo, il TEAM). Qui è possibile ottenere più programmatori per interagire con il QA. Dare punti per un problema risolto in modo cooperativo da un programmatore E ad esempio un QA.
• assegnare titoli diversi, uno per il maggior numero di punti e uno per il maggior numero di biglietti. Ciò dovrebbe soddisfare l'istinto competitivo dei programmatori.
• eventualmente stabilire una competizione amichevole tra il Dev e il QA riassumendo i punti di ogni membro di una squadra

Ridurre la possibilità che compaiano errori di regressione è tuttavia un altro problema. Ad esempio, potresti applicare punti negativi, ma sono sicuro che non è una buona idea poiché sarebbe una forma di punizione. Forse sarebbe meglio iniziare automaticamente uno sprint con alcuni punti se non è stato rilevato alcun bug di regressione nella scorsa settimana. Se sono stati rilevati bug di regressione, il programmatore inizia con 0.

Inoltre, nella "gamification" c'è il "gioco". E l'aspetto fondamentale di un gioco è che giochi / partecipi volontariamente. Nel contesto del lavoro, può essere imposto dalla direzione che è il caso qui, ma normalmente nessuno dovrebbe essere costretto a farlo.

Per concludere, questa cosa MVP non è necessariamente una cattiva idea, ma l'approccio potrebbe essere leggermente cambiato per far venire prima gli affari (risoluzione di importanti bug) e sottolineare il lavoro di squadra piuttosto che le persone.

Una sorta di riconoscimento di gruppo degli sforzi di un membro del team può essere un valido motivatore, ma in questo caso sembra che venga applicato in modo errato. Affermate che l'MVP viene scelto per voto, ma ci sono molte menzioni di numeri di bug corretti per sprint. Sembra che il tuo tempo abbia una definizione divertente di MVP - Suppongo che la persona che merita il titolo di "più prezioso" sia la persona che ha aggiunto più valore al software in quello sprint. Se un membro del team sta individuando bug che possono essere corretti rapidamente, eliminandoli il più rapidamente possibile e causando bug di regressione e altri problemi sulla loro scia, allora non aggiungono valore, stanno creando più lavoro per chiunque abbia seguirli per identificare e risolvere quei problemi.

Il mio suggerimento sarebbe di provare a iniziare una discussione adeguata la prossima volta che la tua squadra avrà uno di questi voti. Non limitarti a renderlo uno spettacolo di mani; parlane prima. Se qualcuno sembra ottenere voti in base al solo numero di "correzioni" che hanno fatto, indica (con tatto) dove tali correzioni hanno causato regressioni e suggerisce che forse la persona che ha risolto tali regressioni dovrebbe essere nominata per ripulire le altre persone pasticcio. Se qualcuno ha trascorso l'intero sprint a risolvere un brutto problema, segnalalo al team, sottolineando il fatto che, sebbene il conteggio delle correzioni di questa persona sia uno, hanno risolto da solo un grave problema con il tuo software - un problema che era così cattivo che nessun altro voleva toccarlo.

Scegliere soluzioni facili e farle in modo affrettato o casuale non è prezioso, quindi gli sviluppatori che lo fanno probabilmente non dovrebbero qualificarsi come candidati MVP. Quando selezioni il nuovo MVP, dimentica tutto del team e delle persone che lo compongono e guarda il software. Scegli l'ultima modifica più importante in quel software dall'ultima volta. Intendo single qui; "Non tanti piccoli bug" non è un grande cambiamento. È stato corretto un bug particolarmente evidente? È stata aggiunta una nuova fantastica funzionalità? Una volta identificato quale sia questo grande cambiamento, chiedi a chi era responsabile. Una di quelle persone è probabilmente il tuo vero MVP. Se "non tanti piccoli bug" è l' unica differenza, allora e soloallora il conteggio dei bug è una misura valida di MVP e anche allora guarderei il rapporto tra bug corretti e bug di regressione causati. Ogni errore che qualcuno causa deduce almeno 1 dal loro conteggio. In effetti, direi più di 1, perché una correzione errata causerà un bug sconosciuto che dovrai trovare, che è peggio di un bug noto che è già stato trovato. Un bug noto richiede agli sviluppatori lo sforzo di risolvere; un bug sconosciuto richiede la ricerca del QA e lo sviluppo degli sviluppatori da correggere, quindi c'è il rischio che il QA manchi.

In teoria, se gli sviluppatori si rendono conto che la strada per il premio è quella di risolvere un numero minore di problemi, mireranno a quelli difficili, quelli complessi, i difetti di blocco. Ciò richiederà loro di riunirsi a volte, sia perché non ci sono abbastanza problemi carnosi da aggirare, sia perché il problema è abbastanza complicato da richiedere più serie di occhi . Forse suggerire che in casi come questo, il premio potrebbe essere condiviso se non fosse immediatamente chiaro quale di un gruppo di persone ha lavorato di più per correggere un bug - e ricordate, lavoro fatto! = Righe di codice scritte. Gli sviluppatori probabilmente lo sapranno, ma hai detto che la gestione è coinvolta e la direzione non sempre capisce questo punto.

E hey, se tutto il resto fallisce, dimentica il programma MVP. Parla con i tuoi colleghi sviluppatori al di fuori della mischia e sottolinea l'impatto negativo che i premi MVP stanno avendo sul software. Vedi se riesci a farli ignorare, o non renderlo così grande. Lascia il trofeo in un cassetto, spendi il premio in denaro per un giro di bevande per la squadra dopo il lavoro, usa il pranzo gratuito per ottenere qualcosa che puoi condividere, come un mucchio di cupcakes. Agile è un sistema di squadra; evidenziando i singoli rischi di prestazione mettendo l'uno contro l'altro il team. Uniti tu stai, diviso spedisci software pieno di bug, dopo la scadenza, oltre budget.

Questo è un classico esempio di come una pratica specifica (riconoscimento pubblico come MVP) può avere un impatto significativo ma indiretto sul comportamento della tua squadra. Questo va oltre gli incentivi, le motivazioni e i premi e in realtà tocca idee nella psicologia ambientale / comportamentale e nell'architettura delle decisioni. Roba forte.

La domanda è: come puoi progettare un processo in modo che il tuo team sembri fare le cose giuste in modo naturale, senza dover attuare politiche rigide o costringere le persone a fare qualcosa?

Ho scritto sull'uso delle convenzioni (nella tradizione di Design of Everyday Things di Donald Norman ) per i processi come meccanismo per progettare un processo che funzioni per il tuo team. L'idea di base è che le pratiche in un processo influenzano direttamente il comportamento di una persona. Pertanto, i problemi sorgono quando le prestazioni nel processo non sono completamente allineate ai valori della tua squadra.

Ho tenuto diversi seminari su questo argomento e questo particolare problema emerge di volta in volta come esempio in gruppi. Applicare la teoria delle convenienze al caso che hai condiviso nella tua domanda potrebbe assomigliare a questo .....

Supponi che la tua squadra valuti coerenza, prevedibilità e codice di alta qualità.

Hai un elenco di comportamenti negativi che hai osservato e tutti sembrano derivare dall'uso delle metriche dei difetti per scegliere un MVP di squadra. Ad esempio, i compagni di squadra sembrano voler naturalmente raccogliere e correggere casualmente i bug, incidendo negativamente su tutti e tre i valori. (Suppongo che prima ci fosse un problema, e questo è ciò che ha portato all'idea MVP).

Invece di avere un singolo MVP basato su parametri di difetto, proveremo a cambiare il comportamento del team apportando alcune piccole ma significative modifiche.

• Consenti a chiunque di dare un "kudo di squadra" a tutti (e tutti, non solo a uno) individui che abbracciano manifestamente i valori della tua squadra. Ciò promuoverà la prevedibilità democratizzando il sistema di valori del team attraverso esempi. (In realtà lo facciamo nel nostro team ..)
• Inizia la programmazione della coppia (o assegna "compagni di bug") per tutto il bug fixing. Ciò promuoverà la qualità scoraggiando decisioni di programmazione affrettate o incerte e incoraggerà la coerenza perché gli amici tempereranno il comportamento irregolare. (Questa idea viene comunemente suggerita durante i seminari, sembra intuitiva ..)

E questi sono solo alcuni esempi per dimostrare l'approccio e iniziare ...

La cosa fantastica di questo approccio è che stai progettando attivamente le modifiche al tuo processo e hai ragioni giustificabili per le modifiche al processo che apporti. Proprio come nella progettazione di oggetti o dell'interfaccia utente, puoi persino misurare i risultati per capire se le cose funzionano o no.

Uno degli aggiustamenti più facili da apportare per garantire che qualcosa come un programma MVP funzioni è quello di premiare i membri del team per essere il più prezioso per il successo del team, non per essere il lavoratore più duro.

Lo abbiamo fatto con successo riconoscendo le persone che non hanno nemmeno lavorato su bug o funzionalità, ma hanno fatto qualcosa di fantastico che ha permesso a tutti i membri del team di avere successo. Ad esempio, abbiamo avuto uno sviluppatore che ha assunto il compito di guidare un gruppo di nuovi membri nel team in modo che potessero imparare l'architettura e il modo in cui abbiamo lavorato. La nostra velocità è aumentata perché avevamo queste nuove reclute in grado di fornire risultati in modo rapido ed efficiente, anche se individualmente quella velocità di uno sviluppatore è diminuita perché stava impiegando più tempo ad aiutare il resto del team.

Ricompensa il lavoro di squadra e il team noterà che è il TEAM che conta, non il loro successo personale.