Quali sono alcuni metodi per evitare che gli sprint Agile Scrum diventino essenzialmente mini-waterfalls di 2 settimane?

La maggior parte dei suggerimenti qui sono buoni:

• rendere i test di accettazione del business-test di accettazione del business un prerequisito affinché le storie siano pronte per la pianificazione dello sprint
• utilizzando il test driven development (TDD)
• fondendo le epopee in storie e le storie in compiti
• seguendo i compiti in modo che alcuni siano completati all'inizio dello sprint proprio quando i tester completano la loro pianificazione dei test
• accorciando gli sprint per far risaltare i veri problemi
• scaldando i ruoli (se l'obiettivo è la qualità, tutti devono essere tester!)
• passare dalla cooperazione alla vera collaborazione (il valore centrale dei team ad alte prestazioni)
• meno passaggi di consegne
• auto-organizzazione; ...

Supporrei inoltre che:

• non si ha una definizione comunemente accettata di "fatto", e
• il team non viene premiato per aver soddisfatto tale definizione di fatto con storie che sono veramente "fatte".

Il che suggerirebbe che, come team, si definisca "fatto" e si cambi il sistema di ricompensa per premiare il rispetto della vostra definizione. Per usare solo un tocco di iperbole, se la qualità non fa parte della definizione, allora i tester dovrebbero andare a casa - non avete un lavoro - non importa a nessuno. Ma se la qualità fa parte della definizione, e se, come molti hanno detto, siete una squadra che si impegna:

• non accetterete storie nella pianificazione che non hanno test di accettazione del business
• farete una pianificazione dello sprint che assicuri che le storie raggiungano tutte il "fatto" entro i confini dello sprint e la pianificazione cambierà per alimentare più uniformemente il lavoro dei tester, gli sviluppatori abbracceranno TDD, e
• i membri del team termineranno gli sprint sciamando a fare test per assicurarsi che le storie siano davvero fatte.

Ma io'sto supponendo. Tutti noi lo stiamo facendo.

Lukasz Szóstek ha ragione: Questa è una grande domanda per la retrospettiva - e la retrospettiva (e l'apprendimento e il miglioramento continuo) sono fondamentali per la sfida continua di allinearsi con i valori e i principi fondamentali di agile e scrum.