Smetti di perdere tempo!

Il punto principale che voglio fare è che più persone hai in una riunione, più tempo perdi. Ogni volta che stai discutendo di qualcosa che non riguarda direttamente il dipendente X, stai sprecando il tempo X del dipendente.

Perché questa è una brutta cosa? Ovviamente c'è un costo diretto (supponendo che tu paghi il dipendente X per il suo / a suo tempo!) Ma ce n'è anche uno indiretto - stai demoralizzando l'impiegato X. Ogni volta che lui / lei sta scontando una scadenza ristretta, o dovendo fare gli straordinari , penseranno al tempo sprecato trascorso in quell'incontro quando avrebbero potuto ottenere qualcosa.

Quindi, mantieni le tue riunioni il più piccole possibile. Lo fai organizzando le persone in squadre. Pensa a una squadra come all'insieme di persone che hanno bisogno di essere coinvolte per implementare un'attività. Potrebbe trattarsi di persone specifiche o potrebbe essere "due sviluppatori e un progettista UX". Una persona può trovarsi in più di una squadra e potrebbe essere necessario creare squadre diverse per ogni funzione.

Se 2 squadre devono lavorare insieme - ad es. la squadra A non può iniziare il proprio lungometraggio finché la squadra B non termina il proprio. In questo caso cerca di ottenere uno o due rappresentanti di ogni squadra coinvolta invece di coinvolgere tutta la squadra.

Decidere le priorità

In definitiva il prodotto è in fase di sviluppo per un cliente (o clienti), ed è il cliente che decide quali caratteristiche sono più importanti. I tuoi operatori di marketing sono quelli che trattano con i clienti, quindi è compito loro scoprire quali sono le funzionalità che i clienti desiderano / vogliono successivamente e assegnare priorità a tali funzioni.

Per decidere come assegnare le priorità alle funzionalità, i professionisti del marketing devono definire i requisiti, che possono quindi utilizzare per avere un'idea di quanto tempo di sviluppo / progettazione sarà necessario per ciascuno di essi. Questo è uno di quegli incontri in cui ottieni rappresentanti di ogni squadra insieme.

I tuoi sviluppatori / progettisti potrebbero aver bisogno di discutere con i rispettivi team per ottenere una stima decente, quindi concediti uno spazio per la pianificazione. Suggerirei di rendere questi incontri abbastanza frequenti, sia come e quando le nuove funzionalità sono pensate, sia su base settimanale / bisettimanale.

L'altra cosa importante da considerare è che alcune funzionalità dipendono da altre funzionalità. Se la caratteristica A è un prerequisito per la funzione B, allora la caratteristica A deve venire prima della caratteristica B nell'elenco delle priorità.

Un altro punto qui è che le correzioni dei bug dovrebbero essere trattate come caratteristiche qui. Spetta al cliente decidere se la cosa nuova caratteristica A è più importante di correggere quel bug esagerato con la funzione esistente B! Questo dovrebbe anche semplificare la pianificazione.

Pianificazione del prossimo milestone

Con il tuo elenco di funzionalità prioritarie (con stime temporali) questa parte dovrebbe essere piuttosto semplice. Fondamentalmente, prendi la prossima funzione raggiungibile * in cima all'elenco finché non avrai riempito il tempo delle persone!

Se trovi che non puoi fare l'elemento in cima alla lista perché una persona / squadra ha già una pianificazione completa, lasciala per il prossimo traguardo e trova la prossima funzione realizzabile.

Chiedi a tutti di darti una copia dei loro programmi e dovresti avere tutte le informazioni di cui hai bisogno per fare la milestone di pianificazione da sola. Ricordati di lasciare un po 'di tempo per affrontare l'imprevisto!

Ulteriori letture / dove andare da qui

Ho appena sfiorato la superficie qui. Vi consiglio caldamente di dedicare un po 'di tempo a leggere su diverse metodologie di sviluppo e di elaborare ciò che meglio si addice alla situazione della vostra squadra. Lo sviluppo agile è il "in cosa" (ci sono vari tipi, ad esempio Scrum e Kanban sono popolari), ma potrebbe non essere la soluzione migliore per il tuo team.

L'ultimo punto che vorrei fare è non cambiare le cose troppo velocemente!

Ti consiglierei di dividere la tua squadra di 10 e farne uscire due o tre.

Pensa divide e conquista. Gli incontri con 10 persone tendono a non essere ottimamente produttivi, ma funzionano meglio con 3-5 persone.

Gli incontri di sviluppo (come li chiami tu) potrebbero non aver bisogno di tutte le persone e probabilmente non sono il modo giusto per assicurarsi che tutti sappiano cosa fare per il prossimo traguardo. Queste riunioni di sviluppo dovrebbero essere dove viene presa la decisione su cosa fare, dopo una lunga discussione.

Dopo che gli incontri con ogni squadra sono terminati, dovresti avere (per ogni squadra) un elenco di compiti che dovrebbero essere svolti all'interno dello sprint. Forse è meglio condividerli. Puoi persino realizzare una lavagna o una lavagna kanban che tutti possono vedere.

Pensando a questo, tuttavia, mi sembra che il problema di base che si sta avendo è con la struttura organizzativa, con come strutturare un team di 10, e non necessariamente con Scrum o sprint.