Riunioni di team efficaci

Hai detto che le riunioni sembrano come se le stessero tenendo lezioni. Se ti sembra così, e il team non sembra interessato a ciò che hai da dire, allora perché avere ancora l'incontro? Se stai solo lanciando informazioni su di loro, e non sta attirando la loro attenzione, perché non riassumere tutto in una email settimanale invece?

Se vuoi sfruttare quell'ora che hai con tutta la squadra, potresti prendere in considerazione l'idea di eseguire una retrospettiva. Puoi presentare la retrospettiva con onestà semplice da parte tua: dì loro che non ritieni che le precedenti riunioni siano state produttive e che vuoi provare qualcosa di diverso per aiutare tutti a beneficiare dell'ora che hanno insieme.

Nelle retros dove lavoro, avremo tre colonne su una lavagna, in genere posizionando una faccina sorridente, meh e triste in alto, ad es. :) , :| e :( . Poi i membri del team metteranno qualsiasi cosa sulla lavagna che vorrebbero parlare con l'intero gruppo.

Nella colonna happy, puoi festeggiare successi (come congratularmi con Alice e Bob per l'uscita di un progetto su cui hanno lavorato insieme) e puoi dichiarare la vittoria con nuovi processi che stai provando (come il nuovo bug tracker è molto meglio di quello vecchio).

Nella colonna Meh, metti le 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 - potrebbero metterlo alla lavagna per capire se tutti gli altri ritengono che l'aggiornamento sia privo di valore o se altre persone abbiano trovato modi in cui è effettivamente superiore alla versione precedente.

Nella triste colonna, metti le cose che non sono andate bene per la settimana. Identificare i punti deboli per la settimana è probabilmente il più grande vantaggio di una retrospettiva a mio parere. L'intero team deve discutere delle soluzioni a un problema reale. Sui team che lavorano tutti su un singolo codebase, ad esempio, qualcuno potrebbe dire che la classe FooBar non è mantenibile ed è stata la causa di ore di debug. All'improvviso scopri che tutti gli altri membri del team hanno perso più ore questa settimana a FooBar, ma nessuno ha dedicato del tempo a ripulirlo. In tal caso, la squadra potrebbe decidere collettivamente che è logico che qualcuno passi del tempo a rifare il codice la prossima settimana.

Dopo che tutti hanno scritto gli argomenti proposti alla lavagna, mi piace esaminare brevemente ogni argomento e chiedere al suo autore di dare una spiegazione di 10-30 secondi sull'argomento. Questa sezione della riunione è facile da far deragliare, quindi dovrai stare attento a tenere le persone in argomento - ad es. 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 aver votato. Nell'introdurre gli argomenti, puoi trovare modi per raggruppare più argomenti strettamente correlati.

Dopo le presentazioni, ognuno ottiene tre voti che possono distribuire tra gli argomenti come meglio ritengono opportuno. Infine, i voti sono conteggiati e qualsiasi argomento abbia il maggior numero di voti è ciò che il team discute. Per ogni argomento, determinare se è necessario intraprendere un'azione. La celebrazione di un successo di solito non ha un elemento di azione, ma il codice specifico di refactoring può essere assegnato a una persona. Gli elementi di azione dovrebbero essere in genere completabili da una sola persona, ma a volte sono elementi di azione "a squadra intera" come essere consapevoli di avere buoni messaggi di commit.

La maggior parte delle retrospie tende a concentrarsi su argomenti nella colonna triste, e praticamente nessun ritroso discute di tutto ciò che è scritto alla lavagna. L'incontro tende a finire quando il tempo è scaduto. Immediatamente dopo la riunione, verifica che le azioni siano assegnate a persone specifiche; fai questo in qualsiasi modo abbia senso per la tua organizzazione.

Ho avuto un grande successo con le retrospettive. Sono un ottimo modo per costruire la coesione in una squadra, e sono un ottimo modo per riflettere sulla settimana precedente e per perfezionare il tuo processo. Penso che se ci provi con la tua squadra, saranno molto più impegnati per i tuoi incontri.

Benvenuti nel mondo del middle management!

Troverai questo tipo di problema che si verificherà molto!

Hai 3 opzioni:

Big Stick Fai questo o sei licenziato - non funziona mai. Non farlo.

Proprietà Prendili per facilitare gli incontri. Fai un passo indietro e nomina qualcun altro. Fallo come una posizione di rotazione dove ogni volta una persona diversa ospita.

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

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

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

• brevi demo che mostrano le nuove funzionalità sviluppate nel recente sprint. (presentato da tutti)
• una discussione appresa in lezioni in cui hanno la possibilità di cambiare il modo in cui la squadra lavora e migliora (la discussione ha portato la mano destra nel team e sei lì per giustificare le tue decisioni di gestione. 1 sessione di ventilazione ma più grande)
• una lezione su un nuovo progetto open source che potrebbe essere rilevante o un linguaggio di programmazione diverso come Lang funzionale o Golang o thread verdi in python. (forse presentato da uno dei più giovani sviluppatori, o sotto forma di un video online)
• una discussione condotta da un ingegnere delle vendite che descrive un problema ingegneristico terribilmente difficile che il suo cliente sta tentando di risolvere. (lo stesso accordo con il manager di 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 influito sull'ingegneria dato il panorama competitivo.
• un consulente esterno che offre sessioni di consulenza su tecnologie già utilizzate ma non al massimo (di solito nosql, cep, RDBMS, networking, sicurezza, monitoraggio ...)
• un codice in cui tutti possono apprendere nuove codifiche o debug o test di produttività (da parte di uno sviluppatore con produttività 10 volte).
• una sessione di codifica in cui non è consentito il mouse. Scopri le scorciatoie IDE thingy.
• parlare con un contabile su soldi 101 relativi a pensioni, investimenti
• parla di programmazione sociale e carriera (scambio di stack, twitter, github, blog personali, LinkedIn, meetups nella tua zona)

Può l'incontro o tenerlo molto meno spesso. Scrivi le tue lezioni in una normale email e spediscila a tutti.

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

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

• Mantieni brevi le riunioni
• Sfrutta il software di gestione dei progetti
• Mantieni personale, propositivo e connettiti con emozioni e obiettivi
• Risoluzione dei problemi 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 impostato i punti che vogliono indirizzare. Se vuoi un feedback, preparalo o conservalo per un thread di commento da qualche parte online 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. Mantieni quella roba alla fine dopo aver risolto tutto ciò che devi attraversare.

Adotta una direttiva sull'approccio alla gestione dei progetti e incoraggia le buone pratiche di sviluppo conducendo attraverso l'esempio.