Un grande aumento della velocità è realistico in un ambiente Scrum?

Il mio manager ha recentemente spinto davvero ad usare la velocità come obiettivo e misura della produttività. Attualmente stiamo lavorando ad una velocità media di 50 punti trama. Il mio manager vuole che lo aumentiamo del 40% a 70 punti trama (senza aumentare i membri del team). Se non otteniamo questo aumento, vuole che forniamo una suddivisione completa che spieghi il perché.

L'idea di misurare le prestazioni del team in base alla velocità e di usarlo come obiettivo mi sembra sbagliata, ma trovo difficile spiegare perché. Qualsiasi aiuto? Perché non è questo il modo giusto per misurare e incentivare la produttività?

Bene, è perfettamente semplice aumentare la velocità del 40% - basta aggiungere il 40% in più di punti a tutte le stime e fare lo stesso lavoro.

Dato che è così, dovrebbe essere chiaro il motivo per cui l'uso della velocità come obiettivo è sbagliato, incoraggia solo stime gonfiate.

Una risposta meno risoluta è che il tuo preventivo presuppone già che stai andando il più velocemente possibile mentre fai tutto correttamente. L'unico modo per aumentare davvero la produttività del 40% è di fare gli straordinari o di non fare tutto correttamente. Entrambi accelerano le cose a breve termine, ma rallentano le cose a lungo termine. E il lungo termine in questo caso non è molto lungo, un mese all'esterno. La strategia ottimale a lungo termine è di non andare mai più veloce del tuo ritmo sostenibile.

Peopleware parla in modo eloquente dei problemi del tentativo di forzare i programmatori a una maggiore produttività ed è un classico spesso citato. Ma in generale non sarà facile cambiare idea di un manager che sta seguendo il tuo percorso. Il tuo progetto potrebbe essere nei guai - questa è sicuramente una bandiera rossa.

Come sottolineato dai commenti, la richiesta è ovviamente errata nel modo in cui è stata presentata. Ma non ha davvero torto a voler migliorare costantemente la produttività. Di norma, questo è ciò per cui i manager lottano (e vengono valutati).

Detto questo, i manager cercano sempre di migliorare le prestazioni e Scrum e Agile si basano sull'essere adattabili. Mentre la velocità è una misura del tuo attuale ritmo sostenibile, non dovresti sederti sugli allori. Scrum ha un posto per valutare e cambiare ciò che funziona e non nel tuo processo: la retrospettiva. Se ne approfitti e modifichi il processo, la produttività (e possibilmente la velocità) dovrebbe aumentare.

Quindi, stai cercando (nelle tue retrospettive) i modi per diventare più produttivo come squadra? C'è qualcosa nei tuoi sprint che consuma regolarmente uno sforzo sproporzionato? Può essere indirizzato? Probabilmente non ti darà un aumento del 40%, ma il 5-10% è un inizio, no? Ogni sprint dovresti cercare i colli di bottiglia e affrontarli. Alla fine, potresti avvicinarti all'obiettivo che ti è stato assegnato.

TL; DR

La velocità è molto utile per stimare i programmi o generare valori di pianificazione e può anche essere un controllo investigativo significativo per valutare i colli di bottiglia del processo o i cambiamenti nella capacità del team. Non è, tuttavia, una misura valida della produttività.

Quando la velocità è confusa con gli obiettivi di gestione

"Velocity" è un intervallo che esprime la capacità media di una squadra in un periodo storico. È un'analisi statistica delle prestazioni passate, che può quindi essere utilizzata per proiettare stime probabilistiche della capacità di carico di lavoro o dei tempi di ciclo futuri. Ciò è in netto contrasto con un "obiettivo di pianificazione", che è un obiettivo gestionale che stabilisce una linea temporale o un obiettivo a fini di pianificazione.

I project manager agili esperti sanno che l'uso corretto della velocità è determinare se un team ha la capacità sostenibile di raggiungere gli obiettivi di pianificazione definiti dalla direzione. A volte la risposta è sì, e tutti sono felici. A volte la risposta è no, a quel punto il triangolo di ferro forza le decisioni aziendali su portata, costi, tempo e qualità.

Valuta le tue opzioni politiche

Abbiamo una velocità media di 50 punti trama ... Mi è stato chiesto di aumentarla del 40% a 70 punti trama (senza aumentare i membri del team).

Supponendo che le tue pratiche di stima siano solide e che la tua velocità sia ragionevolmente stabile, il tuo manager non avrà alcuna gioia nel regolare la scala di stima o nel fissare obiettivi di gestione non basati sulle prestazioni storiche. Come correttamente sottolineato, questo è fondamentalmente un problema di capacità .

Il limite di capacità può essere correlato al numero di persone nel tuo team o può essere una limitazione dei processi organizzativi. Naturalmente, l'aggiunta di più persone non sempre aggiunge l'effettiva capacità del progetto; vedere la legge di Brooks per ulteriori informazioni su questo malinteso comune.

Il problema che affronti è politico. Dal tono del tuo post, sembra che il tuo manager voglia vedere un aumento della produttività senza apportare modifiche effettive alla capacità sottostante del team. Le soluzioni sono quindi anche politiche e in gran parte di natura educativa.

Se sei uno Scrum shop, chiedi al tuo Scrum Master di affrontare questo problema attraverso i canali framework appropriati. Backlog Grooming e Sprint Retrospectives sono spesso le opportunità ideali per ispezionare e adattare per questo particolare problema.

Se non sei uno Scrum shop, devi decidere quale sia il modo corretto di affrontare le tue preoccupazioni all'interno della tua organizzazione. Se sei in buoni rapporti con il tuo manager, potresti anche prestargli una copia di Agile Stimate e Planning per farti discutere a pranzo insieme.

Se tutto il resto fallisce, preparati per una marcia della morte spazzolando il tuo curriculum e facendo del tuo meglio fino a quando il progetto non implode. Il 68% dei progetti IT fallisce ; a meno che gli obiettivi di gestione non siano fortemente radicati nella capacità organizzativa, il tuo sarà probabilmente uno di questi.

Non capisco quale ruolo ha il tuo manager nel team Scrum? È un allenatore? È un product owner?

Se è all'interno della squadra come un allenatore o simile (lavora in un compito di sviluppo), potresti chiedergli perché sottovaluta la propria produttività, perché sembra che non sia il caso degli altri membri della squadra. Se crede di poter assumere personalmente 30 punti storia in più ogni iterazione, lascia che lo mostri.

Più probabile: è al di fuori del team, forse il proprietario del prodotto? In tal caso, dovrebbe capire di aver fatto una richiesta così stupida che ha appena smesso di agilità.

Una regola di base è che il proprietario del prodotto stabilisce l'obiettivo mentre il team stabilisce cosa può essere fatto in una iterazione. Non farlo porta al classico e ben noto circolo di ferro: risorse, velocità, caratteristiche. Prendine due! Non puoi sceglierne tre contemporaneamente (e ricorda: la qualità non è una variabile di regolazione, provare a tagliare gli angoli con una bassa qualità peggiorerà le cose).

Se non vuole cambiare l'obiettivo attuale, forse un aumento del 40% della produttività può essere raggiunto reclutando più persone per la squadra? Forse investi in qualche addestramento avanzato per alcuni membri del team? Le squadre possono anche guadagnare velocità nel tempo attraverso il miglioramento continuo, ma certamente non per decisione arbitraria.

Cercare di cambiare la velocità di una squadra è come provare a cambiare la dimensione di una stanza. Si può fare, ma sostanzialmente è necessario cambiare la stanza.

Non hai qualche Scrum Master o altre persone con una conoscenza di base di Scrum che potrebbe spiegarglielo?

In questo caso, il manager ha girato la direzione sbagliata dopo aver ottenuto una stima onesta e fedele dal team. Il manager dovrebbe rivolgersi al stakeholder e far loro sapere che i loro requisiti non possono essere completati nel tempo richiesto. Il manager / analista dovrebbe quindi dare la priorità a quale delle funzioni DEVE essere inclusa e le altre che possono attendere (anche se solo un paio di settimane). Se l'azionista è irragionevole, potrebbe essere necessario coinvolgere manager di livello superiore, il che può essere generalmente impegnativo e richiedere un'intera serie di discussioni.

Se fossi nei tuoi panni mi sarebbe venuto con un caso dettagliate sul motivo per cui il progetto IS andando a prendere il tempo che è stato stimato. Prova anche a identificare gli articoli a basso rendimento. Trova gli elementi che non aggiungono molto valore e richiedono notevoli sforzi di programmazione e cerca di rimuoverli dallo sprint. Inoltre escogita un approccio iterativo che fornisca "X" alla data "Y" e assicurati che sia fattibile, quindi escogita un'iterazione di follow-up che fornisca loro gli elementi rimanenti.

Fondamentalmente, qualcuno deve dire allo stakeholder cosa possono aspettarsi di ricevere entro la scadenza e che include la maggior parte delle loro esigenze. e che dalla prossima versione avranno gli elementi rimanenti. Se il cliente è così irragionevole, è necessario coinvolgere il management superiore, il manager dovrebbe essere in grado di farlo accadere.

Tuttavia, se il cliente ha promesso troppo e nessuno ha parlato fino ad ora, sarà una battaglia in salita. Purtroppo questa non è una situazione rara.

Sembra che tu debba affrontare due problemi.

La parte sulla misurazione della velocità che ti disturba è probabilmente che la misurazione è il costo . Quello che vuoi davvero migliorare è il valore . Sfortunatamente, misurare il valore del software è notoriamente difficile e soggettivo. Tuttavia, anche una metrica imperfetta e soggettiva può essere utile. È possibile che il vero problema non sia che il tuo team debba scrivere più codice, ma che le storie debbano essere più preziose.

L'altro problema è che in base al tuo account, il tuo manager si aspettava un aumento della produttività del 40%. Non è stato indicato nella tua domanda il contesto di questa richiesta. Potrebbe essere un desiderio bonario se desideroso per la tua squadra di migliorare. Oppure potrebbe essere un'indicazione non così sottile che il tuo manager crede che la tua squadra stia andando male.

modifica: in base al tuo commento, la situazione sembra brutta. Sembra che la tua azienda stia gettando le basi per licenziare te e la tua squadra (forse anche il tuo manager). Ti suggerisco di cercare un altro lavoro.

Licenzialo. Vale a dire, andare oltre la testa e spiegare che ha perso tutta la fiducia della sua squadra e spiegare che non ha valore per il business. Spiega che i dirigenti con questo livello di incompetenza sono molto più facili da sostituire rispetto al team di seguito.

Non vi è alcuna buona ragione per tollerare un simile gestore, ma ciò non dovrebbe significare automaticamente che gli sviluppatori dovrebbero dimettersi. Non c'è necessariamente qualcosa di sbagliato nel business, solo con questo individuo. Risolvi quel problema.

E per evitare qualsiasi rifiuto da parte dell'alta dirigenza, chiarire che questo non è un errore perdonabile. Segnala che il manager responsabile non ha alcuna comprensione della squadra che sta gestendo. Ciò non si presta alla correzione, né è necessario nell'attuale mercato del lavoro. I manager sono sostituibili in modo eminente proprio come gli allenatori sportivi. I proprietari non licenziano le squadre.

Ora, potrebbe sembrare una strategia che può ritorcersi contro. Ma considera: se la direzione superiore si schiera dalla parte del tuo manager, a prescindere, saresti comunque in una posizione perdente. Quindi, se consideri solo le situazioni in cui non sei già in quella posizione perdente, il risultato sarà probabilmente molto più positivo. Il vero rischio è che i vertici licenziano l'intero team, incluso il manager. Solo tu puoi stimare quel rischio. Apparentemente la tua produzione è voluta, altrimenti non ne chiederebbero di più, ma a quale prezzo?

La mia esperienza è che è stato molto, molto difficile aumentare la velocità effettiva di una squadra, dato che né la squadra, il dominio problematico o lo stack tecnologico cambiano.

Dove sono stato in grado di ottenere aumenti, è stata una questione di:

• ripulire il debito tecnico; assicurando che tutto esegua la versione corretta (non necessariamente la più recente!), che il codice sia ben ponderato e che non vi sia ridondanza nel sistema (codice duplicato, codice non utilizzato, ecc.)

• migliorare le pratiche; accoppiamento laddove possibile (sì, ho scoperto che aumenta la velocità), prendendomi il tempo di rifattorizzare in modo aggressivo (idem!) ed essere spietato su portata e messa a fuoco

• trovare e / o acquistare i migliori strumenti per il lavoro (ad esempio ReSharper per .NET vale il suo peso in oro, Airbrake e Splunk per lo sviluppo di Ruby, ecc.)

Sono d'accordo con altri qui che affermano che il tuo manager che chiede un aumento arbitrario della velocità è una bandiera rossa. Vorrei cercare un altro lavoro come priorità assoluta.

Il tuo manager chiede (o dice) al tuo team di lavorare ore extra. Mentre rimuovere i colli di bottiglia e ottenere efficienze può migliorare un po 'la tua velocità, l'unico modo per ottenere quell'aumento (40%) è lavorare ore più lunghe, perché in quel periodo di tempo devi riempire più unità di lavoro.

Facciamo uno scenario.

Per un'interazione di due settimane diciamo 10 giorni. L'utopia sarebbe di 8 ore al giorno, con un punto della storia che viene sottratto a una giornata di lavoro. Quindi, dall'alto, la tua velicità sarebbe 8. Ma, in pratica, le persone probabilmente stanno arrivando in 6 buone ore al giorno con e-mail, riunioni, pause bagno, ecc. Quindi ora sei a 6 per sviluppatore. Quindi la tua baseline è 6. Diciamo che vuoi che le persone facciano gli straordinari, ora lì a 10 ore al giorno. Quindi, sarebbero 10 punti velocità per sviluppatore.

La tua velocità fluttuerà sempre, forse era bassa perché hai dovuto affrontare molti bug durante quell'iterazione, forse mancavano i requisiti, forse qualcuno si è ammalato per alcuni giorni. Forse è stato alto perché il lavoro è stato sopravvalutato o il tuo team ha impiegato ore extra.

Ma se sei a 50, davvero per arrivare a 70 richiederà ore extra.

Il problema con la velocità è che si tratta di una variabile dipendente, un output misurato del processo di sviluppo. Esigere di aumentare la velocità del 40% è come cercare di mettersi al lavoro prima urlando alle macchine per andare più veloci. La velocità aumenta alimentando più carburante e aria nel motore o ottenendo un'auto più veloce, oltre a trovare un percorso con meno traffico.

Lavorare più ore non aumenta la velocità se la si misura correttamente, diciamo in punti funzione per ora sviluppatore. Funziona solo se si misurano punti al giorno e poi si ridefinisce ciò che un "giorno" è nella misurazione media. Questo fornisce solo l'illusione della velocità.

Un aumento della velocità richiede il miglioramento delle variabili indipendenti nel processo di sviluppo; computer e compilatori più veloci, sistema di build più efficiente, migliore processo di progettazione, sviluppatori più capaci, migliore area di lavoro, motivazione del super-duper. Un miglioramento del 40% richiederebbe cambiamenti molto significativi.

Chiedi al tuo manager di prendere in considerazione la possibilità di collocare il tuo team in uffici chiusi attorno a un ambiente di lavoro comune, acquistare il nuovo hardware di sviluppo del team o assumere un paio di sviluppatori davvero senior per guidare il team se ciò gli avrebbe permesso di ottenere il suo 40%. Se non ci sono risorse disponibili per migliorare gli input per il tuo processo di sviluppo, praticamente esclude un sincero interesse per il miglioramento. Questo lascia il reverse-engineering del tuo manager per capire cosa lo sta davvero motivando, che sarebbe oggetto di un intero 'altro filo.

Bene, sono un po 'sorpreso che le altre risposte prendano sul serio la richiesta del capo. Qualcuno che richiede un aumento del 40% della produttività non conosce la prima cosa sullo sviluppo del software.

Mi piace ancora leggere Phil Factor su questo argomento:

Esistono due percorsi di base per la gestione IT. Puoi imparare il tuo mestiere attraverso il sangue, il sudore e le lacrime e salire gradualmente sulla scala, in base alla credibilità che hai acquisito grazie al duro know-how tecnico e ai progetti di successo. In alternativa, puoi indossare un abito e una cravatta affilati, imparare il gergo e parlare dolcemente fino in cima.

Entrambe le rotte sembrano ugualmente efficaci. Trattare con quest'ultima razza può certamente causare alcuni momenti di sgomento e incredulità ... persino la disperazione ... e alcuni di questi sono documentati in queste storie.

Tuttavia, è facile diventare tristi e amareggiati quando si incontra incompetenza tecnica in posizioni di potere e tarare tutti i manager con lo stesso pennello. Phil sconsiglia. La maggior parte dei manager lavora duramente e contribuisce bene all'azienda, e anche i manager poveri possono essere addestrati fino allo standard richiesto, se si seguono solo alcune semplici linee guida. Fa parte della responsabilità del tuo team aiutare il tuo manager a funzionare in modo da beneficiare tutti.

In definitiva, se non riesci ad addestrarli, promuoverli o evitarli, forse puoi imparare ad amarli solo per il loro contributo involontario alla ricca commedia sul posto di lavoro.

Il consiglio di non diventare "tristi e amareggiati" è il massimo che puoi ottenere. Non combattere un capo tecnicamente incompetente su questioni tecniche. Lo vedrà solo come un attacco personale.

Il tuo manager ha frainteso l'uso della velocità. Non è una metrica e non è un obiettivo. Il suo scopo è la calibrazione del carico di lavoro della squadra per sprint.
Se ci pensi, la tua velocità emerge da una migliore ipotesi, che ripeti dopo ogni sprint. Di solito col passare del tempo, dovrebbe diventare un po 'stabile. Ma ciò non cambia il fatto che è un sottoprodotto di ciò che il tuo team sta effettivamente facendo: creare valore per i tuoi clienti.

Il motivo per cui è errato usarlo come target e / o metrica è perché ciò lo renderebbe una metrica di vanità. Sarebbe bello sulla carta, ma non farebbe assolutamente nulla per riflettere se i tuoi prodotti soddisfano pienamente le esigenze dei tuoi clienti. E questo è ciò che è più importante (spero).

Per quanto riguarda la mia esperienza e andare dritto al punto.

Innanzitutto, potresti gonfiare la stima, ma ciò non significa che stai facendo di più.

Secondo (premessa: senza gonfiare, concentrandosi solo sulla velocità della squadra),

Prova a trovare le abilità all'interno della tua squadra. Stanno lavorando su ciò che sono meglio? Hai bisogno di un architetto di sistemi per prendere le decisioni difficili riguardo alla costruzione dell'applicazione e cose complesse? In che modo il team sta spendendo i propri sforzi? Stanno trascorrendo del tempo alla ricerca di soluzioni per i loro problemi, refactoring, decisioni aziendali o cosa?

Sono comodi, focalizzati e stimati? Cosa succederà dopo per loro?

Questo non è "sono spinto oltre i limiti" ... è più come una domanda per tutta la squadra "Siamo ai limiti?" e "Come possiamo spingere i limiti?" ...

Ho leader team ad alte prestazioni (per la prima costruzione e / o migrazioni) ... la motivazione del team è la chiave del successo ... e pianificare come dovrebbe essere la base dell'applicazione è essenziale. A volte io o un team assumiamo il ruolo di Systems Architect e decido come e dove "la cosa" dovrebbe andare.

A volte quando vedo che i miei compagni stanno perdendo efficienza, provo a rompere e li invito a uscire per una birra o qualcosa che gli piace. Questo risolve eventuali conflitti e il giorno successivo si concentrano di nuovo.

VENDITA...

Se spiegare i motivi per cui non è possibile aumentare la velocità è difficile, utilizzare il ROI.

Scrum focus su ciò che è più importante per il cliente. Teoricamente i compiti più redditizi.

Se i tuoi problemi riguardano la vendita dello sforzo di sviluppo, cosa pensi di vendere qual è il ROI dello sforzo di sviluppo, invece converti direttamente i punti della storia al "prezzo". Se riesci a provare che il tuo team lavora con un ROI elevato, chi ti farà domande? Inoltre, ogni squadra ha i suoi limiti se la squadra ha trovato la sua "dimensione confort", prova di mese in mese un leggero aumento, se non sono riusciti a completare tutte le attività questo è (probabilmente) il limite.

Mostra la cronologia delle attività, i profitti (se disponibili), il punto della storia che hai usato e mostra che la PRODUTTIVITÀ NON È LO SFORZO DEL TEAM è un calcolo determinato dal team per valutare la complessità e forse il tempo per ottenere qualcosa fatto