Perché e per quali motivi gli sviluppatori potrebbero non apprezzare la "mischia quotidiana"? [chiuso]

Ci sono vantaggi nel tenere la mischia quotidiana, come:

1. Il team viene coordinato tra loro
2. Tutti sanno quale compito è stato svolto
3. Il grafico di Burndown diventa sempre più completo
4. La scheda delle attività è stata aggiornata
5. Non dura molto, 15 minuti non uccideranno nessuno

Tuttavia, di recente (dopo 6 mesi di implementazione e utilizzo di scrum), mi sembra che ai nostri sviluppatori non piaccia più così tanto lo scrum ogni giorno. La gente aggiorna semplicemente la bacheca delle attività, senza spiegare abbastanza e sembra che ne sia annoiata. Vedo che quando per qualsiasi motivo, non lo riteniamo, diventano più felici.

Semplicemente non so cosa potrebbe esserci di sbagliato in questo. Ci sono dei motivi menzionati da qualche parte per gli svantaggi che la "mischia quotidiana" può avere per una squadra? Quali potrebbero essere i motivi per cui gli sviluppatori si stancano della mischia quotidiana?

Ho avuto esperienza nella partecipazione a un team "SCRUM" con diversi datori di lavoro. Mi sembra che i manager prendano la "riunione della mischia quotidiana" come il punto principale di SCRUM e lo fissino come obiettivo, invece di averlo per quello che è: un mezzo per raggiungere un ciclo di sviluppo più efficace .

Molto rapidamente gli incontri di 15 minuti sono diventati incontri di 45 minuti, gli aggiornamenti erano inefficaci perché le persone sarebbero state impegnate a sbadigliare e pensare "quando possiamo già andare" invece di ascoltare gli altri, e spezzerebbe anche le routine delle persone (io, per esempio, sono una persona civetta, e andare a lavorare alle 9:00 per questo stupido incontro ogni giorno è una buona ragione per me per lasciare il lavoro).

Quando i manager prendono un'idea che può essere buona se applicata correttamente e la portano all'estremo, ottengono l'esatto contrario dei risultati che si aspettavano. Io personalmente penso che i più incontri partecipo - meno lavoro che sto facendo. Ho 2 incontri regolari a settimana nel mio calendario e di solito ne salto uno. Le riunioni sono per i manager, lasciano gli sviluppatori a fare il loro lavoro.

Sono sicuro che ci saranno molti appassionati di SCRUM che diranno "Ma è così meraviglioso" - beh, salvalo, ho sentito tutto.

Troverei quotidianamente noioso e inutile alzarmi in piedi se sentissi che c'era poco o nessun valore in esso. Ci sono alcune cose che possono ridurre l'utilità di uno standup quotidiano.

• Le informazioni condivise non mi riguardano né influenzano in alcun modo.
• Assenza della proprietà del team e tutti lavorano sempre ai propri progetti.
• Assenza di comunicazione di squadra fuori dallo standup.
• Mancanza di progressi visibili o comunicati.
• Assenza di informazioni da condividere.

Questi sono appena fuori dalla mia testa, ma ci sono sempre più possibili ragioni.

Forse dovresti semplicemente chiedere agli sviluppatori perché non sembrano essere interessati? Se vuoi una comunicazione migliore / migliore, dovrebbe iniziare da te.

Alcuni dei problemi riscontrati con le riunioni SCRUM quotidiane:

• quelli che durano troppo a lungo. Non vuoi nessun tipo manager in quei quotidiani perché sono la causa principale di questo tipo di problemi. Guarda come saranno di solito quelli che usano una sedia (sì, doversi alzare per quelli è invogliare le persone a essere veloci)
• dover sentire parlare di qualcuno (o 2 o 3 sviluppatori) che descrive a lungo qualunque problema isolato abbia invece di decidere di programmare un altro vero incontro in seguito per discuterne con gli interessati
• ore stupide. Quelle riunioni non devono essere al mattino: non stai parlando di quello che hai fatto ieri e stai decidendo cosa farai oggi; stai parlando di quello che hai fatto tra l'ultimo quotidiano e questo e stai decidendo cosa farai fino al prossimo.
• mancanza di proprietà dell'app per gli sviluppatori. SCRUM funziona se gli sviluppatori non sono trattati come scimmie di codice. Il primo segno del fallimento del processo è quando gli sviluppatori non sono quelli che valutano quanto tempo ci vorrà per fare qualcosa.
• ore stupide di nuovo. Se parte del team ha iniziato a lavorare su alcune cose e si trova "nella zona" quando si verifica il quotidiano, diventa un problema. Un buon momento per avere quelle quotidiane è quando nessuno dovrebbe lavorare (dopo il pranzo, per esempio, o poco prima di iniziare alcune discussioni durante il pranzo).

Il tempismo è il killer per molti. Ai programmatori piace programmare tardi, dormire fino a tardi ed entrare dopo la corsa mattutina. Dover essere in carica a un orario prestabilito, troppo presto per loro. E troppo tardi per gli altri che potrebbero entrare prima e iniziare a lavorare già.

Il flusso è un altro problema. Un programmatore in flusso con alcune funzionalità funzionerà fino a tarda notte, tornerà a casa e tornerà ricaricato e pronto per continuare. Dover partecipare a una riunione con problemi per lo più indipendenti potrebbe distrarlo.

La mia osservazione è fin troppo spesso che questi incontri sono per i manager per sembrare e sentire che stanno effettivamente facendo qualcosa piuttosto che essere utili per il team e il progetto.

Ad esempio, a un team viene assegnato di eseguire una serie di brevi correzioni di bug su diversi progetti. Non stanno davvero lavorando come una squadra ma come individui. Tuttavia, poiché la politica aziendale / di reparto lo impone, il responsabile / responsabile del team organizza comunque una riunione di mischia giornaliera. Tutto ciò che viene realizzato è prendere più di 15 minuti per una riunione inutile e affrontare 15-30 minuti di distrazione e mancanza di produttività prima e dopo la riunione.

Ora, ho visto la mischia ben eseguita in un progetto che aveva scadenze ravvicinate e richiedeva molto coordinamento tra le persone che lavoravano su vari pezzi. In quel contesto è stato un grande sistema. Ma, nel contesto di "Stiamo avendo un incontro perché siamo una mischia / negozio agile ed è quello che dovremmo fare" può davvero fare schifo.

Assicurarsi che nessuno monopolizzi l'incontro.

Se 4 sviluppatori riescono a togliersi di mezzo in 5 minuti e i successivi 10 minuti vengono spesi ascoltando il leader del team che illustra in dettaglio tutti i fantastici e fantastici nuovi sviluppi che ha realizzato, molti dei quali non sono né così sorprendenti né così fantastici come pensa di essere, le persone si annoieranno molto rapidamente.

Fai un passo indietro e pensa alla tua squadra:

• Stanno funzionando efficacemente?
• Le attività sono completate in tempo?
• Il codice è robusto e ben scritto?
• Il team si assicura che nulla cada attraverso le crepe?
• Il team si coordina in modo da non duplicare il lavoro o calpestarsi l'un l'altro?

Se la tua risposta a tutte queste cose è "Sì", forse dovresti considerare perché vuoi forzare il lavoro intenso come riunioni quotidiane, grafici di burndown e task board nel tuo team. Quale valore aggiunge? Vuoi generare dati burocratici esclusivamente per il tuo divertimento o stai cercando di rendere il team più produttivo?

C'è stato un calo della produttività da quando si sono interrotte le mischie quotidiane o tutto procede come prima? Se nulla è cambiato, perché continuare gli incontri?

15 minuti. Quei 15 minuti (più il tempo per prepararsi) trasmettono abbastanza informazioni nuove e utili tra i membri del team per migliorare la produttività dei team per il prossimo giorno di oltre 15 minuti? Se non c'è quella quantità di utili contenuti di mischia ogni giorno, i membri del team probabilmente pensano che farebbero molti più progressi verso gli obiettivi se uscissero da questa riunione al più presto e tornassero al lavoro.

Se vuoi semplicemente aggiornare la scheda e il grafico di frequente, metti le bozze di copie su un wiki.

Suggerirei di tenere la riunione retrospettiva per vedere "Cosa è andato bene" e "Cosa non è andato bene" e vedere se gli sviluppatori elencano la riunione Stand-up giornaliera come una perdita di tempo. Quindi dovrai riorganizzarlo un po '.

La mia esperienza personale:

• L'obiettivo è sapere cosa stiamo facendo oggi e dove eravamo ieri. Invece di attenersi all'agenda, entra in una discussione tecnica sui bloccanti tra 2 persone e le altre 15 si annoiano. Identifica il problema ma discuti di fuori
• Le persone non entrano nella sala riunioni in tempo, e questo diventa un ciclo fatto da alcuni di proposito. Quindi lo Scrum Master deve avere una discussione tranquilla con loro al di fuori della riunione per assicurarsi che inizi e finisca in tempo.
• Aggiorniamo già i grafici di burndown al di fuori della riunione Scrum in modo che non sia lo scopo principale dello stand-up quotidiano.

La resistenza arriva quando: 1) Sono usati per costringere le persone a correre dentro per le 9 del mattino. È più stressante quando il treno è in ritardo. 2) Scarsa leadership nella mischia. Il leader dovrebbe dire alle persone di mettere le cose fuori linea piuttosto che farle stare in piedi ascoltando qualcosa che non le influenza. 3) Contenuto senza valore. Questo è di nuovo un problema di leadership nella mischia. Dovrebbe essere un forum per affrontare colli di bottiglia, problemi di traiettoria e potenziali collaborazioni. Ciò che realmente accade è che tutti dicono semplicemente ciò che si aspettano di lavorare in quel giorno, che non è di alcuna utilità o interesse per nessun altro. 4) In piedi. Non sopporterò la posizione. La logica alla base era che incoraggia le persone ad essere brevi. Le persone in realtà fanno solo rumore.

Sono riuscito e ho fatto parte delle squadre della mischia molte volte. La ragione principale per cui agli sviluppatori non piace la mischia sono:

• Dato che sono gestiti da un misero maestro di mischia, se si trasforma in 45 minuti il ​​tuo scrum master deve migliorare nel controllo della mischia.
• La ragione più grande e di gran lunga la più onesta per cui non gli piace, è perché è molto difficile nascondersi in una cattiva etica del lavoro, cioè, più palesemente, mostra persone pigre. Alcuni sviluppatori con cui ho lavorato sono scioccanti, impiegano giorni a svolgere compiti che dovrebbero durare 30 minuti. Un buon PM dovrebbe rimuovere le barriere per gli sviluppatori, il che significa che dovrebbero essere in grado di superare i loro compiti in uno sprint. Agli sviluppatori non piace perché devono alzarsi ogni giorno e dimostrare i progressi che hanno fatto. Provoca ansia quando non possono dimostrare progressi per qualsiasi motivo. Se è a causa di un problema valido, un buon mastro scrum dovrebbe risolvere il problema al più presto.

Il problema si presenta quando i maestri della mischia non hanno l'autorità, le capacità o le capacità per risolvere i problemi di blocco. In effetti ho visto alcuni problemi solo seppellire sperando che se ne andassero. Questo è disastroso.

Francamente, nel 99% delle riunioni di scrum giornaliere a cui ho partecipato, praticamente tutte le discussioni / domande / risposte avrebbero potuto essere risolte con poche e-mail.

Onestamente penso che dobbiamo mostrare ragioni più valide per NON tenere riunioni. Costruisci ambienti in cui quando è il momento di radunare tutti in una stanza di persona, è meglio che sia una buona ragione ed essere organizzati per massimizzare l'efficienza del tempo.

Odio le riunioni in generale e preferirei utilizzare la videoconferenza, i telefoni, le e-mail, qualsiasi cosa mi permetta di entrare o rimanere nel mio lavoro senza dovermi alzare e interrompere il mio flusso di produttività.

Personalmente penso che se hai più di quattro riunioni in un periodo di 8 ore, i progetti non vengono gestiti bene.

Ci sono molti fattori che contribuiscono alla tensione sulle riunioni. Considera questi come alcuni dei motivi importanti per cui le riunioni potrebbero costarti di più di quanto valgono:

• Focus: software rispetto alle riunioni
• Gestione - i manager hanno bisogno di misurazioni
• Personalità: introversi contro estroversi
• Tempo - interrompe, tempo Maker e Manager
• Obiettivi, priorità

Ognuno di questi fattori è spiegato di seguito,

Focus : mi piace sviluppare software e questo include pensare alle sfide (problemi), creare soluzioni, costruire software e riunioni distrarre dalla concentrazione sui compiti che compongono il software. Esiste uno stato chiamato " Flusso " in cui uno sviluppatore è immerso nella sfida (problema), ha costruito un modello mentale della soluzione e si concentra completamente sulla costruzione della soluzione. Uno sviluppatore può lavorare fino a mezzanotte, lasciare solo per mangiare e dormire, quindi tornare a uno stato vicino a dove ha lasciato.

Gli sviluppatori devono evitare le distrazioni e molti trovano che ci sono vantaggi nel programmare a tarda notte (evitano il rumore, le telefonate, l'ufficio occupato e i colleghi non sviluppatori che interrompono il loro lavoro). E quando hai lavorato fino alle 10, alle 11 o alle 12, non è irragionevole venire a lavorare più tardi (10, 11, mezzogiorno?). È ragionevole aspettarsi che gli sviluppatori lavorino dalle 9:00 a mezzanotte?

Scrum (e qualsiasi) riunione distrae lo sviluppatore dal suo scopo principale, che è la creazione di software.

Gestione - I manager devono misurare per avere successo, da qui la necessità di pianificazioni, risultati, tempistiche, priorità e riunioni per misurare e riportare i progressi e per esporre dipendenze, ritardi e aree a rischio. La sfida con uno Scrum è che un manager ha bisogno di queste cose, ma lo sviluppatore ha bisogno di concentrazione. Le riunioni servono il gestore e forniscono al gestore un modo per ottenere, misurare e tenere traccia dello stato e dei progressi, ma le riunioni raramente forniscono utilità agli sviluppatori. Considera che i gestori forniscono più valore quando gestiscono le distrazioni, rimuovono le barriere e consentono agli sviluppatori di concentrarsi sulla costruzione di software.

Esistono soluzioni alla necessità di riunioni. Un manager può visitare i propri sviluppatori, chiedere rapporti sullo stato, adottare un protocollo per le interruzioni meno intrusive o adottare una politica che lo sviluppatore informi dell'avanzamento dello sviluppatore quando è interrompibile. Vedi la discussione del tempo sul perché questo è importante.

Personalità - Considera che alcune persone sono introverse e altre sono estroverse. Gli estroversi godono delle interazioni sociali e ne vengono ricaricati. I manager sono in genere estroversi (perché gli estroversi sono generalmente migliori con le interazioni sociali), sebbene gli introversi possano avere successo come manager. Gli introversi possono godere e persino eccellere nelle interazioni sociali, ma vengono ricaricati dalla solitudine. Gli sviluppatori sono spesso introversi e lavorano con successo da soli (o in piccoli team) perché non "hanno bisogno" di interazioni sociali; possono essere felici di lavorare da soli sui problemi (anche se gli estroversi possono essere anche sviluppatori). Le riunioni quotidiane di mischia possono diventare incontri sociali, utili per gli estroversi, ma non altrettanto per gli introversi.

Tempo : gli sviluppatori non possono scrivere codice durante le riunioni. Né possono pensare a problemi difficili (a meno che non stiano facendo brainstorming), mentre sono distratti dalle riunioni. Gli sviluppatori hanno bisogno di grandi blocchi di tempo ininterrotto per concentrarsi sulla creazione di software. Le riunioni sono interruzioni che distraggono dai loro sforzi. Quando sei stato immerso nella risoluzione di un problema per ore, hai quasi finito, e qualcuno dice "tempo per la mischia", sei interrotto e perdi forse ore di lavoro mentre "cambi marcia". Oppure sei rimasto al lavoro fino alle 23:00, hai lasciato il lavoro, sei tornato a casa, hai dormito sul problema, ti sei svegliato, sei tornato al lavoro pronto a risolvere il problema e poi sei stato interrotto dopo un'ora di lavoro su un problema, perché è "il tempo della mischia".

Paul Graham ha un eccellente articolo su Maker Time vs. Manager Time, che spiega questo problema molto meglio di me. Basti dire che un'interruzione della riunione, sia pianificata che non pianificata, può interrompere il flusso e forzare uno sviluppatore dal tempo del Maker al tempo del Manager. Credimi, vuoi che gli sviluppatori siano in tempo per Maker.

Obiettivi, priorità - Sviluppatori e manager hanno obiettivi e priorità diversi. I manager hanno l'onere di tenere traccia dei programmi, minimizzare i costi, assicurarsi che i loro report siano responsabili e che eseguano. Gli sviluppatori hanno l'obiettivo di costruire il software che affronta le sfide / i problemi. Questi obiettivi non sono in conflitto, ma è il meccanismo di comunicazione che crea la tensione. Le riunioni soddisfano le esigenze del manager e ottimizzano i tempi dei manager, ma sono in conflitto con le esigenze dello sviluppatore. Gli incontri Scrum scartano la prima regola degli incontri, "hanno un programma" e tendono a vagare di più. E le riunioni vengono utilizzate per ottimizzare la comunicazione (per il gestore), ma costano il tempo dello sviluppatore (interruzioni, perdita di flusso, ecc.).

Qual è l'obiettivo? Costruire software che soddisfi le esigenze, rapidamente e con qualità, mentre i vincoli sono (qualità, tempo, costi, processo). Scrum e altre metodologie agili riconoscono il vincolo del processo, provano a minimizzare quel fattore e hanno avuto successo perché minimizzano quel vincolo. Ma l'aggiunta di riunioni costa tempo e l'interruzione costa allo sviluppatore molto più della durata della riunione.

Modifica l'incontro per assicurarti che offra vantaggi:

1. Pianificalo in un momento che offra un po 'di praticità. Perché non possono essere trascorsi 30 minuti dall'inizio del lavoro in modo che tutti possano rivedere le e-mail e organizzare i propri pensieri per il viaggio. La brevità richiede pianificazione. L'impreparato può vagare per sempre.
2. Identificare i problemi che avrebbero potuto essere evitati se durante l'incontro fosse stato comunicato un problema. Tutti devono capire qual è il punto.
3. Fai tutto il necessario per ridurre al minimo gli input di tutti. Non è il luogo per il dibattito. Incoraggia le persone a pianificare privatamente le riunioni al di fuori della riunione quotidiana incentrata su un argomento che necessita di discussione. Regola: solo una persona parla alla volta.

Tutti i denuncianti devono assicurarsi di non contribuire al problema. Se riesci a raggiungere i tuoi obiettivi per la mischia quotidiana senza averne uno in modo meno doloroso, vorremmo ascoltarlo.