Come bilanciare la velocità degli Sprint con il programma di adozione prudente del cliente?

Conserva i tuoi cortometraggi internamente, finché il cliente non è pronto. Quindi, rilascia il cliente in uno dei tuoi cicli di quattro settimane.

Se possibile, chiedi al cliente di partecipare alle revisioni del software tra delle relative date di rilascio, in modo da poter tenere traccia degli sprint.

Gli sprint non riguardano la distribuzione

Gli sprint sono per gli sviluppatori, riguardano gli impegni per i deliverable, non le distribuzioni da parte dei clienti.

L'obiettivo di uno Sprint è avere un Deliverable . Non c'è alcun obbligo di consegnarlo effettivamente molto meno distribuendolo.

Ogni team in cui sono stato produce molte altre build deliverable di quelle che il team operativo potrebbe implementare e promuovere alla produzione.

Software come servizio

SaaS è una circostanza specifica, puoi consegnare ciò che vuoi quando vuoi, ma non rompere la compatibilità senza preavviso, se non mai. Niente ti impedisce di implementare nuove funzionalità API insieme a quelle vecchie e di contrassegnare quelle precedenti deprecate .

Avere una politica di fine vita e supporto molto pubblica in modo che tutti sappiano cosa aspettarsi e quando aspettarsi che il supporto finisca.

How do you balance the need for rapid sprints with the customer's conservative view of application change?

Per come la vedo io, se il cliente non ha bisogno di / desidera un'altra consegna in 3-4 settimane, non c'è bisogno di uno sprint rapido.

Il saldo qui sarebbe quello di modificare il ciclo di sviluppo per soddisfare le loro aspettative.

Se tutto ciò che stai dicendo è che non vogliono implementare frequentemente live, quindi impostarli su un server dimostrativo pubblico e fare la tua fine di sprint di implementazione / revisione lì.

Se stai dicendo che in realtà non vogliono passare molto tempo a gestire il prodotto, puoi alleggerire il carico di lavoro o continuare con il rischio di rilavorazione.

Molte volte in queste ultime situazioni il PM o l'addetto alle vendite finisce comunque col riempire il ruolo del cliente, indipendentemente dalla durata dello sprint perché il cliente non è interessato a partecipare. È sfortunato e porta a una rielaborazione più ampia, ma è vero.

È essenziale che tu faccia partecipare il cliente. L'intero punto di iterazione è ottenere il feedback dei clienti. Il feedback ti consentirà di adattare il corso.

How do you balance the speed of Sprints with the customer's conservative adoption schedule?

Il vantaggio di SCRUM non si sta sviluppando più velocemente, si tratta di avere una direzione migliore. Ciò significa che raggiungerai il tuo obiettivo molto più rapidamente. Ma non puoi modificare la tua direzione senza il feedback dei clienti.

Abbiamo avuto successo nel far entrare il cliente aggiungendo una versione "beta". È fondamentalmente una seconda versione di produzione. Funziona sul database di produzione, ma viene aggiornato ogni giorno dal controllo del codice sorgente. È incredibilmente utile ricevere feedback sugli articoli su cui hai lavorato ieri. E le persone conservatrici possono rimanere sul normale rilascio di produzione.

Ecco un buon articolo su Boyd's Law of Iteration . Il pilota da combattimento iterato rapidamente non vincerebbe senza feedback.