Come posso riacquistare il controllo manageriale del mio team "auto-organizzato"?

Dai al mischiaro uno sguardo strano, e dici “ciao Felicia”, e il giorno dopo convochi una riunione di tutta la squadra e chiedi loro che diavolo era tutta quella stupidaggine.

Se questo accadesse davvero, allora licenzierei quell'idiota mischiaro in un minuto di New York. Questo mischiaro è pericoloso, non professionale e selvaggiamente inadatto al suo lavoro. Il modo per “licenziare il proprio manager” è quello di licenziarsi: in pratica ha appena rassegnato le dimissioni per tutta la squadra.

Non capisco perché sei preoccupato. Sono tutti sotto di te nella gerarchia, e non hanno il potere di licenziarti.

Più importante, devi capire cosa diavolo sta succedendo. Il maestro della mischia stesso potrebbe aver bisogno di essere licenziato a seconda della situazione.

Fallo prima che sia troppo tardi, prima che il tuo capo (o CIO) ti dica la stessa cosa.

Anche se ho lavorato con un certo numero di squadre che hanno seguito questa stessa linea d'azione, non sembra che sia stata gestita con la cura che merita. Vorrei condividere con voi quello che ho visto per vedere se vi aiuta ad andare avanti.

Innanzitutto, Scrum incoraggia le squadre che si auto-organizzano. Ciò che la Guida della Mischia dice specificamente sulle squadre auto-organizzate è questo:

Sono auto-organizzati. Nessuno (nemmeno il Maestro della Mischia) dice al team di sviluppo come trasformare il backlog del prodotto in incrementi di funzionalità potenzialmente rilasciabili;

Questo, insieme a molte altre cose sull'essere cross-funzionali e sull'ampia responsabilità, vuole incoraggiare i membri del team a porsi domande difficili su quanto sono preparati a mettere in campo qualsiasi richiesta gli venga rivolta. Vale sicuramente la pena di dare una lettura alla Scrum Guide - è breve.

Per quanto riguarda un manager, se avete scoperto che il vostro lavoro in passato è stato assegnato a compiti e tracciamento di elementi di lavoro, Scrum vi chiede di fare un passo indietro da questo. Francamente, se il Maestro della Mischia non ve ne ha parlato molto prima della prima retrospettiva, potrebbe essere stato un po’ una mancanza da parte sua. Una dura realtà, però, è che molte squadre abituate a un manager che organizza i propri compiti per loro non sono ben preparate a lanciarsi in questo approccio. Se vi sentite come se la vostra squadra si trovasse in questa situazione, vi consiglio di parlarne con lo Scrum Master. Ci sono molte tecniche per facilitare questa transizione. In particolare, guarderei la Scala della Leadership di David Marquet e forse anche il suo libro Turn the Ship Around. Troverete che in entrambi, nessun manager è licenziato.

Infine, esaminiamo il motivo per cui vorreste fare questa transizione se avete avuto successo nella gestione delle persone in passato. La versione breve è che avrete ancora più successo aiutandoli ad imparare a gestire se stessi. Ci sono così tante ricerche e dati su questo, che è difficile anche solo sapere da dove cominciare - ma dirò che è un fatto abbastanza ben dimostrato che tutte le persone sono potenzialmente in grado di auto-organizzarsi e in un team di, diciamo, dieci, undici cervelli (il tuo incluso) risolveranno sempre i problemi in modo più efficace di uno e ne avranno altri dieci in attesa di dare la colpa a te se la soluzione è sbagliata.

Ho visto un sacco di manager di successo in ambienti Scrum. Metterei sempre in guardia una squadra dal “licenziarne” uno. Anche se sei intimidatorio come dice la tua domanda e gestisci ogni compito di fronte a loro, ho lavorato con molti manager di questo tipo che sono ancora una risorsa straordinaria per il team. In questi team auto-organizzati, si passa dal dedicare tutto il proprio tempo a dirigere le azioni del team a fare in modo che la strada per il loro successo sia chiara e che il risultato sia sempre migliore in tutti i settori, con team che offrono di più e manager che hanno la reputazione di creare rockstar.

Buona fortuna, spero che questo vi dia qualche angolazione con cui lavorare.

• Nel contesto della mischia: Cosa dice il proprietario del prodotto? Non è compito del padrone della mischia chiedere più (o meno) risorse. Questo è qualcosa di cui il Product owner ha bisogno per allinearsi con gli stakeholder

• Nel contesto della mischia: Una retrospettiva riguarda il processo e il team e il progetto (non “come mi sento riguardo al mio capo”). Se facevi parte del team, avresti dovuto essere invitato. Se non facevi parte del team, la retrospettiva avrebbe dovuto riguardare solo il tuo ruolo nel progetto.

• I maestri di mischia che dicono ai manager di linea cosa fare sono assurdi almeno quanto i manager di linea che entrano direttamente in mischia

Quindi il maestro di mischia ha chiaramente oltrepassato i suoi limiti. La sua funzione è stata quella di mantenere la retrospettiva focalizzata sull'individuazione di problemi specifici da affrontare.

Come procedere:

• Parlate con il team in sessioni individuali e chiedetegli cosa sta succedendo. Spiega chiaramente che il maestro di mischia non è una funzione di linea e che non assembla le squadre. Chiedete anche dove pensano che avreste dovuto rimanere fuori dal business quotidiano

• chiarite al team a chi devono essere indirizzati i problemi

• Andate al prossimo in linea (se quello è il CIO, è il CIO - non è accettabile che non abbiate un manager per mesi), affermando che la situazione deve essere risolta immediatamente (licenziando il maestro di mischia o il CIO che gli dice che verrà licenziato sul percorso in corso), altrimenti mette in pericolo il progetto - a me sembra che il maestro di mischia non capisca i suoi doveri e i suoi limiti. Una risposta professionale al team che cerca di “licenziare” il proprio manager nell'ambito di una retrospettiva sarebbe stata: “Non è compito mio risolvere il rapporto tra te e il tuo capo, e sicuramente non è quello per cui il progetto ci paga”.

Ho sottolineato alla squadra i vantaggi dell'auto-organizzazione delle squadre e dell'empowerment della squadra.

Beh, hanno certamente preso questa parte a cuore.

Sembra chiaro che sei in una situazione molto emotiva in questo momento. A quanto pare, il suo team ha alcuni problemi importanti con l'attuale rapporto tra lei e loro. Probabilmente è stato un bene che lei non fosse alla retrospettiva, perché di solito è questo il motivo per cui le persone sono improvvisamente disposte a parlare di ciò che le preoccupa davvero. Se sono disposti a farlo intorno a uno Scrum Master con cui lavorano solo da poche settimane, allora o si fidano già di lui o sono così infastiditi che non si preoccupano delle conseguenze.

In ogni caso, questo non è un problema nuovo che è apparso all'improvviso quando sei passato a Scrum o hai assunto una nuova persona. Si tratta di un problema che non si vedeva da molto tempo. Si dice spesso che lavorare Agile non crea tanto nuovi problemi, quanto rende estremamente evidenti quelli già esistenti. Questo è probabilmente un caso di questo.

Detto questo, il vostro Scrum Master ha perso la palla, duramente. Il suo compito è quello di aiutare la squadra a crescere verso l'auto-organizzazione, certo. Ma questo non è il modo giusto. Per prima cosa, non può effettivamente licenziarti, e il solo dirti “questo è quello che la squadra vuole” è completamente non costruttivo. Non sono sicuro di quello che lui pensa che sarà il risultato di questo, ma non può benissimo essere quello che la squadra pensa che sia.

Inoltre, rimuovere le persone è la scelta più difficile che una squadra o Scrum-Master ) può fare e non dovrebbe mai essere presa alla leggera e senza parlare (ripetutamente) con le persone coinvolte. Non si può semplicemente uscire e rimuovere qualcuno che non ha idea che qualcuno ha un problema con lui. Se non altro, lascerà tutti spaventati a morte che se si perdono una retrospettiva, potrebbero improvvisamente tornare al lavoro per scoprire di essere stati cacciati dalla squadra. Creerà un'atmosfera di paura, non di fiducia. Un'atmosfera di fiducia e di apertura è ciò che vuoi quando lavori in Agile.

Quindi con il tuo Scrum Master che non riesce a lavorare in un'atmosfera aperta (almeno al di fuori del team; sembra che abbia fatto in modo che le persone si aprano un po’ troppo internamente) e che non cerchi una soluzione costruttiva, sembra che tocchi a te farlo.

A questo punto, non credo che qualcosa basato sull'autorità sarà utile. Scrum e Agile si occupano di dare alle persone il potere di fare le proprie cose, e affermare la propria autorità a questo punto probabilmente finirà con il licenziare l'intera squadra. Il team ha già dichiarato di essere al punto in cui vuole che le persone se ne vadano, quindi, anche se potrebbero aver sbagliato persona, un testa a testa con loro probabilmente finirà con l'allontanare almeno un paio di persone. (E ricordate la regola più importante sull'andarsene: le persone più valide saranno le prime ad andarsene.)

Quindi se volete davvero fare Mischia con questa squadra, questo è il punto in cui dovete accettare la loro capacità di decidere come vogliono lavorare e avere una discussione aperta su come vogliono organizzare la loro squadra. Non possono licenziarti, ma hanno fatto capire chiaramente che quello che stai facendo ora non è lavorare per loro. Dovete parlare di quale sarà il vostro ruolo in futuro, di cosa hanno bisogno da voi, di cosa avete bisogno da voi e di come tutto questo sarà organizzato. Tenete a mente che sono loro a decidere come lavorare, ma alla fine c'è ancora un prodotto che deve essere consegnato; saranno giudicati in base alla qualità di ciò che consegneranno. E se ci sono cose organizzative di cui avete bisogno da loro, dovranno fare anche queste cose. (Detto questo, lavorate con loro sulla forma di queste cose, e assicuratevi che siano veramente necessarie prima di farle rispettare).

Assicuratevi che in quella riunione, non vi avviciniate alle cose dalla vostra autorità; l'intera idea è di mettere tutti sullo stesso livello. Siete colleghi e individui che hanno tutti un lavoro da fare, tutti vogliono fare un buon lavoro e tutti devono lavorare insieme giorno per giorno. Essere un autoritario di solito rende le persone antagoniste l'una verso l'altra, il che non è produttivo. Quindi cercate di essere vulnerabili ed essere disposti ad ammettere le cose sbagliate. Dovete capire come procedere da qui come esseri umani.

Sembra che la vostra squadra abbia colpito la Storming Phase del loro sviluppo come squadra, e l'hanno colpita hard. Ora tocca alla squadra (e vi sto includendo, almeno per ora) capire come procedere da lì. Attenzione, non tutte le squadre escono da questa fase e non posso promettere che questo approccio risolverà il problema. Posso garantire che non sarà peggio che abbandonare o licenziare tutti, però.

E assicuratevi di parlare con lo Scrum Master separatamente. Non sono sicuro di cosa lo abbia spinto ad aprire con un primo messaggio così non costruttivo, ma deve lavorare sulle sue capacità di comunicazione e di risoluzione dei problemi.

Buona fortuna con il vostro situazione. Sicuramente vivete in tempi interessanti; fate del vostro meglio e imparate quello che potete da questo.

(presumo anche qui che lo Scrum Master non riuscirà a far rivoltare l'intera squadra contro di voi senza alcuni seri problemi di fondo. Se ne è capace e sta cercando di ottenere il vostro lavoro, è un maestro-manipolatore. Non appena arrivi al punto in cui pensi che questo sia ciò che sta succedendo, devi sbarazzarti di quel tipo asap. Questo è probabilmente l'unico caso in cui considererei di usare la tua autorità come la persona che l'ha assunto e licenziare il tizio).

Che abbiano o meno il potere effettivo di licenziarti come loro manager, ti sei fatto carico di questa situazione imponendoti di cambiare la mischia semplicemente perché la preferisci. Non ne hai parlato con loro. Avresti potuto essere nei tuoi diritti di manager, ma è stata comunque una cosa stupida da fare, e naturalmente ora si chiedono se vogliono lavorare ancora per te.

Non vedi il sarcasmo nella loro pretesa di auto-potenziamento e auto-organizzazione come base per intraprendere una tale azione?

Devi convocare una riunione domani alle 9:15 e scusarti per aver preso una decisione così importante senza prendere in considerazione il loro contributo. Potete poi chiedere il loro feedback su come pensavano che fosse andato il loro primo sprint e su cosa avrebbe potuto essere fatto in modo diverso.

Se volete introdurre un nuovo flusso di lavoro nel processo di questo team, potreste provarlo su scala più piccola, con compiti specifici come programma pilota, con pochi membri selezionati del team che siano di mentalità aperta abbastanza da dargli una valutazione equa.

Con i dipendenti in possesso di poteri, è meglio persuadere, includere e incoraggiare piuttosto che incaricare.

Una prospettiva diversa: ti è venuto in mente che si stanno semplicemente prendendo gioco del processo di Scrum e del suo aspetto “auto-organizzativo”? Francamente, non riesco a immaginare che facessero sul serio e si siano fatti una bella risata leggendo il tuo post. Gli sviluppatori di software (io sono uno di loro) tendono ad essere persone piuttosto ciniche con un senso dell'umorismo arido che non tutti amano o addirittura non riconoscono. Sono sicuro che vi stavano semplicemente dicendo che non gli piace Scrum.

Forse la cosa migliore sarebbe provare a parlare informalmente con alcuni di loro di Scrum e delle ragioni per cui non gli piace.

Come @Sascha ha correttamente osservato , questo non assomiglia affatto a Scrum:

• Un team di Scrum non ha un manager, risponde invece ad un Product Owner. Il Product Owner rappresenta gli interessi degli azionisti nei confronti della squadra, organizza le consegne per lo sprint all'inizio, accetta i risultati alla fine e nel frattempo chiarisce le richieste della squadra. È essenzialmente un delegato tra la squadra e l'azienda.
• Se facessi parte della squadra di Scrum, parteciperesti ad una riunione retrospettiva. Se non fai parte del team della Mischia, la riunione avrebbe dovuto essere limitata al tuo ruolo per quanto riguarda il team all'interno del modello della Mischia.

Quindi, la domanda è: Da che parte stai in questa foto? Qual è il tuo ruolo all'interno del modello di Scrum? **Da quando sei stato tu la cui idea di provare Scrum è stata in primo luogo, ** hai sicuramente fatto ricerche su Scrum e ci hai pensato prima di suggerirlo, no?**

E se non l'hai fatto, è il momento di farlo ora. La transizione più semplice per un manager se non è considerato parte del team quando si passa a Scrum è il Product Owner. Continuerai a fare la stessa cosa - ma ora il team risponde a te collettivamente piuttosto che a ogni membro individualmente, e smetti di gestirli a meno che non te lo chiedano espressamente (quest'ultimo è probabilmente una buona cosa per entrambe le parti).

Vedendo che apparentemente hai fatto un errore critico di ricerca quando hai suggerito Scrum, credo che tu non abbia organizzato un Product Owner dedicato - quindi sei esattamente nella posizione di assumere questo ruolo ora.

** Questo non nega il fatto che il Master Scrum non ha idea di quello che sta facendo, o lo sta facendo dopo il tuo lavoro** - quali altre risposte hanno coperto adeguatamente come andare avanti.

Come posso disinnescare questa situazione e ristabilire la mia autorità come loro manager, rimanendo fedele ai principi di auto-organizzazione e di responsabilizzazione del team di agile?

Da quando sei il manager di questo team? Non credo che una squadra si ribellerà contro il manager diretto per un disaccordo su un solo argomento. Il problema potrebbe essere più grave del metodo agile.

Questo è un argomento critico per un manager e devi affrontarlo, dovrebbe essere la tua priorità numero uno per le prossime settimane.

Il tuo n+1, n+2 sono in ferie per diversi mesi? forse ha influenzato il tuo team a ribellarsi. Qual è la situazione finanziaria della vostra azienda? (se è negativa, i dipendenti potrebbero pensare che state facendo un cattivo lavoro e che potete fare meglio senza di voi).

cosa fare: - organizzare un incontro con tutto il team: “il maestro di mischia mi ha detto che volete licenziarmi, cosa sta succedendo? (è molto importante che affrontiate l'argomento con tutti perché tutti lo sanno e se influisce sul lavoro quotidiano). -identificare il vero problema (solo questo metodo agile o hai qualche problema con il team prima?) -Quando si conosce il vero problema, è necessario indagare: chi ha ragione, tu o i tuoi dipendenti? -identificare chi è il leader di questa ribellione (c'è sempre un dipendente che sfida le autorità più degli altri). Se pensate che sia fuori luogo, dovete prendere provvedimenti disciplinari.

Non sono sicuro di cosa significhi un ‘manager’ nella vostra azienda, ma in generale penso che significhi qualcuno che aiuta i team ad avere bisogno e ad aumentare le loro prestazioni. Ora:

Sono un grande sostenitore dell'agilità, così ho assunto un maestro di mischia e ho detto che avremmo seguito la mischia.

Suona più come ‘ho una grande idea’ voglio che lo facciate voi ragazzi. Invece di consolidare la squadra prima della vostra idea. Penso che ogni squadra abbia il diritto di criticare la tua idea e di fare dei buchi nella tua idea. se la tua idea non regge, dovresti essere contento di lasciarla cadere.

Non è sicuro che l'idea regge possa dire alla squadra che vuoi un periodo di prova e/o migrare lentamente verso la nuova struttura del progetto.

In questo modo potresti incontrare ancora resistenza, ma probabilmente non così tanta come hai fatto ora.

Penso di riassumere: Tu sei il loro manager, non il loro capo. Sono due lavori molto particolari!

“Il codice è più quello che chiameresti "linee guida” che regole reali.“ - Capitano Barabossa

Mi sembra che lei abbia una situazione difficile e che stia cercando di mantenere alcuni ideali irragionevoli.

Ho sottolineato alla squadra i benefici dell'auto-organizzazione e dell'empowerment della squadra.

Spieghi ai suoi bambini che auto-organizzazione e empowerment non significa che possano fare tutto ciò che vogliono. Se il vostro team ha deciso di andare a rubare delle armi automatiche e a rapinare una banca, non siete obbligati a seguirli solo perché sono autorizzati.

Non possono "licenziarvi”. Questo è il ruolo del vostro manager. Il fuoco viene sempre dall'alto della catena, non dal basso. Certo, possono saltare i gradini della gerarchia e lavorare con il tuo capo per rimuoverti, ma dato che a quanto pare il tuo capo e il tuo capo dei capi sono entrambi in congedo senza aver messo qualcuno in posizione in loro assenza, non c'è molta gerarchia a cui andare. Hai qualche mese.

Ho detto al maestro di mischia che avrei voluto parlarne con la squadra, ma lui è stato categorico sul fatto che si sono sentiti “intimiditi” quando ero nella stanza, e non ha voluto discuterne con me.

Beh, è proprio un peccato per loro. Parlate comunque con loro. L'autoconsolidamento può darvi la possibilità di prendere le vostre decisioni, ma non vi libera dalla responsabilità di essere all'altezza di quelle decisioni. Se avessi un team come quello, parlare con loro sarebbe il livello di risposta più gentile che prenderei in considerazione.

Si potrebbe dire: “Oh, ma il master SCRUM dovrebbe risolvere impedimenti come questo. Tutto dovrebbe passare attraverso di lui”. Beh, è dura. Ha fatto un casino quando è venuto da lei per dirle che era stato licenziato e non è riuscito a farlo in modo sufficientemente cortese da farglielo accettare. Ci si aspetta che un master SCRUM abbia competenze migliori di così.

Allora, che ne dici?

Innanzitutto, vuoi scoprire se hanno effettivamente deciso di “licenziarti”. Hai la parola di una persona su questo, e credo che questo sia il tipo di situazione in cui il team dovrebbe essere in grado di dire direttamente la sua opinione.

Secondo, considera cosa significa “licenziare”. Dici di essere un manager, ma loro vogliono che tu te ne vada. Capisci il perché._ Non stanno scrivendo le buste paga, quindi la decisione di licenziarti non è una decisione del tipo “oh non stanno facendo la loro parte”. È una decisione del tipo “questa persona si sta mettendo in mezzo”. Qui c'è qualcosa che non quadra. Ne avete bisogno prima di prendere decisioni significative. Essendo una persona anonima su Internet, non posso dire se si tratta di te o di loro o del master SCRUM, ma qualcosa è davvero molto molto sbagliato in questo scenario, ed è meglio che tu sappia cos'è quando hai finito di parlare con loro.

Lavora con loro. Sii un manager. Trova un modo per risolvere il problema. Trovate un modo per poter fare il vostro lavoro, mentre loro fanno il loro. Fallo accadere.

Ora, se le loro risposte ti offrono una chiusura sufficiente per onorare la loro autoconsapevolezza, ora devi mostrare al team cosa succede quando “spari” la leadership in questo modo. Dite “Bene. Smetterò di agire come vostro manager. Non puoi in realtà licenziarmi, perché non è la tua posizione, ma se vuoi giocare a questo gioco, possiamo giocare. Sono stato il tuo manager, aiutandoti a isolarti dalle politiche aziendali e dallo stress di dover riferire ai dirigenti. Ora, io sono il tuo superiore, e tu non hai più quell'isolamento. Ora, dato che non posso togliermi da questa posizione, inizierò semplicemente a riferire i compiti dall'alto”. Spiegate che solo perché il team ha votato, questo non significa che non avete obblighi verso i dirigenti superiori che dovete adempiere, e continuerete a farlo.

Allora, chiedete aiuto.

Un ammutinamento non è una cosa da poco. Tutto il vostro team vi ha appena votati fuori dall'isola. Non sottovalutatelo. Trova qualcuno al di sopra di te che ti aiuti. Magari chiama il tuo capo in congedo. Magari parli con il tuo CIO. Qualcuno deve sapere che c'è un grosso problema di persone nella tua azienda e che tu lo stai risolvendo._ La seconda metà è chiaramente importante. La soluzione che raccomanderei è quella di creare la vostra immagine di “manager portatore di requisiti”, scegliendo le cose che richiedono quale leadership (cioè CIO) vorrebbe, che è stata creata per costruire un po’ di auto-realizzazione per andare con questo auto-empowerment. Possono pensare di essere liberi di fare ciò che vogliono, ma tu sei comunque obbligato a farne una squadra di successo._ Se devi farlo da lontano, fallo da lontano. L'obiettivo finale è quello di fargli capire che siete dalla loro parte. Se sono veramente autosufficienti, allora devono rendersi conto che sei una parte benefica della squadra. Lo capiranno solo se avranno successo. Se si illudono dell'impossibile scadenze e burocrazia senza speranza, non se ne accorgeranno mai.

Assicuratevi solo che tutto quadra. 2+2=4. Un manager “a mani vuote” viene “licenziato” dal nuovo master SCRUM per essere stato troppo intimidatorio mentre due livelli di management sono in congedo? Qualcosa non quadra da qui. Sei più vicino alla situazione. Scoprite cosa non quadra e risolvete il problema.

O: a) Hanno ragione e voi non avete giustificato la vostra esistenza. (Non possono ancora licenziarti) o b) Il maestro di mischia vuole il tuo lavoro.

Penso che la cosa migliore per te sia andare a fare un corso di 2 giorni di maestro di mischia e liberarti del tuo maestro di mischia. Probabilmente alla fine dell'anno potrai ottenere un bonus per aver fatto due lavori.

Non c'è nessun ruolo di manager in una squadra di mischia. La vera domanda è perché pensavi di essere un membro della squadra in primo luogo. Se non partecipi alla consegna delle caratteristiche, non hai posto in quella squadra - quindi quello che la squadra ha fatto è stato corretto.

Se ti considerano un impedimento, scopri perché - lo scenario probabile è che stavi interferendo, e la soluzione è che tu ti faccia da parte e lasci che facciano il loro lavoro.

Cosa pensi che il tuo ruolo sia nella squadra? Trovate una risposta utile che sia in linea con gli obiettivi della mischia, poi sottolineate alla squadra che intendete fare quel lavoro, e non interferite con il loro.

Quindi non capisco perché non riesci a vederlo come qualcosa di positivo? La mia comprensione è che l'obiettivo di un team autogestito è di non aver bisogno di un manager.

Quello che devi fare è guardare alle opportunità che questo offre. In pratica avete un super team in grado di gestirsi da solo e ora siete in grado di fare quanto segue:

• Siete in grado di ritenere il team responsabile degli impegni aziendali più facilmente. Se non sono in grado di raggiungere gli obiettivi aziendali, allora non possono semplicemente essere autogestiti
• Sei in grado di far crescere le competenze del team. Così ora potete concentrarvi maggiormente sull'aspetto del team relativo alle persone. Crescita di carriera, abilitazione e questo genere di cose.
• Rendetevi conto che il team + il maestro di mischia sono ancora responsabili nei vostri confronti nella gerarchia aziendale, nei budget e nel processo di valutazione delle prestazioni. Quindi non è che possano andare oltre le vostre capacità.

Pensate a questo come a un successo per ora. Pensate di più a come potete rafforzare il team. Comprendi anche che devi essere presente nello scenario in cui questo approccio autogestito fallisce.

Lao Tzu ha detto

Il leader malvagio è colui che il popolo disprezza,

Il leader buono è colui che il popolo venera,

Quando un grande leader guida, la gente dice “l'abbiamo fatto noi stessi”.

Un leader è meglio quando la gente sa a malapena che esiste,

quando il suo lavoro è finito, il suo obiettivo è stato raggiunto,

diranno: “ce l'abbiamo fatta da soli”.

ed io seguo questa massima fondamentalmente dal primo giorno dei team di sviluppo leader. Se tutti sanno cosa fare, allora non sono necessario e il mio lavoro è servito al meglio in questo modo - godendomi la vita fuori dall'ufficio.

Seguite le metriche, controllate il loro codice, fate leggere correzioni di rotta, incoraggiate & abilitate qualsiasi cosa abbia bisogno di essere incoraggiata e abilitata - comunicazione, cooperazione, test di scrittura, eccetera, li proteggete dai dirigenti e dai clienti - e idealmente non agite mai. Ma quando lo fai, lo fai e prendi a calci i nasi quando è necessario, sei tu il responsabile del loro lavoro, dopo tutto - le persone vengono licenziate su tua raccomandazione e licenziano te, e in tempo.

Non capisco perché uno sviluppatore dovrebbe licenziare qualcuno che non gli è d'intralcio e che fondamentalmente è lì per sistemare le cose per loro e proteggerli dai clienti e occasionalmente anche dai superiori, si occupa della disponibilità delle attrezzature, della documentazione, spinge sempre leggermente ad essere programmatori migliori e persone migliori e permette loro di concentrarsi sul codice.

Sei ancora il loro superiore - puoi ancora licenziarli se ne hai bisogno, non sei stato licenziato da questa posizione. Siete stati semplicemente ritenuti inutili o dannosi per lo sforzo di sviluppo e loro preferiscono giocare senza di voi.

O questo o c'è qualche grave patologia in corso con la cultura del team.

Direi che è un'opportunità straordinaria per una grande riflessione e crescita.

Qui vedo due punti di vista:

• Lei è stato il line manager di un team di sviluppo in un'organizzazione a matrice, ed è ancora il manager di linea. Il tuo lavoro potrebbe essere cambiato un po’, ma è fondamentalmente lo stesso: fornisci i giorni da uomo sviluppatore all'OP in conformità con i processi aziendali di budgeting/HR, ti occupi delle assunzioni (e se necessario, licenziamenti), pianifichi le ferie in collaborazione con il team, e così via. Nello sviluppo agile, il tuo ruolo potrebbe essere un po’ meno dado e bullone di una volta, ma soprattutto se ci sono più squadre di mischia il tuo ruolo ora includerà cose come incoraggiare “comunità di pratica” o “gilde”. Come tutto, la mischia può essere dannosa se portata agli estremi, e qualcuno dovrebbe fare attenzione, ad esempio, che gli stack tecnologici rimangano compatibili, a meno che non ci sia una buona ragione per fare un'eccezione. Questo è il lavoro della gestione della linea in una tale organizzazione.
• Lei era un membro del team di sviluppo e ha avuto un input diretto nelle decisioni tecnologiche, nell'architettura e così via. In questo caso suggerirei che hai fatto un casino non essendo stato coinvolto a sufficienza in questo primo sprint, perché non vedono come potrai contribuire con le tue capacità al team. Nel prossimo sprint, lavorate con la squadra.

Sono un manager di un team di sviluppo.

Sono un grande sostenitore di agile

Bene! Se per “agile” intendi “Scrum” (perché avresti assunto un Master di Scrum, altrimenti…), allora tutto va bene.

Hanno storicamente seguito una metodologia molto a cascata e sono stati resistenti ai cambiamenti.

il team ha accettato collettivamente di “licenziarmi” come loro manager

Good! Hanno cambiato il loro modo di fare, hanno abbandonato la loro resistenza (non ci avete detto a cosa hanno resistito, prima…). Come sicuramente saprete, un manager ha una responsabilità molto remota nel contesto di una squadra della Mischia; non siete né il Maestro della Mischia, né il Product Owner, né uno degli Stakeholder, né parte della squadra stessa. Ricordo quando ho ottenuto il mio certificato di Scrum Master in un seminario di 3 giorni; il ruolo di “manager” non era nemmeno in tabella.

Se la vostra azienda utilizza la tipica struttura a matrice della gestione della linea verticale rispetto alla gestione orizzontale del progetto (o del prodotto) (cioè il manager di linea <<> manager di progetto/prodotto), allora tutto sembra andare secondo i piani. Avrete comunque delle responsabilità manageriali, cioè la gestione di tutto ciò che è al di fuori del lavoro produttivo quotidiano del vostro team.

Lasciatemi ripetere la vostra frase chiave:

Sono un grande sostenitore dell'agile

Ora è un buon momento per abbracciarlo e per imparare cosa significa gestire un Team di Scrum. Anche le vostre responsabilità sono cambiate. Fai le solite cose (inserire nuovi membri, gestire lo stipendio, aiutare il tuo team a lavorare (procurargli l'hardware/softwar/etc. e un buon ambiente di lavoro), magari collaborando con altri manager di Scrum). Il fatto che la vostra azienda sembri riconoscere le unità organizzative non è cambiato. I membri del vostro team avranno ancora bisogno di parlare con voi, ma non del loro lavoro.

A seconda di ciò che avete fatto prima come lavoro quotidiano (distribuire pacchetti di lavoro ai singoli sviluppatori), potreste voler guardare ad altre cose che potete fare. Per esempio, potreste avere voce in capitolo su quali progetti lavora il vostro(!) team, o se un Product Owner diventa cattivo in qualche modo, potrebbe essere vostro compito calmarlo. Potreste essere responsabili della gestione dei contratti con i clienti (vendite, ecc.). Sarete un partner e uno scudo per il vostro team in caso di escalation. Tu sei gestire. Gestire non è la stessa cosa che sviluppare software; e assegnare compiti a singole persone è solo una piccola parte di questo.

Francamente, direi che siete molto fortunati. Cavalcate l'onda. Lasciate che facciano le loro cose. Evitate di gestire via la loro nuova Mischia; la Mischia è stata fatta proprio per rendere il team autosufficiente e in grado di operare senza una costante microgestione dall'esterno. Molte parti di Scrum sono fatte per proteggere una squadra da una gestione indesiderata.

Il vostro lavoro potrebbe essere molto facile ora. Se tutto funziona come previsto, gestiranno un sacco di cose che dovevate fare prima. Tutti potrebbero essere molto contenti d'ora in poi, soprattutto se prima non gli piaceva la tua microgestione.

il team ha accettato collettivamente di “licenziarmi” come loro manager

Ovviamente, presumo che, dato che hai citato la parola “licenziare”, non hanno letteralmente mandato una mail alle Risorse Umane per escluderti dal libro paga, ma ti hanno detto che vogliono vivere Scrum nella sua pienezza (e nel suo intento). Ovviamente, presumo che in realtà non vogliano tagliare le righe dell'organigramma della vostra azienda. Anche un puro Team di Scrum deve ancora essere radicato da qualche parte nell'azienda, cioè essere parte della gestione delle linee, e questo sei tu. Semplicemente non sei più coinvolto nel lavoro quotidiano.