Un team agile maturo richiede una gestione?

Dopo un recente acceso dibattito su Scrum, mi sono reso conto che il mio problema è che penso al management come un'attività piuttosto inutile e ridondante in un team completamente agile. Credo che un team Agile maturo non abbia bisogno di alcun tipo di gestione o processo decisionale non tecnico. Ai miei occhi (apparentemente erranti) è più che ovvio che l'unico adatto e in grado di gestire un team di sviluppo maturo è il loro allenatore (che è il collega tecnicamente più competente con adeguate capacità comunicative). Non riesco a immaginare come un maestro Scrum possa contribuire a tale squadra.

Sto avendo grandi difficoltà a capire e comprendere il valore di tali cose in Scrum e nel manager come qualcuno che non è uno sviluppatore veterano ma è ben abile nel pianificare i cicli di produzione quando esiste un allenatore nel team. Che cosa vuol dire, anche? Come diavolo può una persona senza competenze di sviluppo all'avanguardia gestire un team altamente tecnico? Forse la gestione qui significa qualcos'altro?

Vedo la gestione come una totale perdita di tempo e un sottoprodotto dell'immaturità. Secondo la mia comprensione, un team maturo è completamente autogestito. Apparentemente mi sbaglio dal momento che molte persone eccezionali affermano il contrario ma non riesco a convincermi.

Stai facendo un numero di errori qui.

Il primo presuppone che uno Scrum Master sia un manager. Loro non sono. Sono fondamentalmente un amministratore-facilitatore. Assicurano che le cose accadano nel programma Scrum, ma non devono dirti come, se sei una squadra Agile adulta. Succede quasi sempre.

Ma non controllano la qualità del tuo lavoro o firmano le tue vacanze o cose del genere. Né gestiscono il prodotto o il progetto; fatto da altre persone.

L'errore più grande che stai commettendo è supporre che tu possa passare dalla situazione che hai descritto in altre domande ("Al momento gli sviluppatori sono lungi dall'essere in grado di fare pratiche di programmazione agili. Nessun test unitario, nessuna programmazione di coppia, nessun elemento della configurazione ( eh? che cos'è?) ... hai avuto l'idea. ") al" team Agile completamente maturo "durante la notte. Questo semplicemente non è possibile. Dimenticalo. Non provarci nemmeno.

Se i risultati durante la notte sono ciò che desideri, cerca approcci di gestione del progetto più strutturati. E assumere alcuni manager.

Se l'azienda vuole che tu sia Agile, ci vuole tempo, ci vuole cambiamento di cultura. E sì, all'inizio, quando sei nella fase caotica del miglioramento , richiederà una gestione. Che si tratti di un individuo o di un gruppo, qualcuno dovrà prendere alcune decisioni.

È necessario che una persona o un gruppo sia responsabile per dare un'occhiata al quadro più ampio, spiegare la situazione attuale sia agli sviluppatori che al business, e spiegare le opzioni che hai per migliorare, capire di cosa ha bisogno il business e quindi guidare le persone attraverso esso.

Passerà molto tempo prima che possiate definirvi un team Agile completamente maturo e autogestirvi. La maggior parte delle squadre non ci arriva mai.

Secondo la mia comprensione, un team maturo è completamente autogestito.

Supponiamo per un momento che tu abbia ragione. Non conosco in un modo o nell'altro, quindi non parliamone.

Il problema è che anche una squadra autogestita finisce con qualcuno con buone capacità sociali e politiche che possono rappresentare la squadra in altri dipartimenti. Qualcuno che tiene traccia di ciò che fanno tutti, quando sono in vacanza, ecc. Qualcuno che gestisce le cazzate delle risorse umane e il budget. Qualcuno che discute con i gruppi QA e PM in modo che il resto della squadra non debba farlo. Qualcuno che media gli inevitabili litigi interpersonali tra gli sviluppatori. Qualcuno per programmare riunioni e mantenere il morale alto.

Questa persona è un manager.

• Arrivi a casa un giorno e paghi l'assegno non ...
• Vuoi prendere un congedo, ma il team è troppo occupato ed è stato per un anno ...
• Tua moglie o tuo figlio è malato e ha bisogno che tu riduca a 20 ore alla settimana
  per 6 mesi.
• Il dipartimento delle finanze ha chiesto una riduzione del budget e qualcuno deve andare.
• La macchina del caffè si è rotta e nessuno può ripararla.
• Il tuo team è così bravo che non ci sono difetti da correggere e nessuna funzionalità da aggiungere, hai finito il lavoro - cosa fare adesso.
• Il cliente non pagherà per il lavoro svolto
• Il cliente desidera più lavoro di quanto tu possa ottenere ed è disposto a pagarlo.

In questa lista non vedo nulla che non mi sia successo nella mia carriera. In questo elenco non vedo nulla che richieda una risoluzione di competenze altamente tecniche. Vedo molte cose in questo elenco che richiedono competenze specifiche che, francamente, la maggior parte degli sviluppatori non ha, e bravi manager lo fanno, indipendentemente da ciò che hanno gestito in passato.

Smetti di insaccare i gestori: riconosci di avere una serie di competenze e che hanno una serie diversa. Tutte queste competenze sono necessarie in qualsiasi organizzazione. Farai il loro lavoro così come faranno il tuo. È raro avere qualcuno bravo in entrambi i lavori, è più raro avere qualcuno bravo in entrambi che può fare entrambi contemporaneamente. Ciò che accade senza una mangiatoia è che le cose lentamente si erodono in uno stato di disfunzione. Se sei fortunato, è riconosciuto abbastanza presto, viene assunto un manager, e all'improvviso i problemi scompaiono come per incanto, e ti viene lasciato andare per il lavoro per cui sei pagato, piuttosto che giocare sciocche politiche d'ufficio (parlando da esperienza qui).

Vedo la gestione come una totale perdita di tempo e un sottoprodotto dell'immaturità.

Wow. Ultimamente non hai lavorato con buoni manager, vero? (Abbiamo lavorato tutti con quelli cattivi).

Ho visto persone occasionalmente commettere l'errore di presumere che tutto ciò che non comprendono appieno sia facile.

(Gli imprenditori sono particolarmente colpevoli di questo: hai mai ricevuto specifiche di scarsa qualità E una scadenza fissata nella pietra?)

Nella maggior parte delle aziende il team di sviluppo esiste come parte di un insieme più ampio. I manager esistono come interfaccia tra il team e il resto dell'azienda. Un buon manager lavorerà quella relazione in entrambe le direzioni, assicurando che il team ottenga ciò di cui ha bisogno (requisiti, spazio per ufficio, nuovi computer, riconoscimento, bonus, ecc.) Oltre a comunicare le priorità (in continua evoluzione) che escono dall'ufficio d'angolo .

L'ufficio d'angolo esiste per molte ragioni, molte delle quali non sono rilevanti per questo post.

Ricorda che la maggior parte dei manager sta prendendo le migliori decisioni possibili con le informazioni a loro disposizione che potrebbero non essere le stesse delle informazioni a tua disposizione .

Se tu avessi un team di sviluppo pienamente maturo che faceva parte di una società pienamente maturo che aveva maturare pienamente i clienti e nulla mai cambiato, si potrebbe forse eliminare la necessità per la maggior parte la gestione. Il termine per questo è Utopia .

Buona fortuna.

ps - leggi Non definirti un programmatore - un eccellente consiglio e spiega meglio di me come il resto del mondo degli affari ci vede.

Il compito di un maestro di mischia o di un manager in generale non è quello di agire come un sovrano dittatoriale. Il compito di un manager è assicurarsi che il suo team sia pronto per il successo all'interno dell'azienda. Ciò include assumere le persone giuste, ottenere le attrezzature giuste e mantenere una visione strategica del prodotto. Un manager dovrebbe essere come un guardalinee, mantenendo i dettagli e le minuzie che non sono importanti per il successo di un team interferendo con i loro progressi.

Parte del problema è che "Scrum Master" è probabilmente il ruolo con il titolo meno accurato in tutta la storia. "Scrum Facilitator" sarebbe leggermente più accurato, ma come ha sottolineato qualcun altro in precedenza, il lavoro di SM non è quello di gestire il team ma di far scomparire i problemi in modo che il team (autogestito) possa continuare con il proprio lavoro. Sì, lo Scrum Master è anche responsabile di assicurarsi che avvenga la mischia: le attività vengono aggiornate con le ore rimanenti, gli stand-up vengono mantenuti e aggiungono valore, i burn-down vengono aggiornati e la velocità viene tracciata e così via, ma è ancora un coaching e ruolo di facilitazione, non di ruolo di gestione.

Un'altra parte del problema è che le persone negli uffici d'angolo vogliono conoscere le risposte a domande come "quando posso spedire il software?" e "quali funzionalità conterrà?" e sono abituati a poter porre un "Project Manager" a quelle domande e ottenere risposte supportate con un sacco di grafici Gantt dall'aspetto impressionante e poca o nessuna menzione di cose scomode come il cono di incertezza.

Sotto Scrum, è possibile iniziare con un elenco approssimativo delle funzionalità "volontà", "potrebbe" e "non" per una data di spedizione, ma c'è sicuramente un ruolo per qualcuno - probabilmente il mastro scrum - nel mantenere aggiornato l'ufficio d'angolo con le inevitabili modifiche di tali elenchi nel tempo. Sono tentato di pensare a quell'attività, insieme all'elaborazione del feedback risultante e alla gestione di nuove richieste di funzionalità come "gestione", sebbene una gestione diversa da quella che molti, molti Project Manager avrebbero potuto fare in passato.

Se ritieni che non sia necessaria alcuna gestione, chi eseguirà i seguenti lavori organizzativi, chi risponderà nelle seguenti situazioni?

• nuovi clienti devono essere trovati. Come vendi i tuoi prodotti? Come fai pubblicità?
• i materiali devono essere acquistati, i fornitori devono essere trovati
• devono essere condotte discussioni diplomatiche con altre società, banche o uffici governativi

Sono in una piccola squadra senza manager e funziona. Perché? Onestamente non lo so.

La mia ipotesi migliore è che dipende dal tipo di persona che sei. Alcune persone "sono" computer, quindi devono essere alimentate da un processo. Altre persone sono "programmatori" e hanno la capacità di creare il proprio mondo e la propria struttura dal nulla.

Devo creare un sistema o essere schiavizzato da un altro uomo; Non ragionerò e non confronterò: la mia attività è creare. - William Blake

EDIT in risposta al commento di glenatron:
è più di un semplice team di sviluppo. Abbiamo un CEO, un receptionist che risponde al telefono e un ragazzo IT. Comunichiamo direttamente con i clienti via e-mail, telefono o riunioni. La nostra attività principale è creare il nostro prodotto e venderlo, piuttosto che cercare contratti. Ma ci sono anche contratti.

Ci ho pensato di più e questi sono i motivi per cui penso che funzioni:
1. Creiamo principalmente il nostro prodotto piuttosto che creare quello di qualcun altro.
2. Abbiamo un'etica del lavoro coerente indipendentemente, senza supervisione.
3. Abbiamo conoscenza del dominio.
4. Fortuna. Una manciata di persone che vanno d'accordo e lavorano bene insieme.

Qualcuno ha menzionato che la società Valve non ha nemmeno una gestione. Valve crea il proprio prodotto anziché creare quello di qualcun altro. Penso che un'azienda di prodotti si presti meglio all'autogestione. Non c'è rischio di percorrere una strada diversa da quella che il cliente si aspetta perché tu sei il cliente. In una società di giochi questo è particolarmente vero. Rendi il tuo gioco divertente.

Non puoi farti divertire. Non puoi arrivare alla creazione originale di arte.