La nostra versione di Agile non funziona. Suggerimenti?

because we're behind schedule

Questo tipo di pensiero è il tuo problema. Non sei dietro il programma, il programma è troppo stretto. Dovresti iniziare a stimare storie in punti astratti anziché ore e poi nel corso di 2-3 iterazioni capire la tua velocità. La tua velocità è quanti punti fai di solito ogni iterazione, non quanti punti il tuo manager vuole adattare.

Dopo questo, non importa se sottostimi costantemente le attività: la tua velocità ne giustifica già.

Ovviamente, questo è impossibile se usi ore invece di punti.

Sembra che i problemi siano l'incapacità del tuo team di fare stime accurate e l'incapacità di prevedere i problemi che l'inevitabilità comporta.

Le piccole attività sono molto più facili da stimare con precisione rispetto alle attività di grandi dimensioni, quindi prova a suddividere le tue attività in blocchi molto più piccoli.

Non permettere a nessuno di fare una stima per qualsiasi attività, a meno che non sappiano ESATTAMENTE come lo faranno. Per qualsiasi attività che lo sviluppatore non sa cosa completare, dedicare un po 'di tempo al programma di sprint dello sviluppatore per effettuare alcune ricerche e progettazioni e ottenere una stima accurata. Mai meno di mezza giornata. Ma sposta l'attività su NEXT sprint. Poi, quando arriverai alla pianificazione per il prossimo sprint, avrai una buona stima. Nota che questo tempo extra non è sprecato, perché è il momento che lo sviluppatore finisca per spendere in ogni caso.

E non aver paura di tornare dal project manager e dirgli che avrai bisogno di più sprint per ottenere l'elenco delle attività. È meglio farlo, piuttosto che impegnarsi per obiettivi impossibili.

Stai cercando di allocare il 100% del tuo tempo? Se è così, smetti di farlo. Inizia aggiungendo tutte le ore in cui la tua squadra deve contribuire durante lo sprint. Fai questo assumendo che ogni lavoratore nel migliore dei casi metta 6 ore al giorno verso il progetto. Questo è considerato un "giorno ideale". Quelle altre due ore? Risucchiato da riunioni, pause, attività amministrative, quella mattina al mattino quando leggi e-mail e pianifichi la tua giornata, ecc. Non si tratta di "proteggere le tue scommesse" o "sacchi di sabbia", è realistico.

Secondo, moltiplica 6 ore / giorno di 80% . Perché? Perché come esseri umani facciamo schifo nel predire quanto tempo impiegherà un compito. Questo spiega errori nel nostro giudizio. Ancora una volta, non sandbagging, è realistico.

Ora hai un numero che rappresenta un numero realistico di ore che ti aspetti di applicare direttamente alle tue attività. Quando stai valutando, smetti di aggiungere storie quando la storia successiva ti farebbe passare.

Infine, non lasciare che il proprietario del prodotto aggiunga attività. La pianificazione di Scrum è per il team , il PO non fa parte del team che sta facendo il lavoro. Naturalmente, nel mondo reale se il PO è più esperto di chiunque altro nella squadra, il suo contributo può essere molto utile. Tuttavia, se la squadra sta prendendo il caldo per essere dietro, il team deve assumersi la proprietà di esattamente quali compiti faranno. Il tuo obiettivo è essere in grado di soddisfare i criteri di accettazione; se un compito non porta direttamente a quello, non farlo.

Ricorda, Scrum non significa essere più produttivi. Si tratta di essere più aperti e comunicativi. Il lavoro richiederà tutto il necessario per essere fatto. Scrum è lì per rendere più facile la stima, più facile la comunicazione con gli stakeholder e più facile per il tuo team impegnarsi.

Criteri di accettazione mal definiti all'inizio dello sprint?

Le stime iniziali sono spesso troppo basse perché le story card hanno scarsi criteri di accettazione (se presenti) quando vengono stimati. Che dire del passaggio a Acceptance-Test-Driven Development (ATDD) alias storytesting per aiutare il team a chiarire cosa sia la carta?

Storie troppo grandi?

Un altro motivo per cui scopri a metà sprint che le tue storie richiedono più tempo del previsto potrebbe essere che sono troppo grandi. Hai visto il mazzo di carte Flash Agile in Flash ? Hanno una flashcard chiamata "Shrink XL stories to Fit". Fornisce strategie per dividere storie come casi differenziali, effetti collaterali, aspetti non funzionali o gestione degli errori nelle storie successive.

Impossibile stimare perché non si dispone di informazioni sufficienti?

@sleske è un buon suggerimento sui picchi . Prova e identifica le incognite tecniche al momento della stima. Se ce ne sono, vedi se puoi posticipare la storia in uno sprint successivo e invece fai un'indagine time-boxed (spike) per sprint per provare e imparare cosa sarebbe necessario per poter stimare. Non lasciarti trasportare e risolvi la storia originale - il picco è fatto quando ne sai abbastanza per stimare la storia.

Errore più veloce

E sono d'accordo con @Patrick Hughes - considera di passare agli sprint di una settimana in modo da poter vedere i problemi più velocemente.

Oltre ai buoni suggerimenti di @Kevin e @Patrick ...

Gli approcci agili non sono "taglia unica", ma questo commento ha attirato la mia attenzione:

We are implementing a version of Agile that seems to continuously provide us with the same difficulties

Stai meglio iniziando con una metodologia "dal libro" (Scrum è dominante al giorno d'oggi sembra) - e fai ESATTAMENTE quello che ha fatto un altro team di successo ... Fatelo per qualche sprint ... E solo allora iniziare a considerare le modifiche necessarie per ottimizzare le condizioni locali.

Affittare un allenatore Scrum esperto (per alcune iterazioni) può essere un vero e proprio fattore di differenza. C'è sottigliezza nel diventare agile giusto.

Per prima cosa raccomando il seguente libro scrum-xp-from-the-trenches . Guarda a pagina 26 il punto sui calcoli Velocity. L'idea è di definire un fattore di messa a fuoco e di dire quello per il prossimo Sprint:

available man-days * focus factor = estimated velocity

la velocità stimata è la somma delle stime delle storie che si intende implementare durante il prossimo Sprint.

E dopo uno Sprint calcoli il fattore di fuoco di Sprint come:

focus factor = actual velocity / available man-days

dove velocità effettiva è la somma delle stime delle storie che hai implementato durante lo sprint.

Quindi riutilizzi questo fattore di fuoco effettivo per il prossimo Sprint, e dopo qualche Sprint potrai essere più preciso con quanto riuscirai davvero a ottenere durante uno Sprint ...

Fino a quando non ottieni le tue stime per abbreviare i tuoi sprint a una settimana, in questo modo riconoscerai il superamento più velocemente e sarai in grado di reagire con incrementi più piccoli.

Dedica più tempo in anticipo quando si progettano le attività per ottenere un po 'di respiro in cui riconoscere gli effetti collaterali che probabilmente stanno causando la fuoriuscita dell'ambito. Potrebbe anche essere che i compiti stessi siano troppo lunghi per una corretta stima agile, vedere se le attività possono essere suddivise in fasi più brevi che saranno più facili da digerire.

Metti tutti a proprio agio con l'invio di una bandiera rossa non appena si imbattono in un intoppo anziché rimanere bloccati su un problema per alcune ore. Cerca di staccare l'ego e incolpati da questo processo, per alcuni è più facile di altri =)

E come ha fatto @Kevin, non pianifichi mai al 100% direttamente le attività perché ci sono sempre overhead come le riunioni e così via che potresti non riconoscere come mangiatori di tempo.

Quando tutto è a posto sul fronte della programmazione, poi torna indietro di due settimane, magicamente riprenderai un po 'di tempo dal minor numero di riunioni.