Agile MVP (Most Valuable Player / Programmer)

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

Piuttosto che incoraggiare la collaborazione tra team, questo incoraggia ogni membro del team a concentrarsi sul proprio risultato. Può persino portare i membri a evitare l'aiuto reciproco (o peggio), che a lungo termine impedirà al team di migliorare.

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

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

Ora, almeno per alcuni di loro, 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 gratis), che sono giochi la meccanica spesso fa parte di un processo gamificato.

La gamification può essere applicata con successo sul lavoro, ma bisogna fare molta attenzione a sfruttare la motivazione intrinseca / estrinseca. La motivazione estrinseca deve alimentare la autodeterminazione in modo che la motivazione diventi intrinseca. Tuttavia, quello che è successo qui è il contrario, i programmatori stanno "giocando il gioco" per vincere .

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

• indica i punti che corrispondono alla difficoltà e alla priorità dei biglietti. Fai in modo che sia molto più interessante, in termini di punti, correggere un bug difficile da trovare / riprodurre.
• fornire punti per risolvere i problemi cooperativamente (di nuovo, il TEAM). È qui che potresti ottenere più programmatori per interagire con il controllo qualità. Dare dei punti per un problema che viene risolto in modo cooperativo da un programmatore e un QA, ad esempio.
• assegna titoli diversi, uno per il maggior numero di punti e uno per il maggior numero di ticket. Questo dovrebbe soddisfare l'istinto competitivo dei programmatori.
• è possibile stabilire una competizione amichevole tra Dev e QA riassumendo i punti di ogni membro di un team

Ridurre la possibilità che i bug di regressione appaiano comunque è un altro problema. Potresti ad esempio applicare punti negativi, ma sono sicuro che non è una buona idea dato che sarebbe una forma di punizione. Ciò che sarebbe meglio, forse, è iniziare automaticamente uno sprint con pochi 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, in "gamification" c'è "game". E l'aspetto fondamentale di un gioco è che tu giochi / partecipi volontariamente. Nel contesto del lavoro, può essere imposto dalla direzione che è il caso, ma normalmente nessuno dovrebbe essere obbligato a farlo.

Per concludere, questa cosa MVP non è necessariamente una cattiva idea, ma l'approccio potrebbe essere modificato un po 'per far sì che il business (risolvendo bug importanti) venga prima, e enfatizzi il lavoro di squadra piuttosto che i singoli.

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 erroneamente. Tu affermi 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 - presumo 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, facendo esplodere il più velocemente possibile e causando bug di regressione e altri problemi nella loro scia, allora non aggiungono valore, stanno creando più lavoro per chi ha seguirli per identificare e risolvere questi problemi.

Il mio suggerimento sarebbe di provare ad avviare una discussione adeguata la prossima volta che la tua squadra ha uno di questi voti. Non renderlo solo una dimostrazione di mani; parlarne per primo Se qualcuno sembra ottenere voti in base al numero di "correzioni" che hanno fatto, evidenzia (con tatto) dove quelle correzioni hanno causato regressioni, e suggerisce che forse la persona che ha fissato quelle regressioni dovrebbe essere nominata per ripulire le altre persone pasticcio. Se qualcuno ha speso l'intero sprint per ottenere uno schifoso problema, segnalalo alla squadra, sottolineando il fatto che sebbene il numero di correzioni di questa persona sia uno, hanno risolto da soli un grosso problema con il tuo software - un problema che era così brutto che nessun altro ha voluto toccarlo.

Individuare correzioni semplici e eseguirle 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 sul team e le persone su di esso, e guarda il software. Scegli l'unica 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 abbagliante? È stata aggiunta una nuova grande funzionalità? Una volta che hai identificato ciò che questo grande cambiamento è, chiedi a chi era responsabile. Una di queste persone è probabilmente il tuo vero MVP. Se "non tanti piccoli bug" è la differenza solo , allora e solo allora il bug conta una misura valida di MVP - e anche allora, guarderei il rapporto di bug corretti per i bug di regressione causati. Ogni bug che qualcuno causa deduce almeno 1 dal proprio conteggio. In effetti, direi più di 1, perché una correzione errata causerà un bug sconosciuto che dovresti trovare, il che è peggio di un bug conosciuto che è stato trovato già. Un bug noto richiede uno sforzo da parte degli sviluppatori per risolvere; un bug sconosciuto richiede lo sforzo del QA per trovare, e lo sforzo degli sviluppatori di risolvere, e quindi c'è il rischio che il QA non riesca a trovarlo.

In teoria, se gli sviluppatori si rendono conto che il modo per ottenere il premio è quello di risolvere problemi minori, più grandi, mirano a quelli difficili, quelli complessi, i difetti di blocco. Ciò richiederà che si uniscano a volte, sia perché non ci sono abbastanza problemi di carne da aggirare, sia perché il problema è abbastanza complicato da richiedere più set di occhi . Forse suggerire che in casi come questo, il premio potrebbe essere condiviso se non è immediatamente chiaro quale di un gruppo di persone ha fatto più lavoro per risolvere un bug - e ricorda, lavoro fatto! = Righe di codice scritte. Probabilmente lo sanno gli sviluppatori, ma hai detto che la gestione è coinvolta e la gestione non sempre capisce quel 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 farlo diventare un grosso problema. Lascia il trofeo in un cassetto, spendi il premio in denaro in un giro di drink per la squadra dopo il lavoro, usa il pranzo gratis per ottenere qualcosa che puoi condividere, come un mucchio di cupcakes. Agile è un sistema di squadra; evidenziando i rischi delle prestazioni individuali che mettono la squadra l'una contro l'altra. Uniti, ti dividi, dividi il tuo software pieno di bug, dopo la scadenza, oltre il 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 al di là degli incentivi, delle motivazioni e dei premi e tocca in realtà le idee nella psicologia ambientale / comportamentale e nell'architettura decisionale. Cose interessanti.

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

Ho scritto sull'uso di affordances (in la 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. Di conseguenza, i problemi sorgono quando le affordances nel tuo processo non sono completamente allineate con i valori della tua squadra.

Ho eseguito diversi workshop su questo argomento e questo particolare problema si presenta come esempio nei gruppi di tempo al tempo. Applicare la teoria delle affordance al caso che hai condiviso nella tua domanda potrebbe sembrare qualcosa di simile .....

Assumi la coerenza dei valori del team, la prevedibilità e il codice di alta qualità.

Hai una lista di comportamenti negativi che hai osservato e sembrano provenire dall'utilizzo di metriche sui difetti per scegliere un MVP del team. Ad esempio, i compagni di squadra sembrano voler scegliere e correggere i bug in modo casuale, con un impatto negativo su tutti e tre i valori. (Suppongo che anche prima ci fosse un problema, e questo è ciò che ha portato all'idea dell'MVP).

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

• Permetti a chiunque di dare un "kudo di squadra" a chiunque (e tutti, non solo uno) individui che comprendano in modo dimostrabile i valori della tua squadra. Ciò promuoverà la prevedibilità democratizzando il sistema del valore della squadra attraverso esempi. (Effettivamente facciamo questo nel nostro team ..)
• Avvia la programmazione delle coppie (o assegna "compagni di bug") per tutti i bug fixing. Ciò promuoverà la qualità scoraggiando le decisioni di programmazione affrettate o sconsiderate e incoraggiando la coerenza perché i compagni smetteranno il comportamento erratico. (Questa idea è comunemente suggerita durante i workshop, sembra intuitiva ..)

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

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

Uno degli aggiustamenti più facili da fare per garantire che qualcosa come un programma MVP funzioni è premiare i membri del team per essere il più prezioso per il successo della squadra, non essere il lavoratore più difficile.

Lo abbiamo fatto con successo riconoscendo le persone che non hanno nemmeno lavorato su bug o funzionalità, ma hanno fatto qualcosa di straordinario che ha fatto sì che tutti nel team riuscissero meglio. Ad esempio, abbiamo avuto uno sviluppatore che si è assunto l'incarico di guidare un gruppo di nuovi membri del team in modo che potessero imparare l'architettura e il modo in cui lavoravamo. La nostra velocità è aumentata perché avevamo queste nuove reclute in grado di fornire risultati in modo rapido ed efficiente, anche se singolarmente la velocità di uno sviluppatore è diminuita perché stava trascorrendo più tempo ad aiutare il resto del team.

Ricompensa il lavoro di squadra e il team noterà che è il TEAM a essere importante, non il proprio successo personale.