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

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

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

Una risposta meno scontata è che la tua stima presuppone già che stai andando più veloce che puoi mentre fai tutto correttamente. L'unico modo per aumentare realmente la produttività del 40% è quello di lavorare fuori orario o di non fare tutto correttamente. Entrambe queste cose accelerano nel breve periodo, 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 è quella di non andare mai più veloce del tuo ritmo sostenibile.

Peopleware parla in modo eloquente dei problemi relativi al tentativo di forzare i programmatori ad aumentare la produttività ed è un classico spesso citato . Ma in generale non sarà facile cambiare la mentalità di un manager che sta seguendo il percorso che è il tuo. Il tuo progetto potrebbe essere nei guai: questa è certamente una bandiera rossa.

Come i commenti hanno sottolineato, la richiesta è ovviamente sbagliata nel modo in cui è stata messa. Ma non ha davvero torto a voler migliorare costantemente la produttività. Di norma, è quello che i manager si sforzano (e sono valutati) per.

Detto questo, i manager cercano sempre di migliorare le prestazioni, e Scrum e Agile è tutto merito dell'essere adattabile. 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 regola il tuo processo, la produttività (e possibilmente la velocità) dovrebbe salire.

Quindi, stai cercando (nelle tue retrospettive) modi per diventare più produttivi come una squadra? C'è qualcosa nei tuoi sprint che consuma regolarmente una quantità sproporzionata di sforzi? Può essere indirizzato? Probabilmente non ti darà un aumento del 40%, ma il 5-10% è un inizio, no? Ogni sprint si dovrebbe cercare i colli di bottiglia e affrontarli. Alla fine, potresti avvicinarti all'obiettivo che ha fissato per te.

TL; DR

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

Quando la velocità è confusa con gli obiettivi di gestione

"Velocity" è un intervallo che esprime la capacità media di una squadra su un periodo storico. Si tratta di un'analisi statistica delle prestazioni passate, che può quindi essere utilizzata per progettare stime probabilistiche della capacità di carico di lavoro o dei tempi di ciclo futuri. Questo è in netto contrasto con un "obiettivo di pianificazione", che è un obiettivo manageriale che imposta una tempistica o un obiettivo per scopi di pianificazione.

I project manager agili esperti sanno che l'uso corretto della velocità è per determinare se una squadra ha la capacità sostenibile di soddisfare 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 impone decisioni aziendali su portata, costi, tempo e qualità.

Valuta le tue opzioni politiche

We have an average velocity of 50 story points...I have been asked to increase it by 40% to 70 story points (with no increase in team members).

Supponendo che le tue pratiche di stima siano solide e che la tua velocità sia ragionevolmente stabile, il tuo manager non trarrà alcuna gioia dall'adattare la scala delle stime o impostare gli obiettivi di gestione non basati sul rendimento storico. Come giustamente fai notare, questo è fondamentalmente un problema capacità .

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

Il problema tu è 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 di controllo e adattamento 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 addirittura prestargli una copia di Agile Estimating and Planning per voi due di discutere durante il pranzo.

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

Non capisco quale ruolo ha il tuo manager nel team di Scrum? È un allenatore? È un proprietario di un prodotto?

Se è all'interno della squadra come un allenatore o altro (lavora in un compito di sviluppo) potresti chiedergli perché sottovaluta la sua stessa produttività, perché sembra che non fosse il caso degli altri membri del team. Se crede di poter assumere personalmente 30 punti storia in più ogni iterazione, fallo mostrare.

Più probabile: è fuori dal team, forse il proprietario del prodotto? Se è così, dovrebbe capire di aver fatto una richiesta così stupida che ha semplicemente interrotto l'agilità.

Una regola di base è che il proprietario del prodotto imposta l'obiettivo mentre il team imposta ciò che può essere fatto in una iterazione. Non farlo porta al classico e ben noto cerchio di ferro: risorse, velocità, caratteristiche. Prendine due! Non puoi sceglierne tre in una sola volta (e ricorda: la qualità non è una variabile di regolazione, cercare di tagliare gli angoli con una bassa qualità renderà le cose ancora peggiori).

Se non vuole cambiare l'obiettivo attuale, è possibile raggiungere un aumento della produttività del 40% reclutando più persone per la squadra? Forse investendo in qualche formazione avanzata per alcuni membri del team? Le squadre possono anche guadagnare velocità nel tempo attraverso il miglioramento continuo, ma certamente non con una decisione arbitraria.

Cercare di cambiare la velocità di una squadra è come provare a cambiare le dimensioni di una stanza. Può essere fatto, ma in pratica è necessario cambiare la stanza.

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

In questo caso, il manager ha cambiato direzione dopo aver ottenuto dal team una stima onesta e fedele. Il manager dovrebbe rivolgersi allo stakeholder e fargli 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 agli altri che possono aspettare (se anche solo un paio di settimane). Se lo stakeholder non è ragionevole, potrebbe essere necessario coinvolgere manager più esperti, il che può essere generalmente impegnativo e richiedere un'intera serie di discussioni.

Se fossi nei tuoi panni, presenterei un caso dettagliato sul motivo per cui il progetto IS durerà tanto quanto stimato. Prova anche a identificare gli oggetti a basso rendimento. Trova gli articoli che non aggiungono molto valore e richiedono sostanziali sforzi di programmazione e fai un caso per rimuovere quelli dallo sprint. Crea anche un approccio iterativo che consegna "X" alla data di "Y" e assicurati che sia fattibile, quindi fornisci un'iterazione di follow-up che consenta loro di ottenere gli elementi rimanenti.

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

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

Sembra che tu abbia due problemi.

La parte sulla misurazione della velocità che ti dà fastidio è probabilmente che la misurazione è il costo . Quello che vuoi veramente migliorare è il valore . Sfortunatamente, misurare il valore del software è notoriamente difficile e soggettivo. Tuttavia, anche una metrica imperfetta e soggettiva può essere utile. Potrebbe essere che il vero problema non è che il tuo team ha bisogno di scrivere più codice, ma che le storie devono essere più preziose.

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

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

licenziarlo. Vale a dire, andare oltre la sua testa e spiegare che ha perso tutta la fiducia della sua squadra, e spiegare che non ha alcun valore per il business. Spiega che i manager con questo livello di incompetenza sono molto più facili da sostituire rispetto alla squadra di sotto.

Non ci sono buone ragioni per sopportare un simile manager, ma questo non dovrebbe significare automaticamente che gli sviluppatori dovrebbero dimettersi. Non c'è necessariamente qualcosa di sbagliato nel business, solo con questo individuo. Risolvi il problema.

E per prevenire qualsiasi richiesta da parte del management, chiarisci che questo non è un errore da dimenticare. Segnala che il responsabile responsabile ha nessuna comprensione del team che sta gestendo. Ciò non si presta alla fissazione, né è necessario nell'attuale mercato del lavoro. I manager sono eminentemente sostituibili proprio come gli allenatori sportivi. I proprietari non licenziano squadre.

Ora, questa potrebbe sembrare una strategia che può ritorcersi contro. Considerate però che se la direzione superiore è a favore del vostro manager, in ogni caso siete già in una posizione di perdita. 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 il management superiore licenzi tutto il team, incluso il manager. Solo tu puoi stimare quel rischio. A quanto pare il tuo output è ricercato, 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 aumentare, è stata una questione di:

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

• migliorare le pratiche; accoppiando dove possibile (sì, ho trovato che aumenta la velocità), prendendo il tempo di refactoring aggressivo (idem!), ed essendo spietato su portata e focus

• 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 gli altri qui che dicono che il tuo manager che chiede un aumento arbitrario della velocità è una bandiera rossa. Sarei alla ricerca di un altro lavoro con priorità elevata.

Il tuo manager chiede (o dice) alla tua squadra di lavorare ore extra. Pur rimuovendo i colli di bottiglia e aumentando l'efficienza può migliorare la tua velocità, l'unico modo per ottenere tale aumento (40%) è lavorare più ore, perché è necessario inserire più unità di lavoro in quel periodo di tempo.

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 astratto in una giornata lavorativa. Quindi, dall'alto, il tuo velcoity sarebbe 8. Ma, per il momento le persone probabilmente stanno ottenendo in 6 ore buone al giorno con e-mail, riunioni, pause bagno, ecc. Quindi ora sei a 6 per sviluppatore. Quindi la tua linea di base è 6. Supponiamo che tu voglia che le persone lavorino fuori orario, ora lì a 10 ore al giorno. Quindi, questo sarebbe 10 punti di velocità per sviluppatore.

La tua velocità fluttua sempre, forse era bassa perché dovevi affrontare molti bug durante l'iterazione, forse mancavano i requisiti, forse qualcuno si ammalava per alcuni giorni. Forse era alto perché il lavoro era sopravvalutato o la tua squadra impiegava ore extra.

Ma se il tuo a un 50 stabile, davvero per arrivare a 70 richiederà ore extra.

Il problema con la velocità è che si tratta di una variabile dipendente, un risultato misurato del processo di sviluppo. Chiedere di aumentare la velocità del 40% è come cercare di mettersi al lavoro prima urlando alle macchine per andare più veloce. 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 misuri correttamente, diciamo in feature point per ora dello sviluppatore. Funziona solo se si misurano punti al giorno e poi si ridefinisce il valore di un "giorno" a metà della misurazione. 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 compilazione più efficiente, processo di progettazione migliore, sviluppatori più capaci, migliore spazio di lavoro, motivazione super-duper. Un miglioramento del 40% richiederebbe cambiamenti molto significativi.

Chiedete se il vostro manager potrebbe prendere in considerazione la possibilità di co-localizzare la vostra squadra in uffici chiusi intorno a un laboratorio comune, acquistare il nuovo hardware di sviluppo del team o assumere un paio di sviluppatori senior per guidare la squadra se questo gli porterà i suoi 40 %. Se non ci sono risorse disponibili per migliorare gli input per il tuo processo di sviluppo, questo praticamente esclude il sincero interesse a migliorare. Ciò lascia reverse engineering al tuo manager per capire cosa lo motiva davvero, il che sarebbe l'argomento di un intero "nother thread".

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

Mi piace ancora leggere Phil Factor su questo argomento:

There are two basic routes into IT management. You can learn your trade through blood, sweat and tears and work your way up the ladder gradually, based on the credibility you've gained from hard-earned technical know-how and successful projects. Alternatively, you can don a sharp suit and tie, learn the lingo, and smooth talk your way to the top.

Both routes seem equally effective. Dealing with the latter breed can certainly cause some moments of dismay and incredulity… despair even… and some of that is documented in these stories.

However, it's easy to become sad and embittered when one encounters technical incompetence in positions of power, and to tar all managers with that same brush. Phil advises against it. Most managers work hard and contribute well to the company, and even poor managers can be trained up to the required standard, if you just follow a few simple guidelines. It's part of your team responsibility to help your manager function in a way that will benefit all.

Ultimately, if you can't train them, get them promoted, or avoid them, maybe you can learn to love them just for their unintended contribution to the rich comedy of the workplace.

Il consiglio di non diventare "triste e amareggiato" è il meglio che puoi ottenere. Non combattere un capo tecnicamente incompetente per questioni tecniche. Lo vedrà solo come un attacco personale.

Il tuo manager ha frainteso l'uso della velocità. Non è una metrica e non è un bersaglio. Il suo scopo è la calibrazione del carico di lavoro del team per sprint.
Se ci pensi, la tua velocità emerge da un'ipotesi migliore, che puoi rimisurare dopo ogni sprint. Di solito con il passare del tempo, dovrebbe diventare un po 'stabile. Ma ciò non cambia il fatto che si tratta di un sottoprodotto di ciò che effettivamente fa il tuo team: creare valore per i tuoi clienti.
Il motivo per cui è sbagliato utilizzarlo come target e / o metrica è perché ciò renderebbe una metrica vanity. Sarebbe bello sulla carta, ma non farebbe assolutamente nulla per riflettere se i tuoi prodotti fossero pieni di soddisfazione per le tue esigenze. E questo è ciò che è più importante (spero).

Riguardo la mia esperienza e andando dritto al punto.

In primo luogo, potresti aumentare la stima, ma ciò non significa che stai facendo di più.

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

Cerca di trovare le abilità all'interno della tua squadra. Stanno lavorando su quello che sono i migliori? Hai bisogno di un architetto di sistemi per prendere le decisioni difficili relative alla costruzione dell'applicazione e a cose complesse? Come la squadra sta spendendo i loro sforzi? Stanno passando il tempo a cercare soluzioni per i loro problemi, a refactoring, a prendere decisioni di business o che cosa?

Sono constrongvoli, focalizzati e stimati? Cosa accadrà per loro?

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

Ho team leader ad alte prestazioni (per la prima costruzione e / o le migrazioni) ... la motivazione del team è la chiave del successo ... e la pianificazione di come dovrebbe essere la base della domanda. A volte io o un teamato assumiamo il ruolo di Systems Architect e decidiamo come e dove dovrebbe andare la "cosa".

A volte, quando vedo che i miei team stanno perdendo efficienza, provo a romperli e li invito a uscire per bere una birra o qualcosa che gli piace. Questo risolve eventuali conflitti e il giorno dopo sono di nuovo focalizzati.

VENDITA ...

Se spieghi i motivi per cui non puoi aumentare la velocità è difficile, usa la ROI.

Fai attenzione a 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 che venda il ROI dello sforzo di sviluppo invece converti direttamente i punti della storia nel "prezzo". Se riesci a dimostrare che il tuo team lavora con un alto ROI, chi ti interrogherà? 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 possono finire tutti i compiti questo è (probabilmente) il limite.

Mostra la cronologia delle attività, le entrate di profitto (se disponibili), il punto della storia che hai usato e mostra che LA PRODUTTIVITÀ NON È IL TEAM EFFORT è un calcolo determinato dal team per valutare la complessità e forse il tempo per fare qualcosa