Riunioni di gruppo efficaci

Sono un caposquadra di una squadra di 8 programmatori in una compagnia di circa 20 tecnici. Stanno lavorando su una serie di progetti, questi progetti coinvolgono anche persone di altri team che sono al di fuori del mio controllo. La mia organizzazione non sta facendo uno sviluppo agile adeguato e sono in qualche modo resistenti ai cambiamenti, ma ho tenuto riunioni di stand-up quotidiane all'interno della mia squadra e le abbiamo trovate tutte utili e tutti sono coinvolti e abbiamo finito 10-15 minuti. Ho anche incontri settimanali individuali con ogni membro del team in cui discutiamo più dettagliatamente vari argomenti generali (sia tecnici che non tecnici), oltre a vari incontri tematici ad hoc.

Ciò con cui ho lottato, tuttavia, è la mia riunione settimanale della squadra. Sta perdendo vapore e non sono stato in grado di mantenere le persone interessate.

Voglio ancora tenere un incontro più lungo, anche se deve essere quindicinale o mensile. Lo scopo era di discutere vari argomenti che non possono essere fatti durante una riunione in piedi perché richiedono più tempo. Gli aggiornamenti da me includono un riepilogo di tutti i progetti in corso su cui stanno lavorando (sia nei tempi previsti, vari ritardi, ecc.), Eventuali cambiamenti di direzione, progetti futuri, modifiche al processo di sviluppo, ecc. Tuttavia, finisce per essere una mia conferenza, e almeno 2 persone sono ovviamente state suddivise in zone e il resto è alquanto moderatamente interessato.

Ho cercato di coinvolgere maggiormente le persone facendole parlare della loro settimana, ma con 8 persone ci vuole molto tempo e (in parte perché gran parte del loro lavoro non supera molto), la maggior parte del resto del team lo fa non importa a cosa i loro collaboratori hanno lavorato in modo più dettagliato (ottengono una panoramica di alto livello durante gli stand up).

Quindi, durante questi incontri, almeno alcune persone sono molto annoiate, ed è quasi imbarazzante per me continuare a tenere queste. È un netto contrasto con le nostre energiche riunioni mattutine in piedi.

Qualche consiglio su cosa posso fare per mantenere le persone più coinvolte e più interessate? E come posso convincerli a presentare cose sul loro o avviare discussioni che coinvolgono tutti invece che essere un mio monologo?

Hai detto che le riunioni sembrano come se le stessi tenendo lezioni. Se ti sembra così, e la squadra non sembra interessata a quello che hai da dire, allora perché hai ancora l'incontro? Se stai semplicemente lanciando informazioni su di loro e non stanno attirando la loro attenzione, perché non riassumere tutto in un'e-mail settimanale invece?

Se vuoi sfruttare quell'ora che hai con l'intera squadra, potresti prendere in considerazione l'idea di organizzare una retrospettiva. Puoi presentare la retrospettiva con semplice onestà da parte tua: digli che non ritieni che gli incontri precedenti siano stati produttivi e che tu voglia provare qualcosa di diverso per aiutare tutti a beneficiare dell'ora che hanno insieme.

In retros dove lavoro, avremo tre colonne su una lavagna, di solito mettere uno smiley, meh, e faccia triste in alto, ad esempio :), :|e :(. Quindi i membri del team possono mettere alla lavagna qualsiasi cosa di cui vorrebbero parlare con l'intero gruppo.

Nella felice rubrica, puoi celebrare i successi (come congratularmi con Alice e Bob per il rilascio di un progetto su cui hanno lavorato insieme) e puoi dichiarare la vittoria con i nuovi processi che stai provando (come il nuovo bug tracker è molto meglio del vecchia).

Nella colonna meh, metti cose che non sono esattamente felici o tristi per la settimana. Forse hai acquistato le licenze per la nuova versione del tuo IDE e qualcuno non ha visto alcun vantaggio del nuovo IDE: potrebbe metterlo sul tabellone per capire se tutti gli altri ritengono che l'aggiornamento sia stato inutile o se altre persone hanno trovato modi in cui è effettivamente superiore alla versione precedente.

Nella colonna triste, metti cose che non sono andate bene per la settimana. Secondo me, identificare i punti dolenti della settimana è probabilmente il più grande vantaggio di una retrospettiva. L'intero team discute delle soluzioni a un problema reale. Sui team che lavorano tutti su una singola base di codice, ad esempio, qualcuno potrebbe dire che la classe FooBar non è sostenibile ed è stata la causa di ore di debug. Improvvisamente scopri che anche tutti gli altri membri del team hanno perso diverse ore questa settimana a FooBar, ma nessuno ha speso del tempo per ripulirlo. In tal caso, il team può decidere collettivamente che ha senso che qualcuno trascorra del tempo a riformattare quel codice la prossima settimana.

Dopo che tutti hanno scritto alla lavagna i loro argomenti proposti, mi piace approfondire brevemente ogni argomento e chiedere al suo autore una spiegazione dell'argomento di 10-30 secondi. Questa sezione della riunione è facile da deragliare, quindi dovrai stare attento a tenere le persone in argomento - ad esempio qualcuno dirà che X è stato un problema e qualcun altro inizia a parlare di una soluzione al problema; le soluzioni non dovrebbero essere discusse fino a dopo il voto. Nell'introduzione degli argomenti, è possibile trovare modi per raggruppare più argomenti strettamente correlati.

Dopo le presentazioni, ognuno ottiene tre voti che può distribuire tra gli argomenti nel modo che ritiene più opportuno. Infine, i voti vengono conteggiati e qualsiasi argomento abbia il maggior numero di voti è quello di cui la squadra discute. Per ciascun argomento, determinare se è necessario eseguire un'azione. Celebrare un successo di solito non ha un oggetto d'azione, ma il refactoring di un codice specifico può essere assegnato a una persona. Gli elementi di azione dovrebbero in genere essere completabili da una persona, ma a volte sono elementi di azione "a tutto il team", come la consapevolezza di avere buoni messaggi di commit.

La maggior parte dei retro tende a concentrarsi su argomenti nella colonna triste, e praticamente nessun retro discute tutto ciò che è scritto alla lavagna. L'incontro tende a finire ogni volta che il tempo è scaduto. Immediatamente dopo la riunione, verifica che gli elementi di azione siano assegnati a persone specifiche; farlo in qualsiasi modo abbia senso per la tua organizzazione.

Ho avuto un grande successo con le retrospettive. Sono un ottimo modo per creare coesione in una squadra e sono un ottimo modo per riflettere sulla settimana precedente e perfezionare il processo. Penso che se li provi con la tua squadra, saranno molto più coinvolti nelle tue riunioni.

Benvenuti nel mondo del middle management!

Troverai questo tipo di problema che sta accadendo MOLTO!

Hai 3 opzioni:

Big Stick Fallo o sei licenziato, non funziona mai. Non farlo

Proprietà Ottieni loro di facilitare le riunioni. Fai un passo indietro e nomina qualcun altro. Fallo ruotare come una posizione in cui una persona diversa ospita ogni volta.

Parla il non detto Da quello che hai detto, tutti sono annoiati - allora perché non chiederglielo? Sei annoiato ? / È una perdita di tempo, ecc. Perché sentiamo? Qual è il valore in questo?

Non è chiaro nella tua domanda perché vuoi farlo. Se sei l'unico che ritiene che questi siano preziosi, sei disposto a cambiare? Chiedi loro quello che vogliono. Sono persone software, il loro compito è quello di risolvere i problemi tutto il giorno - risolvi questo!

Prova a dare più valore agli sviluppatori nelle tue riunioni. Alcuni esempi potrebbero essere:

• brevi demo che mostrano nuove funzionalità sviluppate nel recente sprint. (presentato da tutti)
• una discussione appresa in cui hanno la possibilità di cambiare il modo in cui il team lavora e migliora (la discussione ha portato la mano destra nel team e tu sei lì per giustificare le tue decisioni di gestione. simile a una sessione di ventilazione 1 su 1 ma più grande)
• una lezione su un nuovo progetto open source che potrebbe essere rilevante o un linguaggio di codifica diverso come Lang o Golang funzionale o thread verdi in Python. (forse presentato da uno degli sviluppatori più giovani o sotto forma di un video online)
• una discussione condotta da un tecnico delle vendite che descrive un problema ingegneristico terribilmente difficile che il suo cliente sta cercando di risolvere. (stesso accordo con il responsabile del supporto / servizi che cerca di ridurre i costi di supporto migliorando l'usabilità del prodotto)
• una mangiatoia che rivela le varie alternative strategiche che l'azienda avrebbe potuto prendere e come avrebbe influenzato l'ingegneria, dato il panorama competitivo.
• un consulente esterno che offre sessioni di consulenza sulle tecnologie che già usi ma non al massimo (di solito nosql, cep, RDBMS, networking, sicurezza, monitoraggio ...)
• un codice attraverso il quale tutti potrebbero imparare nuovi codici o eseguire il debug o testare suggerimenti sulla produttività (da quello sviluppatore che ha una produttività 10x).
• una sessione di codifica in cui non è consentito il mouse. Scopri le scorciatoie IDE.
• parlare da parte di un commercialista in materia di 101 problemi pensionistici, investimenti
• parlare di programmazione sociale e carriera (scambio di stack, twitter, github, blog personali, LinkedIn, Meetup nella tua zona)

Può la riunione o tenerlo molto meno spesso. Scrivi le tue lezioni in un'e-mail normale e inviale a tutti.

Avere incontri solo se le persone in essi hanno effettivamente motivo di parteciparvi. Altrimenti, stai davvero sprecando il tempo della gente.

Non tenere lunghe riunioni e sfruttare il software di gestione dei progetti. Se si desidera mantenere le persone interessate, quindi condensare ed evidenziare ciò che conta e salvare il resto per registri e report di progetto. Concentrati sulle pietre miliari, le consegne, i punti salienti e gli obiettivi e, se si applica solo a 1/3 delle persone, mettilo a scaffale per un thread di discussione del progetto.

• Mantieni brevi le tue riunioni
• Sfrutta il software di gestione dei progetti
• Mantienilo personale, propositivo e connettiti con emozioni e obiettivi
• Il problema si risolve nei focus group, non nei forum
• Ricevi feedback dai tuoi colleghi

Inoltre, non lasciare che gli altri saltino nella conversazione e proseguano il loro lavoro a meno che non abbiano fissato dei punti che vogliono affrontare. Se vuoi un feedback, preparalo o mettilo a scaffale per un thread di commenti online da qualche parte dove le persone hanno il tempo di affrontarlo. Questo è uno dei problemi più fastidiosi con le riunioni; dare tempo al pavimento ai colleghi per rispetto. Tieni queste cose alla fine dopo aver affrontato tutto ciò di cui hai bisogno per attraversare.

Prendi la direttiva sull'approccio alla gestione del tuo progetto e incoraggia le buone pratiche di sviluppo dando l'esempio.