Il team non riesce costantemente a raggiungere gli obiettivi dello sprint

Siamo una piccola società di software con un solo prodotto.

Usiamo scrum e i nostri sviluppatori scelgono le funzionalità che vogliono includere in ogni sprint. Sfortunatamente negli ultimi 18 mesi, il team non ha ancora una volta consegnato le funzionalità a cui si è impegnato per uno sprint.

Ho letto molti post / risposte affermando qualcosa sulla falsariga di "software fatto quando è fatto, non prima, non più tardi ... non aiuta a fare pressione sul team, a mettere più persone su di esso, ... "Ho ricevuto un feedback simile da uno degli sviluppatori sulla mia domanda su come possiamo migliorare il tasso di successo degli sprint. Oh, e sì, usiamo retrospettive .

La mia domanda è sostanzialmente:

Quando è giusto cercare il problema nella qualità degli sviluppatori?

Sto iniziando a pensare che se riesci a scegliere il tuo lavoro / le tue caratteristiche e fallisci comunque ogni sprint: - Non sei in grado di supervisionare la complessità del tuo codice; - o il codice è così complesso che nessuno può sovrintendere alla complessità.

Mi sto perdendo qualcosa?

Dovresti prima chiedere "chi se ne frega"?

Il completamento degli sprint è positivo e in alcune aziende si ottengono i cookie della scrum parent. Ma il test finale è se la società sta raggiungendo i suoi obiettivi.

Quanto sopra è faceto. Se la società riesce senza mai completare il contenuto pianificato di uno sprint, è possibile utilizzare Kanban: si ordina il backlog, si lavora su ciò che è più importante e non ci si preoccupa così tanto delle iterazioni definite.

Uno dei valori di iterazioni definite è quello di guidare il miglioramento dei processi (o scacciare i sottoperformatori in alcune mentalità). Non lo capisci adesso. Quindi, puoi adottare il resto del processo che migliora il processo (e alla fine completa gli sprint), oppure puoi decidere che ti piace quello che hai.

Mi sto perdendo qualcosa?

SÌ!

Sei andato 18 mesi - o da qualche parte nel quartiere di 36 sprint con retrospettive, ma in qualche modo non sei riuscito a risolverlo? Il management non ha ritenuto responsabile il team e quindi il loro management non li ha ritenuti responsabili per non aver ritenuto responsabile il team?

Ti manca che la tua azienda sia pervasivamente incompetente .

Quindi, come risolverlo. Tu (il dev) smetti di impegnarti in così tanto lavoro. Se le storie sono così grandi che non puoi farlo, allora devi scomporle in pezzi più piccoli. E poi puoi rendere le persone responsabili per aver fatto ciò che dicono che saranno fatte. Se si scopre che possono ottenere solo una piccola funzione per ogni sprint, quindi capire perché e migliorarlo (che può comportare la sostituzione dello sviluppatore). Se si scopre che non riescono a capire come impegnarsi in quantità ragionevoli di lavoro, li licenzi .

Ma prima, avrei esaminato il management che ha lasciato andare le cose per così tanto tempo e avrei scoperto perché non stanno facendo il loro lavoro.

Vorrei suggerirti di fare una piccola modifica e provare Kanban per un paio di settimane invece di Scrum . Potrebbe funzionare meglio per la tua squadra.

Mentre Scrum guida la produttività limitando il tempo di lavoro disponibile in uno sprint, Kanban guida la produttività e la velocità limitando il numero di problemi attivi e concorrenti. La stima del tempo non fa più parte del processo. ( fonte )

In poche parole, che cos'è Kanban?

Kanban è anche uno strumento utilizzato per organizzare il lavoro per motivi di efficienza. Come Scrum, Kanban incoraggia il lavoro a essere suddiviso in blocchi gestibili e utilizza una Kanban Board (molto simile alla Scrum Board) per visualizzare quel lavoro mentre avanza nel flusso di lavoro. Laddove Scrum limita la quantità di tempo consentita per eseguire una determinata quantità di lavoro (per mezzo di sprint), Kanban limita la quantità di lavoro consentita in qualsiasi condizione (solo così tante attività possono essere in corso, solo così tante possono essere sul -do elenco.)

Come sono SCRUM e Kanban uguali?

Sia Scrum che Kanban consentono di scomporre e completare in modo efficiente attività grandi e complesse. Entrambi attribuiscono un valore elevato al miglioramento continuo, all'ottimizzazione del lavoro e del processo. Entrambi condividono l'attenzione molto simile su un flusso di lavoro altamente visibile che mantiene tutti i membri del team in contatto con WIP e ciò che verrà.

Vedi il resto dei dettagli da questo link

La mia domanda è fondamentalmente: quando è giusto cercare il problema nella qualità degli sviluppatori

Non ci sono abbastanza informazioni nel tuo post per rispondere a questa domanda. Non c'è modo di sapere se falliscono perché sono incompetenti o falliscono perché si impegnano a fare più lavoro di quanto sia ragionevole.

Se sono uno sviluppatore incredibilmente dotato, in una squadra di sviluppatori incredibilmente dotati, e non riusciamo a finire X storie in due sprint (o 36!), Siamo incompetenti? Oppure, facciamo solo schifo alla stima? Dipende se le storie erano "crea una schermata di accesso" o "invia un uomo sicuro su Marte".

Il problema inizia con storie brutte e / o stime negative

La stima è difficile. Davvero difficile. Gli umani fanno schifo, motivo per cui Scrum ci fa scomporre il lavoro in blocchi che non dovrebbero richiedere più di un giorno o due, e per assemblare piccoli gruppi di quei blocchi che siamo certi di poter completare in un breve periodo di tempo . Più grandi sono i blocchi e più lungo è il periodo di tempo, meno accurate sono le nostre stime.

Come sono i tuoi negozi? Sono ben scritti, con buoni criteri di accettazione? Sono tutti abbastanza piccoli da fare in pochi giorni? Senza storie ben scritte (che è colpa dell'intero team di sviluppo, incluso il proprietario del prodotto), non ci si può aspettare che il team faccia una buona stima.

Il problema è aggravato da cattive retrospettive

Ciò che stai sbagliando, a quanto pare, è che non stai sfruttando le retrospettive. Hai trascorso 18 mesi senza risolvere questo problema, quindi o il team non se ne accorge o non riesce a risolverlo nelle loro retrospettive.

Ogni retrospettiva termina con almeno un oggetto di azione che la squadra deve compiere, per fare meglio allo sprint successivo. Ogni retrospettiva include parlare degli elementi di azione dello sprint precedente per vedere se sono stati fatti e se sono stati efficaci?

La soluzione non è dare la colpa, è imparare

Il primo passo dovrebbe essere quello di smettere di cercare la colpa e, invece, iniziare a lavorare per migliorare la squadra. La tua squadra probabilmente non è incompetente, ma solo cattiva nella stima e nella pianificazione. Forza la squadra a terminare uno sprint, anche se ciò significa che scelgono una sola storia e finiscono con una settimana di anticipo. Se non riescono a farlo, allora sono incompetenti o le storie sono semplicemente troppo complesse. La risposta a questa domanda dovrebbe essere ovvia.

Una volta che saranno in grado di completare una storia, sapranno con ragionevole certezza che potranno fare X quantità di punti storia in uno sprint. La matematica semplice aiuterà a rispondere alla domanda se possono fare più storie o meno.

Il miglioramento continuo è la soluzione

Una volta terminata una storia in uno sprint, è tempo di vedere se ne possono fare due. Raccogliere, sciacquare, ripetere. Quando iniziano a fallire gli obiettivi dello sprint, hai trovato il limite alle loro capacità di stima. Torna al numero di punti della trama della storia precedente e mantienila per un po '.

In ogni momento, prendi sul serio le retrospettive. Se non hanno finito uno sprint, capire perché e agire su di esso. Avevano troppe incognite? Hanno il mix sbagliato di abilità? Quanto erano buone le loro stime? Se stimavano una storia come punti X, richiedeva una quantità relativamente uguale di lavoro rispetto alle storie del convento che valevano X punti? In caso contrario, utilizzalo per regolare i punti delle storie future.

Dici di "usare retrospettive". Ma cosa fa realmente il team in queste retrospettive? Da quando hai trascorso 18 mesi senza affrontare una volta questo aspetto del tuo processo, immagino che la risposta sia: niente di molto utile.

Per me, la retrospettiva è la parte più importante del processo. Butta via o cambia qualsiasi altra cosa su Scrum tutto ciò che desideri (di comune accordo con il team durante una retrospettiva, ovviamente), ma impegnati a prenderti regolarmente il tempo di parlare di come funziona il processo per tutti, condividere ciò che ha funzionato e cosa non ha fatto lavorare e proporre idee per migliorare. Continua a cercare di migliorare il tuo processo poco a poco ogni sprint e, prima o poi, puoi avere qualcosa che funziona abbastanza bene.

Nel tuo caso, quel processo non sembra funzionare. Poiché gli obiettivi dello sprint non vengono raggiunti, è prudente concentrarsi sul perché questo è il caso. Ovviamente, la squadra ha svolto troppo lavoro per lo sprint. Ma perché l'hanno fatto?

• Hanno sottovalutato la complessità del lavoro?
• Il management li ha spinti ad assumere più lavoro di quanto il team pensasse di poter gestire?
• Hanno avuto troppe interruzioni / emergenze che hanno portato via le risorse dal completamento del lavoro pianificato?
• Si sono verificati colli di bottiglia che hanno ritardato il completamento del lavoro (diciamo, in attesa di risorse da un team di progettazione esterno)?
• E anche: uno o più membri del team non sono stati in grado di svolgere il lavoro?

Questo è il tipo di domande che il team avrebbe dovuto farsi ogni sprint negli ultimi 18 mesi. Quindi, armati delle risposte, possono proporre miglioramenti di processo suggeriti alla prova per il prossimo sprint. Questi potrebbero includere:

• Affronta meno lavoro nel prossimo sprint (duh!)
• Sii più prudente nelle stime
• Di 'a chiunque ci stia facendo pressione per fare più lavoro per sradicare, dato che stiamo già assumendo più di quello che possiamo realizzare in questo momento
• Gestisci meglio le interruzioni e regola la quantità di lavoro nel prossimo sprint per far fronte alle inevitabili emergenze
• Risolvi i colli di bottiglia o pianifica quelli che non puoi evitare
• Non assegnare storie ai membri del team che non sono in grado di realizzarli (e separatamente, capire la risposta della direzione per affrontare una situazione con un membro del team poco performante, dalla formazione e tutoraggio al licenziamento)

Questo è il tipo di conversazione che avrebbe dovuto avvenire ogni singolo sprint negli ultimi 18 mesi. Non si tratta di esercitare pressioni sul team o di aggiungere più risorse, ma di utilizzare le retrospettive per migliorare il processo su base continua. Questo chiaramente non sta succedendo qui.

Penseresti che entro il 15 ° sprint con goal mancati, il team avrebbe discusso di questo nella loro retrospettiva così tante volte, al punto in cui hanno deciso di affrontare gli obiettivi di sprint più minimi possibili solo per il gusto di completarne uno. Al 25esimo sprint incompleto, farei semplicemente uno sprint con un singolo cambio di stringa e nient'altro. Se la squadra non riesce a gestirlo in uno sprint, i problemi sono persino peggiori di quelli che si lasciano andare.

Per essere chiari, come molti hanno già sottolineato, gli obiettivi dello sprint sono previsioni, non impegni di ferro, e gli obiettivi mancanti non sono di per sé indicativi di nient'altro che fare previsioni imprecise. Una grande squadra può mancare un sacco di obiettivi perché sono cattivi pronostici, mentre una squadra terribile può soddisfare tutti e non fornire alcun valore reale. Ma se le tue previsioni sono sbagliate nella stessa direzione per 18 mesi consecutivi, quella parte del processo non funziona. Usa le tue retrospettive per correggere il processo in modo che le tue previsioni siano ragionevolmente vicine alla realtà reale di ciò che il team può offrire ad ogni sprint.

"il software è fatto quando è fatto, non prima, non più tardi."

Questo è vero, ma per ogni attività su cui i tuoi sviluppatori iniziano a lavorare, tutti nella tua organizzazione comprendono la Definizione di Fine per ogni attività?

Sembra che uno dei tuoi maggiori problemi sia la stima , ma gli sviluppatori possono fornire una stima realistica solo quando hanno una "definizione del fatto" chiara e chiara. (Che include problemi relativi ai processi aziendali, ad esempio documentazione per l'utente, pacchetti di lavoro su una versione formale, ecc.)

Non sorprende che l'eccessiva stima stia causando un problema, dato che la maggior parte degli sviluppatori vede che stimare il tempo necessario per completare un'attività è il più difficile che venga loro richiesto.

Tuttavia, la maggior parte degli sviluppatori tende ad avere una ragionevole (sebbene ottimistica ) gestione della quantità di sforzo che sono in grado di fare, per un determinato periodo di tempo.

Il problema è spesso che gli sviluppatori hanno difficoltà a creare una relazione tra un'attività e la quantità totale di sforzo richiesto quando hanno a che fare con informazioni incomplete, in particolare se sono spinti a fornire tutte le risposte in anticipo a un compito davvero enorme .

Ciò porta naturalmente a stime del tempo disconnesse dalla realtà e perdono di vista cose come il processo di compilazione e la documentazione per l'utente.

La disconnessione tende a iniziare all'inizio quando viene descritta l'attività; ed è solitamente composto da una persona non tecnica che redige un elenco di requisiti senza avere la minima idea dello sforzo necessario.

A volte le persone nel senior management specificano le attività e ignorano completamente i problemi dei processi aziendali; non è raro che il senior management pensi che cose come la definizione di test, la creazione di una build ufficiale rilasciata o l'aggiornamento di un documento utente avvengano magicamente senza tempo o fatica. necessario.

A volte i progetti falliscono prima che uno sviluppatore abbia persino scritto una riga di codice perché qualcuno, da qualche parte non sta facendo il proprio lavoro correttamente.

Se il team di sviluppo non è coinvolto nel concordare i requisiti o nel catturare i criteri di accettazione, allora questo è un fallimento della gestione, perché significa che qualcuno che ha una comprensione insufficiente del codice e dei problemi tecnici ha impegnato l'azienda a un insieme incompleto di requisiti, e ha lasciato il progetto aperto a interpretazioni errate, creep di portata, dorature, ecc.

Se il team di sviluppo è coinvolto nell'acquisizione e nel concordare i requisiti, potrebbe trattarsi di un fallimento del team, che è responsabile della chiarificazione dei dettagli (e dei criteri di accettazione - ovvero "Che aspetto ha il deliverable? Quando viene fatto ?" ). Il team di sviluppo è anche responsabile di dire NO quando ci sono altri problemi di blocco o se un requisito non è realistico.

Quindi, se gli sviluppatori sono coinvolti nell'acquisizione dei requisiti:

• Il team ha l'opportunità di sedersi con il product manager per chiarire i requisiti / la definizione di done?
• Il team pone domande sufficienti per chiarire i requisiti impliciti / presunti? Ogni quanto viene data una risposta soddisfacente a queste domande?
• Il team richiede criteri di accettazione (definizione di done) prima di fornire un preventivo?
• In che misura vengono generalmente acquisiti i criteri di accettazione per ciascuna attività? È un documento vago con dettagli sparsi o descrive funzionalità tangibili e una formulazione che uno sviluppatore potrebbe tradurre inequivocabilmente in un test?

È probabile che la produttività della tua squadra non sia un problema; la tua squadra probabilmente sta facendo tutto lo sforzo che è in grado di fare per quanto riguarda lo sviluppo. I tuoi veri problemi potrebbero essere uno o più dei seguenti:

• Requisiti incompleti e vaghi.
• Requisiti / compiti che sono troppo grandi in primo luogo.
• Scarsa comunicazione tra il team di sviluppo e la direzione.
• Mancanza di criteri di accettazione chiaramente definiti prima che i compiti vengano consegnati al team.
• Specifica incompleta o vaga / ambigua dei test di collaudo. (ovvero definizione di fatto)
• Tempo insufficiente assegnato alla definizione / approvazione dei criteri di accettazione.
• Gli sviluppatori non hanno considerato il tempo per testare il codice di base esistente o correggere i bug esistenti
• Gli sviluppatori hanno testato il codice di base esistente ma non hanno sollevato i bug come Problemi di blocco prima di fornire stime sui requisiti
• La direzione ha riscontrato i problemi / i bug e ha deciso che non è necessario correggere i bug prima di scrivere un nuovo codice.
• Gli sviluppatori sono sotto pressione per rappresentare il 100% del loro tempo, anche se probabilmente il 20% (o un numero simile) del loro tempo è probabilmente occupato da riunioni, distrazioni, e-mail, ecc.
• Le stime sono concordate al valore nominale e nessuno regola spazio per errori o imprevisti (ad esempio "Abbiamo deciso che questo dovrebbe richiedere 5 giorni, quindi ci aspettiamo che sia fatto in 8.").
• Le stime sono trattate da tutti (sviluppatori e dirigenti) come numeri singoli anziché numeri "a intervallo" realistici, ad es
  • Migliore stima del caso
  • Stima realistica
  • Stima peggiore

... l'elenco potrebbe andare molto più a lungo di così.

Devi fare qualche "accertamento dei fatti" e capire esattamente perché le stime sono costantemente disconnesse dalla realtà. Il software di base esistente è difettoso? Manca la copertura del test unitario? I tuoi sviluppatori evitano la comunicazione con il management? Il management evita la comunicazione con gli sviluppatori? Esiste una disconnessione tra le aspettative di gestione e le aspettative degli sviluppatori quando si tratta di "Definition of Done" ?

Il mio consiglio di riavviare la squadra è di scegliere la storia più piccola possibile per squadra, per sprint e completare quella storia e quella storia solo!

Sono d'accordo con gli altri poster, o il team è incompetente o stanno cercando di fare troppe cose.

Inizia con le cose più piccole, le storie più ridotte e completa un singolo sprint. Fai in modo che il team finisca uno sprint e abbia successo, e ciò li aiuterà a vedere come stabilire le priorità in termini di tempo e impegni di lavoro. Nel tempo il team sarà in grado di svolgere sempre più lavoro fino a raggiungere la massima produttività.

Dovresti raccogliere dati e creare livelli di confidenza in base alle prestazioni passate.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

L'esempio più semplice è con sprint a tempo costante, come ogni due settimane. Stimare quanti punti trama la squadra finirà entro due settimane. Quindi dopo lo sprint di due settimane, vedi quanti punti della storia sono stati effettivamente completati. Nel tempo, potresti vedere stimare 15 punti, ma finire solo 10. In quel semplice caso, puoi iniziare ad andare avanti con una regolazione della velocità in modo da pianificare solo 10 punti per sprint. O che prevedi di finire il 66% del lavoro stimato.

Costruendo livelli di confidenza con deviazioni standard, puoi dire al management: secondo gli attuali obiettivi del progetto, prevediamo solo il 50% di fiducia che possiamo finire in 3 settimane, ma il 95% di fiducia che possiamo finire in 5 settimane.

L'idea alla base di Agile e Scrum è quella di creare un circuito di feedback stretto in modo da poter valutare il processo. Devi chiedere "Dove si è rotto?", Dal momento che sembra essersi completamente rotto.

1. Pianifica cosa farai e creane un elenco
   • Ciò dovrebbe consistere nella raccolta di articoli da un arretrato di articoli che devono essere completati. Prima che qualsiasi cosa venga inserita nella lista delle cose da fare per lo sprint, il team deve concordare di averlo compreso appieno e di stimare all'incirca il completamento dello sprint.
   • Idealmente, l'arretrato viene ordinato in base alla priorità (per l'azienda) e si può tirare in ordine di priorità.
   • Se gli elementi del backlog sono troppo grandi, suddividili in blocchi più piccoli. Quindi suddividere i blocchi in singole attività che possono essere completate in un giorno o meno.
   • Non aspettarti che questa pianificazione sia facile o veloce.
2. Eseguire su elementi dall'elenco per un periodo di tempo definito (uno sprint)
3. Ripassa ciò che hai realizzato
   • Quali storie erano finite?
   • Se nessuna storia era finita, quali compiti erano stati completati?
   • Se nessuna attività è stata completata, cosa hanno fatto esattamente tutti lunedì scorso? Martedì scorso ?, ecc. - a questo punto, è tempo di una forte introspezione ...

4. Risolvi i problemi (analizza feedback e adatta)

   • Quanto tempo hanno impiegato le cose finite?
   • Cosa ha impedito il completamento delle attività?
   • I membri del team suddividono le storie (caratteristiche) in attività che possono essere completate in 1 giorno o meno? In caso contrario, fallo e rendilo parte dell'elenco delle cose da fare.
   • Quali modifiche all'elenco attività o agli elementi nell'elenco attività sono stati apportati durante lo sprint? Questa è stata una causa per non finire? In tal caso, non modificare l'elenco o le funzionalità. Lancia la funzionalità modificata nel backlog fino a quando non è stabile.
   • Come puoi ridurre le dimensioni e la portata di alcuni elementi a qualcosa che può essere finito in uno sprint? Scegli qualcosa di piccolo come un miglioramento della registrazione, una semplice correzione di bug, un errore di battitura, solo per finire alcune cose per consentire al team di ottenere un indicatore di ciò che possono fare. Se non puoi farlo, smetti di correre e riprogrammare .

5. Torna al passaggio 1 e ripeti fino al rilascio ...

Esistono ostacoli alla documentazione, problemi di accoppiamento che creano dipendenze, problemi di comunicazione, informazioni insufficienti nei requisiti? ... Cosa? Gli sviluppatori hanno trascorso il loro tempo cercando di apprendere nuove tecnologie? Hanno trascorso enormi quantità di tempo nella progettazione? Cose come l'apprendimento sono state incluse nell'elenco delle attività dello sprint?

Pensavi che il tuo team pensasse di aver isolato i loro problemi ogni retrospettiva? Il team ha agito per correggere i problemi. Il team non ha risposto e la direzione ha semplicemente dettato le soluzioni e la linea d'azione?

Dato il lungo arco di tempo, qualcosa non va sistematicamente, non semplicemente con gli sviluppatori. Ad un certo punto (prima di un anno è cresciuto) qualcuno del team (compresa la scrum master) dovrebbe aver chiesto, quello che, per quanto piccolo, può compiamo?

Nella tua situazione le retrospettive sono troppo tardi.
Tieni riunioni quotidiane di stand-up e ottieni veramente lo status delle persone su ciò che hanno fatto nelle precedenti 24 ore?
Lo Scrum Master sta usando quegli incontri per misurare i progressi di ogni sviluppatore rispetto ai loro obiettivi?
Devi usare quella parte della metodologia Scrum per monitorare i progressi mentre procedi. Dovrebbe darti una buona visione di ciò che la gente sta facendo.
Sono distratti? Trascorrere troppo tempo sul caffè, o sull'aiutare altre persone su SE / SO, leggere le notizie o fare ispezioni che non sono giustificate? O sono davvero a testa in giù, a tutto vapore davanti e completamente troppo impegnati? La visione quotidiana dovrebbe darti una buona idea. Aiuterà anche a mantenere gli sviluppatori concentrati sul compito da svolgere, quindi non devono ammettere di non aver fatto nulla ieri.
E ovviamente se segnalano progressi costanti per tutto lo sprint e continuano a non consegnare alla fine, mentivano e potrebbe essere il momento di un nuovo sviluppatore.

Stimare lo sforzo e il tempo necessari per completare un'attività complessa, come il codice di programmazione, è difficile. Come dice Joel Spolsky :

Agli sviluppatori di software non piace molto pianificare. Di solito, cercano di scappare senza uno. "Sarà fatto quando sarà fatto!", Dicono, aspettandosi che uno zenzero così coraggioso e divertente riduca il loro capo a una risatina, e nella conseguente giovialità, il programma verrà dimenticato.

Tuttavia, le società hanno bisogno di scadenze per operare. Come ha suggerito Joel, prova a utilizzare la pianificazione basata sulle prove che fornirà stime temporali con probabilità associata, alla quale la direzione può riferirsi come qualsiasi tipo di rischio.

Scrum fa alcune cose.

Innanzitutto, incoraggia la definizione delle priorità. Il fornitore di lavoro deve dire prima cosa vuole fare e non dire "tutto è ugualmente importante".

In secondo luogo, genera un prodotto un po 'utilizzabile anche se non tutto è finito. Questo è il punto di avere un "prodotto potenzialmente spedibile" alla fine di ogni iterazione.

Terzo, fornisce un circuito di feedback più stretto. Insistendo sul fatto che le cose siano "fatte" alla fine di uno sprint, eviti il ​​problema "Funzionalità 90% completa, ma solo a metà"; quando si spingono per le scadenze, è possibile mettere da parte le cose che devono essere fatte da parte in modo da sembrare quasi che si raggiunga la scadenza o si possa fingere. Avendo una definizione di fatto e insistendo sulle cose da fare, sai se qualcosa è più difficile di quanto sembri prima invece che dopo.

D'ora in poi, evita l'inventario avvicinando la pianificazione dettagliata allo svolgimento del lavoro. Pianificare cose lontane è una forma di inventario: capitale speso per risorse che non sono disponibili per la vendita o per l'uso immediato da parte dei clienti. Tale inventario può marcire (i piani cambiano sotto i piedi, le nuove informazioni lo rendono obsoleto), disallinearsi con le esigenze (risulta che non abbiamo bisogno di una rete distribuita whatzit, perché la cosa che lo utilizza non ne vale la pena) e ridurre il valore delle merci spedite (se nell'ultimo anno metà del tuo tempo è stato dedicato alla pianificazione per il prossimo anno e oltre, avresti potuto ottenere il doppio della spedizione se invece avessi lavorato su materiale per essere pronto per ora). Se riesci ad avvicinare la pianificazione all'esecuzione senza perdite (difficile!), Puoi ridurre l'inventario.

Non è l'unico modo per risolvere questi problemi. Sembra che tu stia usando la mischia in cui fornisce agli sviluppatori un flusso di lavoro su cui lavorare per ogni periodo di tempo, con l'aggiunta periodica di nuovo lavoro da fare e il controllo dei progressi.

Questo è un modo utile per usare schemi di mischia. Mantiene il flusso di lavoro, mantiene la pianificazione vicino alla produzione, fornisce alcuni cicli di feedback, ecc. Ha anche dei vantaggi in quanto non deforma lo sviluppo e i test per adattarli al sistema (se il test viene eseguito meglio con il lavoro è sostanzialmente finito , cercare di finire e testare le cose all'interno dello stesso sprint costringe il back-end dello sprint a non coinvolgere nuovi sviluppi!)

L'incapacità di mettere esattamente quello che stanno per fare in uno sprint non dimostra che i tuoi sviluppatori non stanno facendo un ottimo lavoro. Significa che non seguono SCRUM dall'alto, ma usano parti del framework.

Se avessero dimezzato (o diviso in quarti) quanto si sono impegnati per ogni sprint, ma hanno mantenuto tutto il resto uguale, allora avrebbero finito più di quanto si fossero impegnati per ogni sprint! Avresti la stessa quantità di codice prodotto. Chiaramente i "fallimenti di sprint" non sono la parte importante, perché questo è solo un dettaglio del processo interno. L'obiettivo dell'azienda è quello di fare la merda, e quella merda è buona; non seguire un processo specifico, a meno che il tuo obiettivo non sia un certo tipo di certificazione del processo ISO.

Il processo esiste subordinato all'obiettivo delle cose fatte.

D'altra parte, poiché non seguono le regole di SCRUM, non si ottiene lo stesso tipo di feedback. Dovresti esaminare le cose risultanti per vedere se il tipo di difetti prodotti sono i difetti che SCRUM è stato progettato per affrontare; ci sono storie che vivono per sempre come zombi e vengono uccise solo molto tardi? Ci sono storie che sembrano facili, esplodono e in una retrospettiva dove non vale il lavoro totale? Il prodotto è effettivamente spedibile nei momenti in cui è necessario / si desidera spedirlo?

"Il software è fatto quando è fatto, non prima, non più tardi" è una ricetta per il fallimento se non hai definito l'aspetto di "fatto".

La maggior parte degli ingegneri proverà a produrre la migliore soluzione possibile, ma ciò può facilmente portare alla doratura, specialmente con ingegneri meno esperti. Le uniche responsabilità del management sono definire esattamente dove si trova l'obiettivo e mantenere i vostri ingegneri in quella direzione. Gli ingegneri cercheranno spesso di prendere le svolte secondarie per migliorare le funzionalità e spetta alla direzione decidere se quella svolta accelererà le cose a lungo termine o se sta migliorando allo stesso modo del miglioramento.

Il punto di sviluppo agile è che ogni nuovo pezzo di lavoro dovrebbe essere buono come richiesto per soddisfare lo sprint E NESSUN MEGLIO !!!!!! Sì, questa è la maggior enfasi che posso aggiungere in StackOverflow - e non è ancora abbastanza enfasi. Se scopri che le persone stanno aggiungendo cose che non sono richieste in questo momento, allora hanno bisogno di formazione su come eseguire correttamente lo sviluppo agile.

Oh, e sì, usiamo retrospettive.

Oh bene, quindi sai perché la tua squadra sta fallendo, giusto? Hai avuto 36 opportunità di parlare di ciò che ha funzionato e non ha funzionato, quindi i maestri della mischia dovrebbero capire appieno come risolvere i problemi, giusto?

Ho la sensazione, secondo la descrizione che dai, che la tua azienda sia caduta nella mentalità "SCRUM ci rende produttivi". La verità è che SCRUM non ti rende produttivo. Piuttosto, è uno strumento che ti aiuta a renderti produttivo in un modo che identifica le realtà di sviluppo che sono spesso trascurate sia dal management che dagli sviluppatori.

Cosa ha identificato lo Scrum Master come potenziali problemi con il team? Assegnano costantemente il doppio del lavoro che possono gestire? In tal caso, lo Scrum Master dovrebbe suggerire delicatamente di svolgere meno lavoro, perché lo Scrum Master può controllare la velocità della squadra.

Quando è giusto cercare il problema nella qualità degli sviluppatori?

Il momento in cui si dovrebbe cercare il problema nella qualità degli sviluppatori è il momento in cui si è certi che sia il problema. Questo non è un nuovo problema creato da SCRUM. Questa è la realtà degli affari. MISCHIA dovrebbe darvi enormemente maggiori informazioni sulle capacità dei membri del team rispetto agli approcci tradizionali. Dovresti sapere se il problema è che "gli sviluppatori di software non sono abbastanza bravi" rispetto a "le aspettative di gestione non sono realistiche" in misura molto migliore di quanto tu possa capire con un approccio tradizionale. Questo è il momento per il management di fare ciò che il management fa meglio: capire le persone giuste per il lavoro, in modo che l'azienda possa fare soldi. Se non riesci a capire dove sia il problema, allora immagina quanto sarebbe difficile dire senza tutte quelle retrospettive!

Se pensi che le persone possano essere abbastanza buone (sottintendere che la loro assunzione non è stato un errore da parte della direzione), allora il mio consiglio sarebbe di iniziare a pensare fuori dagli schemi. Se il lavoro non viene eseguito, prendere in considerazione la modifica della forma del lavoro per gli sviluppatori. Uno dei modi più semplici che ho trovato per rispettare le scadenze per il completamento dello sprint è quello di adattare i criteri FATTO in modo che tu sia soddisfatto del risultato, indipendentemente da come viene fatto. Quindi essere completato diventa una tautologia.

Questo mette l'onere sulla gestione, in particolare il master SCRUM. Il trucco è scrivere attività che, se completate, sono molto preziose, ma se lasciate incomplete forniscono comunque abbastanza valore aggiunto all'azienda da meritare il loro stipendio. Dopo 18 mesi, mi aspetto che le tue retrospettive ti abbiano insegnato qualcosa. In caso contrario, forse dovresti scrivere le storie con l'intento esplicito delle storie fallite di scoprire qualcosa che non va nella tua azienda e portarlo alla luce. Ciò fornirebbe alla società immensi dati preziosi, data la frustrazione che la società sembra avere con il team di sviluppo. Il problema potrebbe davvero essere gli sviluppatori, come chiedi. Oppure il problema potrebbe essere una patologia nella mentalità dell'azienda di cui non avevi idea fino ad ora!

Se davvero il problema è con l'azienda, non con gli sviluppatori, le informazioni che raccoglierai da queste storie incomplete potrebbero davvero valere più del prodotto che raccogli da quelle di successo! Potrebbero essere le informazioni che salvano l'intera azienda! Mi sembrano informazioni davvero preziose e puoi usare SCRUM come strumento per aiutarti a raccoglierle.

"Quando è giusto guardare la qualità degli sviluppatori?"

Tutto il tempo. Ovviamente alcune persone sono più produttive di altre, non hai bisogno di una scusa come datore di lavoro per misurare le loro prestazioni.

La parte difficile è come lo fai. Il mio consiglio è di assumere alcuni contrasti esperti per lavorare a fianco del tuo personale permanente nello stesso insieme di compiti stimati dai tuoi ragazzi permanenti e vedere se hanno una velocità maggiore.

Questo ti darà un buon confronto con il mercato attuale senza bloccarti in un noleggio a lungo termine.

Potrebbe anche dare ai ragazzi del culo un po 'un calcio nel culo.

Inoltre, se si lamentano che gli appaltatori stanno saltando sulla qualità, ecc. Per ottenere velocità, ciò guiderà una conversazione su dove si trova il valore aziendale. Manutenibilità a lungo termine o prodotti a breve termine spediti.

Se è roba a lungo termine, ti costringerà a quantificarlo e metterlo nello sprint come requisiti!

Ci sono già diverse risposte eccellenti. In particolare, una cattiva stima, un impegno eccessivo e / o un lavoro non programmato sono frequenti cause di slittamento.

Ma sono curioso di sapere perché "i [tuoi] sviluppatori scelgono le funzionalità che vogliono includere in ogni sprint". Gli sviluppatori dovrebbero in genere lavorare prima sulle funzionalità con la massima priorità, e la priorità è una decisione aziendale, vale a dire che dovrebbe provenire dal proprietario del prodotto che funge da proxy per gli stakeholder aziendali.
(Ci sono eccezioni a questo. In particolare, le funzionalità ad alto rischio sono generalmente utilizzate in precedenza. E in alcuni casi una funzionalità rivolta all'utente può dipendere da altre funzionalità, ad esempio "dobbiamo davvero aggiungere un database prima di poter implementare X". )

D'altra parte, le stime sono decisioni tecniche e non dovrebbero essere prese (o ripensate) da uomini d'affari. Non dici nulla a riguardo - sollevo il punto solo perché, nella mia esperienza, quando gli sviluppatori scelgono su cosa lavorare, è abbastanza comune per gli uomini d'affari cercare di dettare quanto tempo dovrebbe impiegare.

Sembra che tu abbia un processo abbastanza disfunzionale. Raccomanderei di non coinvolgere consulenti degli sviluppatori, almeno per il momento, perché probabilmente questo avrà un effetto negativo sul morale. Ma sembra che la tua organizzazione possa usare un po 'di aiuto dal lato della gestione del progetto. È qui che vorrei iniziare, coinvolgendo un allenatore agile con esperienza - se non per un impegno a medio-lungo termine, almeno per una valutazione o un "controllo sanitario". Un buon allenatore ti dirà se hai sviluppatori poco performanti, ma almeno in questo modo, è l'intero team (non solo gli sviluppatori) che è sotto esame.

Un'altra osservazione: nella mia esperienza è molto difficile far sì che la mischia abbia successo come metodologia di gestione del progetto se non si seguono anche buoni processi di sviluppo. Stai eseguendo test di unità automatizzati? o ancora meglio, test di accettazione automatizzati? I tuoi sviluppatori si accoppiano o esegui almeno revisioni frequenti del codice e / o procedure dettagliate? Stai praticando una qualche forma di integrazione continua?