Ho notato che è abbastanza comune che queste sessioni di toelettatura coinvolgano attivamente solo una o due persone. In generale, ci sono alcune persone a cui piace discutere i requisiti del parlare e alcune a cui vogliono solo sapere cosa costruire.

Il tuo manager ha capito qualcosa dicendo che non è efficiente per tutti essere lì. Non tutti hanno bisogno di essere a una sessione di toelettatura; purché sia ​​più o meno chiaro a tutti cosa fare quando arriva il momento di fare l'effettiva sessione di pianificazione. È uno sforzo di squadra, quindi chi lo sa bene può sempre spiegare agli altri.

Quello che abbiamo fatto in passato è stato ruotare la persona / le persone che assistono alla toelettatura. Non è quasi mai produttivo coinvolgere l'intera squadra; una o due persone faranno le stesse domande, indicheranno le stesse cose che richiedono maggiori informazioni, ecc. E comunque quella settimana non verrà costruito nulla di discusso.

Chiedi al tuo team chi si diverte ad andare alla riunione e parlando di requisiti e chi no. Quindi inizia a inviare le persone che amano la riunione a parteciparvi da sole e lascia che si prendano alcuni minuti (o più, se necessario) alla fine della riunione per condividere ciò che hanno imparato con il team. Molto probabilmente ti ritroverai con lo stesso livello di comprensione e chiarezza, a una frazione del costo.

Non stai usando i termini Scrum, quindi immagino che tu non stia effettivamente facendo Scrum. Il mio primo consiglio sarebbe quello di ottenere un buon libro o, meglio ancora, un trainer.

Il tuo team di prodotto è quello che viene chiamato Stakeholder . E infatti, parlare con le parti interessate per trovare i requisiti non è compito del Team di sviluppo . Il Product Owner parla con le parti interessate.

Il Product Owner parla quindi con il Team di sviluppo in una preparazione per perfezionare le storie e renderle SMART ( Specifico, Misurabile, Realizzabile, Rilevante, Time-boxed) o INVEST (Indipendente, Negoziabile, Prezioso, Stimabile, Piccolo / Scalabile, Testabile) o qualunque acronimo sia aggiornato.

Dovresti avere un Scrum Master che non menzioni. E non c'è un team leader in Scrum. Sembra che stia facendo quello che dovrebbe fare il Product Owner, quindi forse è solo un'etichettatura errata?

Quindi sì, il tuo manager ha ragione. Il tuo Product Owner dovrebbe essere in quella riunione, per il team di sviluppo è solo una perdita di tempo (come dimostrato dalla loro non azione). Dovresti tenere un altro incontro regolarmente (normalmente chiamato "grooming"), in cui il Product Owner condivide le sue intuizioni dal primo incontro con il team e dove il team può porre domande e discutere i dettagli tecnici, nonché fare una stima. p>

C'è un punto chiave che manca nelle risposte: l'azienda è in Asia. C'è una componente culturale che deve essere richiamata e considerata separatamente. Molti asiatici si sentono a disagio nel esprimere un'opinione individuale quando sono in un gruppo.

In qualità di guida pratica / allenatore di mischia / evangelista agile, devi assicurarti che il team di sviluppo sappia che è un ambiente sicuro per commentare e offrire commenti il "Team di prodotto". Che non "perdano la faccia" o che non si creda che critichino il team del prodotto.

Dovrai cambiare / lavorare sulle norme culturali nei gruppi di sviluppo prima che le pratiche agili diventino naturali. Tieni presente che non è solo il gruppo di sviluppo che deve cambiare, ma anche i team di prodotto e i team di gestione. Se gli sviluppatori accettano il manifesto Agile, interrogheranno e forniranno feedback a Product and Management e quei gruppi dovranno rispondere in modo Agile. Se i gruppi di prodotto e gestione non cambiano nelle loro aspettative, allora Scrum non funzionerà.

Per me, questa suona come una decisione sensata da parte del tuo manager. L'elaborazione del backlog del prodotto è formalmente un compito del proprietario del prodotto, sebbene nella mia esperienza sia generalmente utile avere anche qualcuno di tecnico coinvolto nella discussione. Non forzare il resto del team a partecipare a una riunione per il gusto di tenere una riunione.

Il tuo manager ha ragione. Se Scrum fatto "come dovrebbe essere" non si adatta alla cultura dell'ufficio dei tuoi dipendenti, allora non devi farlo "come dovrebbe essere", ma adattare il modo in cui è fatto. Si suppone che Scrum sia un metodo agile, il che significa che adattare il processo al contesto, non il contrario.

Le persone fanno parte del contesto. Sembrano non adattarsi culturalmente a quell'incontro, così come è stato organizzato. Pertanto, tale riunione deve essere modificata.

Sembra che manchi qualcosa qui. Di cosa discuti durante le riunioni di mischia?

Dovresti fare stime del progetto durante le riunioni, invece di distribuire i programmi. Le stime più accurate vengono effettuate dalle persone che svolgono il lavoro . A volte questi incontri cercano di riunire persone esperte nel progetto, in modo che possano segnalare una stima inesatta o aiutare qualcuno che non può stimare.

A volte qualcuno non ha idea di come fare qualcosa a cui è stato assegnato per quello sprint e qualcun altro del team dovrebbe essere in grado di farlo notare.

Alcune persone sono migliori a comunicare per iscritto che di persona. Quindi questi incontri dovrebbero probabilmente essere svolti online, su uno strumento di comunicazione del team come Slack.

A volte le persone sono timide o hanno paura dei conflitti. Quindi la maggior parte della comunicazione dovrebbe avvenire con il leader del team e il resto del team in riunioni individuali. Questi uno contro uno possono essere estremamente efficaci e molte aziende affermate insistono su di loro.

Scopri PERCHÉ le persone non parlano. Hanno paura delle ripercussioni se un manager non è d'accordo con loro? Esiste una cultura della colpa e se le loro dichiarazioni portano a problemi questo può portarli a essere puniti (licenziati, anche)? È semplicemente una tendenza (che ho notato molto) di sedersi in silenzio, in attesa di sentirsi dire cosa fare da persone autorevoli, tenendo conto che questo è in parte collegato alle altre possibilità? Mancano di conoscenza del dominio o di conoscenza tecnica su qualsiasi cosa tranne una parte molto ristretta del sistema ?

Scopri cosa impedisce alle persone di fornire input, quindi fai qualcosa al riguardo. E questo potrebbe essere doloroso per alcuni, soprattutto se si tratta di una cosa culturale nell'azienda e le persone al potere devono cambiare il loro modo di fare le cose.