Dai al maestro di mischia uno sguardo strano e dici "ciao Felicia", e il giorno dopo chiami una riunione di tutta la squadra e chiedi loro che diavolo fossero tutte quelle sciocchezze.

Se questo fosse realmente accaduto, licenzierei l'idiota scrummaster in un minuto a New York. Questo scrummaster è pericoloso, poco professionale e selvaggiamente inadatto al suo lavoro. Il modo per "licenziare il tuo manager" è smettere: fondamentalmente si è limitato a rassegnare le dimissioni per l'intera squadra.

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

Ancora più importante, devi capire cosa diavolo sta succedendo. Lo stesso scrum master potrebbe dover essere chiuso 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 diversi team che hanno seguito la stessa linea di condotta, non sembra che sia stata gestita con la cura che merita. Vorrei condividere ciò che ho visto per vedere se ti aiuta a darti una strada in avanti.

Primo, Scrum incoraggia i team che si auto-organizzano. Ciò che la Scrum Guide dice specificamente sui team che si auto organizzano è questo:

Sono auto-organizzati. Nessuno (nemmeno lo Scrum Master) dice al Team di sviluppo come trasformare il Product Backlog in incrementi di funzionalità potenzialmente rilasciabili;

Questo, insieme a un buon affare sull'essere interfunzionali e ampia responsabilità, ha lo scopo di incoraggiare i membri del team a porsi domande difficili su quanto siano preparati per soddisfare qualsiasi richiesta gli arrivi. Vale sicuramente la pena di leggere la Guida Scrum: è breve.

Per quanto riguarda un manager, se hai scoperto che il tuo lavoro in passato è stato assegnando compiti e tenendo traccia degli elementi di lavoro, Scrum ti chiede di fare un passo indietro rispetto a questo. Francamente, se lo Scrum Master non ti ha parlato di questo molto prima della prima retrospettiva, potrebbe essere stato un po 'un errore da parte sua. Una dura realtà, tuttavia, è che molti team che sono abituati a un manager che organizza i loro compiti per loro non sono ben preparati per passare a questo approccio. Se ritieni che il tuo team si trovi in ​​questa situazione, ti consiglio di parlarne con lo Scrum Master. Esistono molte tecniche per rendere più semplice questa transizione. In particolare, guarderei Ladder of Leadership di David Marquet e forse anche il suo libro Turn the Ship Around . Scoprirai che in entrambi non viene licenziato alcun manager.

Infine, vediamo perché vorresti fare questa transizione se in passato hai avuto successo nella gestione delle persone. La versione breve è che avrai ancora più successo aiutandoli a imparare a gestirsi da soli. Ci sono così tante ricerche e dati su questo, è difficile persino sapere da dove iniziare, ma dirò che è un fatto abbastanza ben dimostrato che tutte le persone sono potenzialmente capaci di auto-organizzazione 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 dalla parte in attesa di dare la colpa a te se la soluzione è sbagliata.

Ho visto molti manager di successo negli ambienti Scrum. Metterei sempre in guardia una squadra dal "licenziarne" una. Anche se sei intimidatorio come dice la tua domanda e gestisci ogni compito davanti a loro, ho lavorato con molti manager del genere che sono ancora risorse straordinarie per il team. In questi team auto-organizzati, passi dal passare tutto il tuo tempo a dirigere le azioni del team per assicurarti che il percorso per il loro successo sia chiaro e che risulti sempre migliore su tutta la linea con i team che offrono di più e i manager hanno una reputazione rockstars.

Buona fortuna, spero che questo ti dia alcuni punti di vista su cui lavorare.

• Nel contesto di Scrum: cosa dice il product owner? Non è funzione dello scrum master chiedere più (o meno) risorse. Questo è qualcosa che il Product Owner deve allinearsi con gli stakeholder

• Nel contesto di Scrum: una retrospettiva riguarda il processo, il team e il progetto (non il "come mi sento per il mio capo "). Se facevi parte della squadra, avresti dovuto essere invitato. Se non facevi parte del team, la retrospettiva avrebbe dovuto occuparsi solo del tuo ruolo nel progetto.

• Gli scrum master che dicono ai manager di linea cosa fare sono assurdi almeno quanto line-manager coinvolto direttamente in mischia

Quindi il maestro di mischia ha chiaramente oltrepassato i suoi limiti. Era sua funzione mantenere la retrospettiva focalizzata sull'identificazione di problemi specifici che devono essere affrontati.

Come procedere:

• Parli al team in uno -a-una sessione e chiedi loro cosa sta succedendo. Spieghi chiaramente che lo scrum master non è una funzione di linea e che non riunisce le squadre. Chiedete anche dove, secondo loro, avreste dovuto restare fuori dalle attività quotidiane

• chiarite al team a chi dovrebbero essere indirizzati i problemi

• Si passa al prossimo in linea (se è il CIO, è il CIO - non è accettabile che non si abbia un manager per mesi), affermando che la situazione deve essere risolta immediatamente (da licenziare lo scrum master o il CIO che ha detto con lui che verrà licenziato durante il corso in corso), altrimenti mette in pericolo il progetto - a me sembra che lo scrum master non capisca i suoi doveri e limiti. Una risposta professionale al team che cercava di "licenziare" il proprio manager come parte di una retrospettiva sarebbe stata "Non è affar mio sistemare il rapporto tra te e il tuo capo, e sicuramente non è quello per cui il progetto ci paga".

Ho sottolineato al team i vantaggi dei team che si auto-organizzano e dell'empowerment del team.

Beh, hanno certamente preso quella parte per cuore.

Sembra chiaro che ti trovi in ​​una situazione molto emotiva in questo momento. Apparentemente, il tuo team ha alcuni grossi problemi con l'attuale relazione tra te e loro. Probabilmente è stato un bene che tu non fossi presente alla retrospettiva, perché di solito è questo il motivo per cui le persone sono improvvisamente disposte a parlare di ciò che le infastidisce davvero. Se sono disposti a farlo con uno Scrum Master con cui hanno lavorato solo per poche settimane, allora o si fidano già del ragazzo o sono così infastiditi che non si preoccupano davvero delle conseguenze.

Ad ogni modo; questo non è un problema nuovo che è apparso all'improvviso quando sei passato a Scrum o hai assunto una nuova persona. Questo è un problema che è rimasto invisibile per molto tempo. Si afferma spesso che lavorare Agile non crea tanto nuovi problemi, quanto rende estremamente ovvi quelli già esistenti. Questo è probabilmente il caso.

Detto questo; il tuo Scrum Master ha lasciato cadere la palla, forte. Il suo lavoro è aiutare la squadra a crescere verso l'auto-organizzazione, certo. Ma questo non è il modo giusto. Per prima cosa, non può effettivamente licenziarti, e solo dirti "questo è ciò che vuole la squadra" è completamente non costruttivo. Non sono sicuro di quello che pensa sarà il risultato di questo, ma non può essere quello che la squadra pensa che sia.

Inoltre, rimuovere le persone è la scelta più difficile che un team ( o Scrum-Master) possa fare e non dovrebbe mai essere presa alla leggera e senza parlare (ripetutamente) con loro coinvolti. Non puoi semplicemente uscire e rimuovere qualcuno che non ha idea che qualcuno abbia un problema con loro. Se non altro, lascerà tutti spaventati da morire che se perdono una retrospettiva, potrebbero improvvisamente tornare al lavoro e scoprire di essere stati scaricati dalla squadra. Creerà un'atmosfera di paura, non di fiducia. Un'atmosfera di fiducia e 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 hanno fatto sì che le persone si aprissero un po 'internamente) e non cercando una soluzione costruttiva, sembra che ricada su di te.

A questo punto, non credo che nulla di basato sull'autorità sia sarà utile. Scrum e Agile mirano a consentire alle persone di fare le proprie cose e affermare la propria autorità a questo punto probabilmente finirà per licenziare l'intero team. Il team ha già affermato che sono al punto in cui vogliono che le persone se ne vadano, quindi anche se potrebbero aver sbagliato la persona, il confronto testa a testa con loro probabilmente finirà con almeno alcune persone che se ne vanno. (E ricorda la regola più importante sulla partenza: le persone di maggior valore saranno le prime ad andarsene.)

Quindi, se vuoi davvero fare Scrum con questo team, è qui che devi accettare la loro capacità di decidere come vogliono lavorare e avere una discussione aperta su come vogliono organizzare il loro team. Non possono licenziarti, ma hanno messo in chiaro che quello che stai facendo ora non funziona per loro. Devi parlare di quale sarà il tuo ruolo in futuro, di cosa hanno bisogno da te, di cosa hai bisogno da te e di come sarà organizzato tutto questo. Tieni presente che possono decidere come lavorare, ma alla fine c'è ancora un prodotto che deve essere consegnato; saranno giudicati in base alla qualità di ciò che forniscono. E se ci sono cose organizzative di cui hai bisogno da loro, dovranno fare anche quelle cose. (Detto questo; lavora con loro sulla forma di queste cose e assicurati che siano davvero necessarie prima di applicarle).

Assicurati che in quella riunione non ti avvicini alle cose dalla tua autorità ; l'idea è di mettere tutti sullo stesso livello. Siete colleghi e individui che hanno tutti un lavoro da svolgere, tutti vogliono fare un buon lavoro e tutti devono lavorare insieme ogni giorno. Essere un autoritario di solito rende le persone antagoniste l'una verso l'altra, il che non è produttivo. Quindi cerca di essere vulnerabile qui e sii disposto ad ammettere le cose che hai fatto di sbagliato. Devi capire come andare da qui in quanto esseri umani.

Sembra che il tuo team abbia raggiunto la fase di tempesta del suo sviluppo come squadra e lo ha raggiunto difficile . Ora tocca alla squadra (e io includo te, almeno per ora) capire come procedere da lì. Essere avvertito; non tutti i team escono da questa fase e non posso promettere che questo approccio risolverà il problema. Posso garantire che non sarà peggio che licenziare o licenziare tutti, però.

E assicurati 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 ha bisogno di lavorare sulle sue capacità di comunicazione e risoluzione dei problemi.

Buona fortuna per la tua situazione. Certamente vivi in ​​tempi interessanti; sfruttali al meglio e impara ciò che puoi da questo.

(Presumo anche qui che lo Scrum Master non farà in modo che l'intero team si ribelli contro di te senza alcuni seri problemi di fondo. Se lui può e sta cercando il tuo lavoro, è un maestro manipolatore. Non appena arrivi al punto in cui pensi che sia quello che sta succedendo, devi sbarazzarti del ragazzo al più presto . Questo è probabilmente l'unico caso dove prenderei in considerazione l'idea di usare la tua autorità come persona che l'ha assunto e licenziare il ragazzo.)

Indipendentemente dal fatto che abbiano o meno il potere di licenziarti come loro manager, hai creato questa situazione imponendo una modifica a Scrum semplicemente perché lo preferisci. Non ne hai discusso con loro. Potevi essere nei tuoi diritti come manager, ma è stata comunque una cosa stupida da fare, e ovviamente ora si chiedono se vogliono più lavorare per te.

Non vedi il sarcasmo in la loro rivendicazione del potere personale e dell'auto-organizzazione come base per intraprendere un'azione del genere?

È necessario convocare una riunione domani alle 9:15 e scusarsi per aver preso una decisione così importante senza prendere in considerazione il loro contributo . Puoi quindi chiedere il loro feedback su come pensavano che sia andato il loro primo sprint e cosa avrebbe potuto essere fatto diversamente.

Se desideri introdurre un nuovo flusso di lavoro nel processo di questo team, potresti provarlo su scala ridotta, con attività specifiche come programma pilota, con pochi membri selezionati del team che hanno una mentalità aperta abbastanza per dargli una valutazione equa.

Con dipendenti autorizzati, è meglio persuadere, includere e incoraggiare che dare mandato.

Una prospettiva diversa: ti è venuto in mente che stanno semplicemente prendendo in giro il processo Scrum e il suo aspetto di "auto-organizzazione"? Francamente, non riesco a immaginare che fossero seri e si siano fatti una bella risata leggendo il tuo post. Gli sviluppatori di software (io sono uno) tendono ad essere persone piuttosto ciniche con un senso dell'umorismo secco che non tutti amano o addirittura riconoscono. Sono sicuro che ti stessero semplicemente dicendo che non gli piace Scrum.

Forse la migliore linea d'azione sarebbe provare a parlare ad alcuni di loro in modo informale di Scrum e delle ragioni per cui non gli piace.

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

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

Quindi, la domanda è: Dove ti trovi in ​​questa foto? Qual è il tuo ruolo all'interno del modello Scrum? Dato che sei stata tu la cui idea di provare Scrum era in primo luogo, hai sicuramente studiato Scrum e ci hai pensato prima di suggerire no?

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

Visto che hai apparentemente fatto un fallimento critico nella ricerca quando hai suggerito Scrum, penso che non hai organizzato un Product Owner dedicato, quindi sei esattamente nella posizione di assumere questo ruolo ora.

Questo non nega il fatto che lo Scrum Master non abbia idea di cosa stia facendo o stia cercando il tuo lavoro - le quali altre risposte spiegavano adeguatamente come procedere.

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 dell'agile?

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

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

I tuoi n + 1, n + 2 sono in ferie per diversi mesi? forse ha influenzato la tua squadra a ribellarsi. Qual è la situazione finanziaria della tua azienda? (se è brutto, i dipendenti potrebbero pensare che stai facendo un brutto lavoro e che puoi fare di meglio senza di te).

cosa fare: - organizzare un incontro con tutto il team: "scrum master mi ha detto che vuoi per licenziarmi, cosa sta succedendo? ". (è molto importante che tu affronti l'argomento a tutti poiché tutti lo sanno e se influisce sul lavoro quotidiano) .- identifica il vero problema (solo questo metodo agile o hai qualche problema con il team prima?) .- una volta che lo sai il vero problema, è necessario indagare: chi ha ragione? tu oi tuoi dipendenti? -identifica chi è il leader di questa ribellione (c'è sempre un dipendente che sfida le autorità più degli altri). Se pensi che sia fuori linea, devi intraprendere un'azione disciplinare.

Non sono sicuro di cosa significhi un "manager" nella tua azienda, ma in generale penso che significhi qualcuno che aiuta i team e ne aumenta le prestazioni. Ora:

Sono un grande sostenitore dell'agile, quindi ho assunto uno scrum master e ho detto che avremmo seguito scrum.

Suona più come "ho una grande idea", voglio che lo facciate voi. Invece di consolidare prima la squadra sulla tua idea. Penso che ogni squadra abbia il diritto di criticare la tua idea e fare buchi nella tua idea. se la tua idea non tiene, dovresti lasciarla andare.

Non è sicuro che l'idea sia valida per dire al team che desideri un periodo di prova e / o migrare lentamente alla nuova struttura del progetto.

In questo modo potresti ancora incontrare resistenza, ma probabilmente non tanto come adesso.

Penso di riassumere: Sei il loro manager, non il loro capo . quelli sono due lavori molto distintivi!

O: a) Hanno ragione e non sei riuscito a giustificare la tua esistenza. (Non riescono ancora a licenziarti) ob) Lo scrum master vuole il tuo lavoro.

Penso che la cosa migliore da fare sia andare a fare un corso di 2 giorni di scrum master e sbarazzarti del tuo scrum master . Probabilmente potrai quindi ottenere un bonus alla fine dell'anno per aver svolto due lavori.

"Il codice è più ciò che chiameresti" linee guida "che regole effettive." - Capitano Barabossa

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

Io ' abbiamo sottolineato al team i vantaggi dei team auto-organizzati e dell'empowerment del team.

Spiega ai tuoi figli che l'auto organizzazione e l'empowerment non significa che riescano a fare tutto quello che vogliono. Se la tua squadra ha deciso di andare a rubare alcune armi automatiche e rapinare una banca, non sei obbligato a seguirle solo perché sono autorizzate.

Non possono "licenziarti". Questo è il ruolo del tuo manager. Il tiro viene sempre dall'alto della catena, non dal basso. Certo, possono saltare gradini nella gerarchia e lavorare con il tuo capo per rimuoverti, ma poiché a quanto pare il tuo capo e il capo del tuo capo sono entrambi in congedo senza aver messo nessuno al suo posto in loro assenza, non c'è gran parte di una gerarchia a cui andare. Hai un paio di mesi.

Ho detto allo scrum master che mi sarebbe piaciuto parlarne con il team, ma era convinto che si sentissero "intimiditi" quando ero in la stanza e non volevo discuterne con me.

Beh, questo è un peccato per loro. Parla comunque con loro. Il potenziamento personale può darti la capacità di prendere le tue decisioni, ma non ti libera dalla responsabilità di essere all'altezza di quelle decisioni. Se avessi un team così, 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 ". Bene duro. Ha sbagliato tutto quando è andato da te per dirti che eri licenziato e non l'ha fatto in un modo sufficientemente cortese da accettarlo. Ci si aspetta che un master SCRUM abbia abilità personali migliori di quelle.

Allora che ne dici?

Per prima cosa, 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 la squadra dovrebbe essere in grado di dire direttamente la propria parte.

Secondo, considera cosa significa "licenziare". Dici di essere un manager senza mani, ma loro vogliono che te ne vada. Capisci perché. Non stanno scrivendo gli stipendi, quindi la decisione di licenziarti non è un tipo di decisione "oh non stanno facendo il loro peso". Questa è una decisione tipo "questa persona si sta attivamente intralciando". Qualcosa davvero non si somma qui. necessario che si sommino prima di prendere decisioni significative. Essendo una persona anonima su Internet, non posso dire se sei tu o loro o il master SCRUM, ma qualcosa è davvero davvero sbagliato in questo scenario, ed è meglio che tu sappia di cosa si tratta dal volta che hai finito di parlare con loro.

Lavora con loro. Sii un manager. Trova un modo per risolvere il problema. Trova un modo per poter svolgere il tuo lavoro, mentre loro fanno il loro. Realizzalo.

Ora, se le loro risposte ti forniscono una chiusura sufficiente per onorare il loro potere personale, ora devi mostrare alla squadra cosa succede quando "licenzi" la leadership in quel modo. Dì "Va bene. Smetterò di fare il tuo manager. Non puoi effettivamente licenziarmi, perché non è la tua posizione, ma se vuoi giocare a questo gioco, possiamo farlo. Ero il tuo manager, aiutandoti a isolarti dalla politica aziendale e dallo stress di riferire all'alta dirigenza. Ora, io sono la tua alta dirigenza e tu non hai più quell'isolamento. Ora poiché non posso effettivamente rimuovere me stesso da questa posizione, lo farò semplicemente iniziare a ritrasmettere il compito dall'alto. " Spiega che solo perché il team ha votato, ciò non significa che non hai obblighi nei confronti della dirigenza superiore che devi adempiere e che continuerai a farlo.

Quindi, chiedi aiuto.

Un ammutinamento non è cosa da poco. Tutta la tua squadra ti ha appena votato fuori dall'isola. Non sottovalutarlo. Fatti aiutare da qualcuno sopra di te. Forse chiami il tuo capo in licenza. Forse parli con il tuo CIO. Qualcuno deve sapere che c'è un grave problema di persone nella tua azienda, e che lo stai risolvendo. La seconda metà è chiaramente importante. Non andare mai alla leadership con problemi, ma rivolgiti a loro con soluzioni.

La soluzione che consiglierei è di creare la tua immagine come "manager che sopporta i requisiti" scegliendo le cose da richiedere quale leadership (ad esempio CIO) vorrebbe , che è creato per costruire un po 'di autorealizzazione da abbinare a questo auto-potenziamento. Potrebbero pensare di essere liberi di fare ciò che vogliono, ma sei comunque obbligato a renderli una squadra di successo. Se devi farlo da lontano, fallo da lontano. Scopri cosa è stato così intimidatorio nel tuo approccio senza mani e assicurati di non farlo mai.

L'obiettivo finale è fargli capire che sei dalla loro parte. Se sono veramente auto-potenziati, allora devono rendersi conto che sei una parte benefica della squadra. Arriveranno a quella realizzazione solo se avranno successo. Se vengono sommersi da scadenze impossibili e burocrazia senza speranza, non lo vedranno mai.

Assicurati solo che tutto sommato. 2 + 2 = 4. Un manager "senza mani" viene "licenziato" dal nuovo master SCRUM per essere troppo intimidatorio mentre due livelli di gestione sono in congedo? Qualcosa non torna da qui. Sei più vicino alla situazione. Scopri cosa non torna e risolverlo.

Non esiste un ruolo di manager in un team di mischia. La vera domanda è perché pensavi di essere un membro del team in primo luogo. Se non stai partecipando alla consegna delle funzionalità, non hai posto in quel team, quindi ciò che ha fatto il team è stato corretto.

Se ti considerano un impedimento, scopri perché: lo scenario probabile è che tu stavano interferendo e la soluzione è che tu ti fermi e lasci che facciano il loro lavoro.

Quale tu pensi che sia il tuo ruolo nel team? Trova una risposta utile che sia in linea con gli obiettivi di Scrum, quindi sottolinea al team che intendi svolgere quel lavoro e non interferire con il loro.

Quindi non vedo perché non puoi vederlo come qualcosa di positivo? Da quanto mi risulta, l'obiettivo di un team che si autogestisce è non aver bisogno di un manager .

Quello che devi fare è guardare alle opportunità che questo presenta. Fondamentalmente hai un super team che può gestirsi da solo e ora sei in grado di fare quanto segue:

• Sei in grado di ritenere il team responsabile degli impegni aziendali più facilmente. Se non riescono a raggiungere gli obiettivi aziendali, semplicemente non possono essere autogestiti
• Sei in grado di far crescere le competenze nel team. Quindi ora puoi concentrarti maggiormente sull'aspetto delle persone del team. Crescita professionale, abilitazione e quel genere di cose.
• Renditi conto che il team + scrum master sono ancora responsabili nei tuoi confronti nella gerarchia aziendale, nei budget e nel processo di valutazione delle prestazioni. Quindi non è come se potessero andare oltre la tua testa.

Quindi pensalo come un successo per ora. Pensa di più alle opportunità di come puoi rafforzare la squadra. Renditi conto anche che devi essere presente nello scenario in cui questo approccio di autogestione fallisce.

Lao Tzu ha detto

Il leader malvagio è colui che la gente disprezza,

Il buon leader è colui che la gente riverisce,

Quando un grande leader guida, le persone dicono "l'abbiamo fatto noi stessi".

Un leader è il migliore quando le persone sanno a malapena che esiste,

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

diranno: l'abbiamo fatto da soli.

e ho seguito questa massima praticamente dal primo giorno dei principali team di sviluppo. Se tutti sanno cosa fare, allora non sono necessario e il mio lavoro è servito al meglio in questo modo: godermi la vita fuori dall'ufficio.

Segui le metriche, controlli il loro codice, fai piccole correzioni di rotta, incoraggi & ad abilitare qualsiasi cosa abbia bisogno di incoraggiamento e abilitazione - comunicazione, cooperazione, test di scrittura ecc., li proteggi dai clienti di & della direzione superiore - e idealmente non agisci mai.

Ma quando lo fai, lo fai e tu prenditi il ​​naso quando è necessario, dopotutto sei il responsabile del loro lavoro: le persone vengono licenziate su tua raccomandazione e dovresti licenziarti dovresti, e in tempo.

Non sono sicuro del motivo per cui uno sviluppatore dovrebbe licenziare qualcuno che non è sulla loro strada ed è fondamentalmente lì per sistemare le cose per loro e proteggerli dai clienti e occasionalmente anche dai più alti, si prende cura della disponibilità di attrezzature, documentazione, spinge leggermente per essere programmatori migliori e migliori persone e consente loro di concentrarsi sul codice.

Sei ancora il loro h più in alto: puoi ancora spararli se necessario, non sei stato licenziato da questa posizione. Sei stato semplicemente considerato inutile o dannoso per lo sforzo di sviluppo e preferiscono giocare senza di te.

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

Io diciamo che è una straordinaria opportunità per una grande riflessione e crescita.

Qui posso vedere due punti di vista:

• Eri il manager di linea di un team di sviluppo in un'organizzazione a matrice e sei ancora il manager di linea. Il tuo lavoro potrebbe essere leggermente cambiato, ma è fondamentalmente lo stesso: fornisci giorni-uomo per sviluppatori al PO in conformità con i processi di budget / risorse umane dell'azienda, ti occupi delle assunzioni (e se necessario, licenziamento), pianifichi parte in collaborazione con il team e così via.
  Nello sviluppo agile, il tuo ruolo potrebbe essere un po 'meno pratico di quanto non fosse, ma soprattutto se ci sono più team di mischia il tuo ruolo ora includerà cose come incoraggiare "comunità di pratica" o "gilde". Come ogni cosa, la mischia può essere dannosa se portata agli estremi e qualcuno dovrebbe prendersene cura, ad es. che gli stack tecnologici rimangono compatibili a meno che non ci sia una buona ragione per fare un'eccezione. Questo è il lavoro del manager di linea in un'organizzazione di questo tipo.
• Eri un membro del team di sviluppo e hai avuto un input diretto nelle decisioni tecnologiche, nell'architettura e così via. In tal caso suggerirei che hai sbagliato a non farti coinvolgere abbastanza in questo primo sprint, perché non vedono come contribuirai con le tue capacità alla squadra. Nel prossimo sprint, lavora con il team.

Sono un manager di un team di sviluppo.

Sono un grande sostenitore dell'agile

Bene! Se per "agile" intendi "Scrum" (perché avresti assunto uno Scrum Master, altrimenti ...), allora va tutto bene.

Storicamente hanno seguito una metodologia molto a cascata e sono stati resistenti al cambiamento.

il team ha accettato collettivamente di "licenziarmi" come suo manager

Bene! Hanno cambiato i loro modi; hanno abbandonato la loro resistenza (non ci hai detto a cosa hanno resistito, prima ...). Hanno imparato i ruoli che circondano uno Scrum Team.

Come sicuramente saprai, un manager ha solo una responsabilità molto remota nel contesto di uno Scrum Team; non sei né lo Scrum Master, né il Product Owner, né uno degli Stakeholder, né parte dello Scrum Team stesso. Ricordo quando ho ottenuto il mio certificato Scrum Master in un seminario di 3 giorni; il ruolo di "manager" non era nemmeno nel grafico.

Se la tua azienda utilizza la tipica struttura a matrice della gestione della linea verticale rispetto alla gestione orizzontale correlata al progetto (o al prodotto) (ovvero il manager di linea <> project / product manager), quindi tutto sembra andare secondo i piani. Avrai ancora responsabilità manageriali, ovvero gestire tutto ciò che è al di fuori del lavoro produttivo quotidiano del tuo team.

Ripeto la tua frase chiave:

Sono un grande sostenitore dell'agile

Ora è un buon momento per abbracciarlo e imparare cosa significa gestire uno Scrum Team. Anche le tue responsabilità ora sono cambiate. Fai le solite cose (assunzione di nuovi membri, gestione dello stipendio, aiuto al tuo team per essere in grado di lavorare (procurando loro hardware / software / ecc. E un buon ambiente di lavoro), magari collaborando con altri manager Scrum). Il fatto che la tua azienda sembri riconoscere le unità organizzative non è cambiato. I membri del tuo team dovranno comunque parlare con te; solo non sul loro lavoro.

A seconda di ciò che facevi prima come lavoro quotidiano (distribuire pacchetti di lavoro a singoli sviluppatori), potresti voler esaminare altre cose che puoi fare. Ad esempio, potresti avere voce in capitolo in merito ai progetti per cui lavora il tuo (!) Team, o se un Product Owner diventa cattivo in qualche modo, potrebbe essere il tuo lavoro a calmarlo. Potresti essere responsabile della gestione dei contratti con i clienti (vendite, ecc.). Sarai un partner e uno scudo per la tua squadra in caso di escalation. Stai gestendo . Gestire non è la stessa cosa che sviluppare software; e assegnare compiti a singole persone è solo una piccola parte.

Francamente, direi che sei molto fortunato. Cavalca l'onda. Lascia che facciano le loro cose. Evita di gestire il loro nuovo Scrum; Scrum è stato creato proprio per rendere il team autosufficiente e in grado di esibirsi senza una microgestione costante dall'esterno. Molte parti di Scrum sono create per proteggere un team da gestioni indesiderate.

Il tuo lavoro potrebbe essere molto facile ora. Se tutto funziona come previsto, gestiranno molte cose che dovevi fare prima. Tutti potrebbero essere molto felici d'ora in poi, soprattutto se prima non gli piaceva la tua microgestione.

il team ha accettato collettivamente di "licenziarmi" come suo manager

Ovviamente, presumo che poiché hai citato la parola "fuoco", non hanno letteralmente inviato una mail alle risorse umane per escluderti dal libro paga, ma ti hanno detto che vogliono vivere Scrum al massimo ( e intenti). Ovviamente, presumo che in realtà non vogliano tagliare le linee sull'organigramma della tua azienda. Anche un puro Scrum Team deve ancora essere radicato da qualche parte in azienda, cioè essere parte del line management, e questo sei tu. Semplicemente non sei più coinvolto nel lavoro quotidiano.