Gli sprint / iterazioni agili dovrebbero essere fatti contro schiena?

whether the notion that sprints/iterations in agile development should always be back-to-back

Sì. Uno Sprint è timeboxed e lo sprint successivo inizia subito dopo la fine del timebox precedente. Questo fornisce la cadenza e il ritmo di uno Scrum sprint.

with only a review and planning meeting to separate them from each other

Recensioni e Retrospettive si svolgono alla fine di uno sprint. Sprint Planning viene fatto all'inizio dello Sprint. Questi Scrum Events fermano lo Sprint effettivo, al contrario degli "in-between" Sprint.

There is no rest. We sprint, and then we sprint again, and then it continues on, supposedly forever. When we "slow down" to manage tech debt, we do it in a "Sprint".

Il pagamento del debito tecnico fa parte delle storie da completare all'interno dello Sprint. Idealmente, il debito tecnico non dovrebbe maturare molto se facciamo la maggior parte delle pratiche XP (cioè test prima, refactor senza pietà).

Naturalmente nel mondo reale, il debito matura. Una buona strategia è assegnare del tempo per il refactoring mentre le User Story vengono scomposte in sottoattività. Ad esempio, una User story del Product Backlog è scritta in modo tale che il valore per l'azienda è dichiarato , ma quando lo decomponiamo in attività costitutive, stimiamo correttamente che il codice esistente debba essere modificato per il nostro nuovo funzionalità alla quale integrare. Alla fine dello Sprint, gli sviluppatori ottengono il loro valore in un codice migliore e l'azienda ottiene il loro valore nel software di lavoro .

Can't we do a few sprints to get a core feature/product delivered and then do no sprints until we are really ready to take on the next big piece?

Inviterò il team di sviluppo a rivedere le loro pratiche di codifica, se potrebbero esserci dei miglioramenti in modo che la qualità possa essere incorporata . Forse la programmazione di coppia? Recensioni di codice? Membri anziani che richiedono più tempo per guidare gli altri? Test-Driven-Design per ridurre al minimo i bug e assicurarsi che non siano overprogettazione / doratura?

E le Sprint Retrospectives? Si stanno sollevando problemi di squadra e si cercano tentativi di miglioramento? Le cartelle Daily Scrum si trasformano in "rapporti di stato" del Project Manager della vecchia scuola? Il Product Owner rispetta la decisione del team di sviluppo in merito alla capacità delle storie di essere eseguite in uno Sprint?

Ci sono molti modi possibili in cui Scrum può essere ottimizzato per ottimizzare le prestazioni. Finché il team mantiene i pilastri fondamentali di Scrum su Trasparenza (le persone sono in anticipo rispetto a ciò che sta accadendo), Ispezione (sia il lavoro che il processo di lavoro vengono valutati equamente ma realisticamente) e Adattamento (facendo qualcosa per migliorare una situazione), ogni iterazione dovrebbe risolversi in una migliore.

Ulteriori letture dalla Guida di Scrum

Uno sprint è semplicemente una raccolta di lavoro (elementi del backlog) da eseguire che fornisce un certo valore al prodotto. Può aggiungere una nuova funzionalità, può essere refactoring del codice esistente per rendere più facile la manutenzione, la risoluzione di bug o qualsiasi altra via di mezzo. Ogni sprint è limitato nel tempo, di solito da 1 a 4 settimane. C'è una pianificazione all'inizio e una demo / recensione alla fine per distinguere uno sprint da un altro, ma altrimenti si susseguono uno dopo l'altro.

Se hai fatto un paio di sprint per sviluppare una funzionalità di base e poi non hai fatto nessuno scatto fino a quando non sei pronto per affrontare la prossima grande funzione, cosa faresti durante quel periodo?

Se stai facendo troppo durante i tuoi sprint (quindi ti senti come se fossi sempre uno sprint, piuttosto che correre una maratona), potresti voler rivisitare quanti punti della storia prendi durante ogni sprint; potresti fare troppo Una serie occasionale di lavoro può essere OK, ma porterà rapidamente al burnout se è la norma. Potresti anche voler cambiare quando i tuoi sprint iniziano e terminare - la pianificazione dello sprint di lunedì e la demo / revisione di venerdì ti offrono una pausa naturale tra gli sprint.

Questo è un problema piuttosto comune per gli sviluppatori di Agile Scrum, ed ecco la cosa che non vorresti sentire: causi il tuo burn out per la maggior parte, dal momento che il lavoro è in corso, con un aiutare la compagnia non aiuta quando qualcuno termina la relazione per qualsiasi motivo.

L'altra cosa che vorrei menzionare è che potrebbe essere utile affrontare lo sprint come un grafico a torta di priorità, in modo da avere il 10% della torta verso il debito tecnologico. Dare uno sprint a un tema può essere d'aiuto anche per quanto riguarda l'obiettivo di non renderlo monotono.

O semplicemente passa a kanban, scrum non si adatta a tutti gli scenari, è soprattutto un po 'incerto sulla manutenzione.

Stai (presumibilmente) lavorando cinque giorni a settimana. Scrum è un modo per gestire il lavoro. Quindi perché non usare la mischia cinque giorni ogni settimana?

È un po 'faceto, ma il fatto è che se pensi che la mischia sia abbastanza buona per lavorare sulle funzionalità, perché non la consideri abbastanza utile per lavorare su tutto il resto?

The Rhythm of Scrum

Parte di ciò che rende scrum il lavoro è che mette la tua squadra in un ritmo: pianifica un po ', lavora un po', rivaluta, pianifica un po ', lavora un po', rivaluta e così via. Il ritmo stesso aggiunge una piccola quantità di valore aziendale, quindi non dovrebbe essere buttato via.

Prendendo un respiro

Se ritieni che la tua squadra abbia bisogno di riposo, puoi riposare durante uno sprint. Collabora con il proprietario del prodotto per riempire uno sprint con alcune attività più facili. Non c'è nulla nella guida di scrum per impedire a te e al proprietario del prodotto di ottimizzare l'arretrato per un po 'di respiro ogni tanto. Il tuo team dovrebbe comunque fornire valore per il business, ovviamente - le aziende non pagano dipendenti solo per scherzare, tu sei lì per fare un lavoro.

Guarda i segnali di pericolo

Tutto ciò detto ... se senti che la tua squadra ha bisogno di un attimo di respiro, forse è un segnale che stai facendo qualcosa di sbagliato. Gli sprint non dovrebbero in realtà essere uno sprint letterale. Non dovresti lavorare il più duramente possibile per la durata dello sprint. Il tuo ritmo deve essere sostenibile. Se non lo è, forse questo deve essere sollevato nella prossima retrospettiva.

Ci sono framework che alterano in qualche modo la cadenza. Ad esempio SAFe (in scala Agile Framework) utilizza il concetto di Incrementi di programma (PI) che sono un insieme di 4 sprint (di solito 2 o 3 settimane), seguiti da una settimana Innovazione e pianificazione Iterazione che mette da parte il tempo per la formazione degli sviluppatori, la pianificazione per il prossimo PI e altre attività. È una specie del meglio di entrambi i mondi. Ottieni la cadenza che rende efficace la mischia, ma ottieni pause programmate a intervalli regolari per evitare che le cose si sentano come una marcia della morte.

Se non sei o non puoi usare qualcosa del genere, ti consiglierei qualcosa di simile al suggerimento che @Bryan Oakley ha avuto per stimolare il lavoro per evitare il burnout.

Prima di tutto, evita di pianificare l'utilizzo al 100% all'inizio dello sprint. Un buon numero di lavoro corrisponde all'80% della tua capacità storica. Questo è il numero che dai all'OP al momento della pianificazione. Ciò ti lascia il tempo di ammalarti, ad esempio o di aumentare l'escalation del servizio clienti. Se trovi che hai tempo, puoi sempre aggiungere altro lavoro dal backlog.

In alternativa, puoi stipulare un accordo con il tuo Product Owner in cui viene speso una certa percentuale di tempo sul debito tecnologico o sullo sviluppo personale. Dove sono stato, abbiamo utilizzato formule come il 15% del debito tecnologico, il 10% dello sviluppo personale. È facile dimostrare che queste attività hanno un valore aziendale anche se non generano un nuovo codice di lavoro.

Mi sembra che tu sia in un'organizzazione che usa "Sprint" come uno stato eccezionale. Ad esempio, l'ordinaria cadenza di sviluppo è più di un "lope" o "mosey", e ad alcuni manager è piaciuto invece il suono dello sprint, e lo ha descritto come un temporaneo acceleratore che poi è rimasto intorno perché produce più valore.

That Is not Scrum [TM]. In Scrum, uno sprint può avere tanto lavoro quanto il team si impegna ad avere in esso, come negoziato con il Product Owner.

Se il team di sviluppo si sente come un mulo che esegue il Kentucky Derby, beh, anche That Is not Scrum.