Quali sono alcuni modi efficaci per rendere la Scrum più dinamica prima di uno sprint?

Il tuo problema si presenta come la tipica "cascata in ogni sprint", se esegui i veri test nella seconda settimana i problemi appaiono nella seconda settimana.

Nella mia esperienza ci sono varie aree che puoi migliorare:

• Crea cronologie degli utenti di piccole dimensioni, forse uno o due giorni per cronologia, in questo modo alla fine della prima settimana hai alcuni Stati Uniti completamente sviluppati e testati.

• Rivedi le tue pratiche tecniche. Agile non funziona solo con i post-it, il team sta usando tecniche appropriate come TDD o integrazione continua? (questi due sono fondamentali per controllare le ipotesi precedenti nel processo e non presentano questo sintomo "all'ultimo momento tutti i problemi emergono").

• Il tuo discorso su analisti, tester e sviluppatori, sembra molto specializzazione. Ciò non è negativo di per sé, dipende da molti fattori, ma forse è necessario fare qualcosa per migliorare la comunicazione dal primo giorno di sprint, ad esempio provare gli sviluppatori ad associarsi con analisti di business o tester.

E il più importante: utilizzare le retrospettive per discutere di questi problemi, cosa ha pensato il team ?, quali soluzioni propongono ?. Alla fine della giornata la tua soluzione è all'interno del tuo team non in overflow dello stack: P

Blockers and scope creep tend to emerge into the second week

Oh, Hell No! Ferma subito lo sprint. Questo non reggerà. I proprietari di prodotti devono comprendere le conseguenze di un'interruzione di uno sprint. Dobbiamo ricominciare da capo.

Scopri se c'era un modo per evitare questo problema (ci siamo persi qualcosa.). Vai all'inizio di un nuovo sprint. In questo modo si appianeranno gli "high" nel progetto, quindi dopo non tutti si sentiranno così bassi. Liscio e costante Niente panico. Nessuna marcia della morte ogni 2 settimane.

Standup - Non mi importa se ieri avevi la testa bassa in codice tutto il giorno, cosa hai fatto ?, cosa hai intenzione di fare oggi? Non è lussuoso e non ha bisogno di essere intrattenuto. Resta sveglio tutti per 15 minuti - non è così difficile. Ognuno dovrebbe ancora essere eccitato per aver dovuto ripetere lo sprint.

Solo perché sono chiamati sprint, non significa che il progetto non è una maratona.

Sembra che tu abbia un numero di disfunzioni, ma qui ce ne sono due che cercherò di trattare in anticipo:

La tua domanda iniziale mi dà l'impressione che tu stia lavorando come un gruppo di individui. L'analista fa il suo bit, lo passa allo sviluppatore che fa il suo bit prima di passarlo a un tester ... e così via. Scrum ha bisogno di individui interfunzionali, non specialisti del silo.

I team Scrum si concentrano spietatamente sullo spostamento di un singolo articolo del backlog del prodotto. Non si legge come questo sta accadendo con la tua squadra. Il recente annuncio di bloccanti e lavori emergenti mi dà l'impressione che tu stia facendo una mini-cascata in cui tutti i test vengono lasciati alla fine.

Quindi, in base alle mie ipotesi, ecco il mio consiglio:

1. Incoraggiare l'abilità interfunzionale nel gruppo di scrum. Non c'è alcun motivo per cui un tester non può aiutare con l'analisi o uno sviluppatore di software non può aiutare con i test, ecc. Il team fa il lavoro che ha di fronte e ha bisogno di fare.

2. Riduci work in progress (WIP). Concentrati sullo spostamento di un articolo del backlog prodotto su "fatto" prima di avviare il successivo. Sì, a volte è sciocco perché ci sono persone che si calpitano l'un l'altro, quindi prova questa semplice guida: la quantità di articoli del backlog prodotto su cui si lavora contemporaneamente deve essere non più della metà della dimensione del team.