Sviluppo agile in cui la collaborazione con il cliente è difficile

Uno dei principali responsabili dello sviluppo Agile è che il cliente fa parte del team. Prende entrambe le parti per adottare Agile, quindi:

PASSO 1

Prendi il cliente dalla tua parte prima di procedere. Agile non riguarda il tuo team, riguarda la collaborazione tra YOUR TEAM e CUSTOMER.

In secondo luogo, Agile è una metodologia, non è perfetta, non è una panacea, è semplicemente un altro modo di fare le cose, che funziona bene per i piccoli team con i clienti seduti accanto a loro.

PASSO 2

Scopri la metodologia agile e determina se REALMENTE renderà le cose più veloci e applicherai ai tuoi clienti. I grandi clienti aziendali sono difficili da coinvolgere nei progetti, tendono a trascinare i piedi e richiedono comfort con la semplice vecchia cascata.

PASSO 3

Probabilmente torna al punto 1 perché il tuo cliente non è ancora chiaro su cosa è agile e perché ne ha bisogno ... parlando di 6 anni di esperienza con un enorme client aziendale.

Alcuni dei problemi che dovrai affrontare:

• Il client ha lavorato con waterfall per anni e non è disposto a cambiare, perché waterfall dà loro un senso di sicurezza quando hanno in anticipo le scadenze (anche se le scadenze scadono del 300% entro la fine del progetto, ma nessuno sembra vederlo)
• Il cliente non capisce quanto agile lavori e accetta, quindi richiede immediatamente una stima L1 fornita dal lunedì della prossima settimana.

• Il tuo team non ha idea di cosa sia l'agilità e il processo sarà una costante lotta per mettere in contatto le persone contemporaneamente e allo stesso tempo cercare di coinvolgere anche i clienti.

  Lo so che agile potrebbe aiutarci a dare un'inversione di tendenza più rapida, ma sto cercando di immaginare come possiamo sostituire questi documenti ingombranti oggi con brevi storie di utenti che si concretizzano attraverso le collaborazioni con i clienti.

Passeresti molto tempo a provare a convertire il client in modo da utilizzare agile e quindi la qualità delle storie degli utenti sarebbe estremamente bassa.

Il modo corretto di agire secondo me:

1. Sai cos'è Agile e come viene applicato molto bene.
2. Trascorri del tempo e insegna al tuo cliente aziendale gli straordinari mentre li aiuti a noleggiare un BA che è agile-savy.
3. I BA diventano proprietari di prodotti da parte del cliente e iniziano a lavorare in modo EFFICIENTE con il tuo team.
4. Rompa la tua squadra in gruppi più piccoli per area del sistema del cliente e ogni team ha il proprio BA come proprietario del prodotto.

L'IT è anche discutibile se puoi fare agilità da remoto. Ho visto alcuni team farlo e altri hanno fallito miseramente.

Conclusione: Prenditi il tuo tempo e apporta le modifiche lentamente. Scegli un processo ibrido che funzioni per te e il TUO cliente. Collaborare con il cliente e non cercare di attenersi a una metodologia al 100%. Dove ci sono persone, ci sono aggiustamenti da fare per ottenere efficienza. Non cercare di passare ad Agile perché "tutti i bambini fantastici lo fanno".

Sebbene siano state fornite importanti motivazioni di supporto e spiegazioni, la domanda principale sembra essere:

...how do you make this work effectively when there is distance between the developers and the users?

Per me, questa sfida non è unica per Scrum. Una collaborazione efficace tra individui dispersi geograficamente è una sfida comune. Mentre l'impatto di questa sfida può essere maggiore in mischia, dove la collaborazione è il re, le soluzioni potenziali sono ancora simili. Includono:

• viaggio fisico (come hai detto)
• conversazioni telefoniche e teleconferenze (che presumo tu possa anche fare, ma non ho menzionato)
• semplici videoconferenze
• ambienti di collaborazione online più sofisticati, lavagne condivise, ecc.

Sfruttare alcune delle soluzioni comuni sopra indicate sarebbe probabilmente vantaggioso, indipendentemente dal grado in cui hai adottato pratiche Agile.