Quali sono i lati negativi dei responsabili dello sviluppo come Scrum Master?

In sostanza, hai un conflitto di interessi. Il lavoro di un manager è rispettare le scadenze. Il compito di un supervisore è di assicurare che le stime siano il più accurate possibile e di lavorare a un ritmo sostenibile. Un manager tende a volere più lavoro tirato in uno sprint, e un master di mischia tende a volere un importo che può essere realisticamente completato, indipendentemente dalle scadenze esterne. Sebbene un buon manager possa bilanciare questo conflitto, è molto più facile quando il lavoro viene diviso tra due persone. I manager di solito sono molto più adatti al ruolo del proprietario del prodotto.

Non c'è niente di sbagliato nell'agire come scrum master se nessuno nella tua squadra ha familiarità con esso, ma il tuo team vedrà dei benefici se passerai quel ruolo dopo alcuni mesi. È importante che questo ruolo sia visto come un pari. Anche i maestri di scrum non di gestione spesso devono ruotare dopo un po 'perché il team inizia a trattarli troppo come un manager.

Credo che il problema principale sia che come manager hai l'autorità di dire al team cosa fare. Un maestro di mischia non ha questa autorità al di fuori dell'applicazione dei principi di Scrum.

Che cosa significa? L'input del manager implicherà implicitamente più peso. Potresti non volerlo o volerlo, ma alla fine della giornata la carriera e lo stipendio dei membri del tuo team dipendono in qualche modo da te. E loro lo sanno. E questo altera la relazione.

Puoi ancora farlo? Ovviamente. Devi solo lavorare molto duramente per rinforzare il fatto che sei un servo-leader e il top-down non volerà.

In realtà ho visto cosa succede quando un "manager tecnico" entra troppo pesantemente nella meccanica quotidiana di un progetto, e non è carino. Nel nostro caso, il manager in questione era non il supervisore di scrum ma stava cercando di cooptare alcune di quelle decisioni; se non avessimo effettivamente avuto un mischia master separato per giocare in difesa, sarebbe stato molto più doloroso.

(Per inciso, questo non era il il mio manager, quindi mi sento abbastanza obiettivo su questo punto.)

Andrò su quello che ho visto come principale conflitto di interessi; se non pensi che qualcuno di questi si applichi alla tua situazione, allora forse puoi fare entrambe le cose. Assicurati tuttavia di ricontrollare regolarmente queste ipotesi per assicurarti di non cadere in nessuna di queste trap:

1. I responsabili tecnici sono in genere responsabili di un determinato ruolo all'interno di più team. Se è solo una squadra, è più un "vantaggio" che un "manager". Questa dilatazione della responsabilità significa meno tempo con il team e meno tempo con il progetto / prodotto e tende a condurre alla gestione dello stile "colpisci e scappa".

2. I manager tecnici hanno molti altri doveri gestionali per il business. Devono svolgere attività di coaching / formazione, revisioni delle prestazioni, interviste / assunzioni, pianificazione dell'infrastruttura / risorse a lungo termine e altro ancora. Questo può facilmente diventare un lavoro a tempo pieno da solo e significa pochissimi resti da spendere per facilitare.

3. Un programma intenso può anche imporsi al team; i manager tecnici possono aver bisogno (o vogliono) di coinvolgere i membri del team in riunioni in quello che il team ritiene essere un tempo inopportuno. Normalmente è compito del supervisore fare da padrone e cercare di eliminare le interruzioni, ma è impossibile essere obiettivi su questo quando si ha il proprio programma di cui preoccuparsi. I master Scrum raramente devono incontrarsi separatamente con i membri del team perché tutti questi incontri sono già pre-programmati (stand-up, retrospettive, ecc.)

4. I responsabili tecnici devono affrontare problemi trasversali ai progetti e il loro impulso naturale sarà cercare di standardizzare tutto - librerie, controllo del codice sorgente, algoritmi, layout, colori, qualsiasi cosa. Sebbene ciò possa effettivamente essere una buona cosa per l'azienda, alla fine non lascia nessuno a cui battersi per quello che la squadra vuole fare, e potrebbero avere ottime ragioni per voler fare qualcosa di diverso. Ciò è in contrasto con gli ideali di "miglioramento continuo" sottostanti Scrum e metodologie simili.

5. I manager che provengono da un background di esperti nel ruolo che gestiscono avranno le loro idee abbastanza forti su come il lavoro dovrebbe essere fatto e quanto tempo dovrebbe prendere. Questa non è una brutta cosa come manager , ma come scrum master significherà spesso spingere i membri del team a progettare o stimare che altrimenti non sarebbero stati d'accordo - e probabilmente conoscono più di te sul problema in questione.

6. I membri del team avranno sempre problemi a distinguere tra una richiesta e un ordine. Non ti diranno questo e potrebbero anche non realizzarlo da soli. Anche se chiarisci che stai semplicemente chiedendo e non dicendo, nelle loro menti, sei ancora il loro manager e ci sono rischi a livello di carriera nel dire "no". Questo è probabilmente il più insidioso di tutti i problemi perché non c'è niente che puoi fare a riguardo - è il loro atteggiamento e non tuo che conta.

Se sei sicuro che non cadrà mai in nessuna di queste trappole, allora fallo ... ma ripeto, assicurati di convalidare frequentemente le tue ipotesi parlando con la tua squadra (e con altri team / manager!) e assicurati che non stiano accadendo in modo sottile o inconscio che forse non te ne accorgi.

Una nota positiva, aggiungo che il fatto che tu consideri il problema abbastanza importante da porre effettivamente la domanda significa che probabilmente sei abbastanza bravo in entrambi i ruoli. Prendersi cura della squadra e non solo delle proprie ambizioni professionali probabilmente rappresenta più della metà di ciò che una buona gestione è, comunque, nei miei libri.

... ma essere bravi a entrambi non significa necessariamente che puoi essere bravo a entrambi allo stesso tempo, sempre . Fai attenzione.

Questa non è religione e le regole di Scrum non sono dogmatiche. Se c'è mai stato un caso per un ruolo di HR Manager / Srum Master combinato, ne hai fatto uno buono. Stai attento a quelle trappole che hai menzionato, ma non ci sarà mai un singolo insieme di regole che si adattino perfettamente a ogni situazione.

Se la tua squadra è a tuo agio con te che esegui entrambi i ruoli, non c'è motivo di scuotere le cose solo per adattarle alle regole di un libro.

Il problema più grande che vedo è la situazione in cui il team ha un problema correlato a te, il manager. Se sono giovani o mancano di fiducia, potrebbero avere paura di parlare durante le retrospettive. Ciò potrebbe limitare l'efficacia delle retrospettive. Molte persone hanno paura di dire "Sento che il manager è irrealistico" quando il manager è presente.

Quindi, forse ti scusi dalle retrospettive per risolvere questo problema. Ora il tuo team sta facendo retrospettive senza un supervisore, anche potenzialmente limitando l'efficacia della retrospettiva.

In entrambi i casi, stai avendo un impatto negativo sulla squadra.

Il problema principale che vedo è che stai inviando messaggi in conflitto al team sull'organizzazione del team.

Di seguito sono elencate due possibili organizzazioni di team. Entrambi possono avere successo. Sono diversi. (Non sono le uniche opzioni possibili.)

1. Il team ha un leader ufficialmente designato. Il team leader è in ultima analisi responsabile delle prestazioni complessive dei team. Il caposquadra non può prendere tutte le decisioni, ma il capo squadra ha l'ultima parola su tutte le decisioni.
2. Il team è auto-organizzato e non ha un leader ufficialmente designato. Tutti i componenti del team sono responsabili delle proprie prestazioni generali e delle squadre. Lo Scrum Master facilita il processo Scrum, ma non ha il potere di prendere decisioni unilaterali per il team.

Sembra che la tua vera struttura di squadra sia la # 1, ma usando la terminologia e diversi processi di Scrum, stai implicando che la struttura è # 2. La mia opinione è che # 1 non sia Scrum.

Di seguito sono riportati due suggerimenti su come risolvere il conflitto.

1. Continua a fare le cose come sei, ma chiarisci che sei il capo squadra e non stai seguendo Scrum al 100%. Probabilmente contribuirebbe a spiegare che mentre si vede il valore nel separare i doveri di un manager e di un supervisore, ciò non è fattibile per la società.
2. Consegnare le responsabilità dello Scrum Master, il più possibile, a qualcun altro. Anche se devi ancora mantenere alcune responsabilità come cancellare i blocchi stradali e deviare le distrazioni dal resto dell'organizzazione, sarà comunque utile avere molto dello Scrum Master svolto da un pari.

What are the negatives of Development Managers as Scrum Masters?

I gestori dello sviluppo sono assunti per:

• Risolvi i problemi di sviluppo .
• Monitora e riduci il debito tecnico.
• Fai crescere lo staff tecnico.

Il loro background e le loro competenze li predispongono a concentrarsi su problemi tecnici .

D'altra parte, i project manager / scrum master vengono assunti;

• Verifica il successo del progetto.
• Assegna lavoro e triage bug / domande alle risorse di sviluppo appropriate.
• Collaborare con il team di sviluppo per rimuovere tutti gli ostacoli che potrebbero ritardare il completamento del progetto.
• inoltrare lo stato del progetto alla gestione superiore.

• Quando un progetto o un'azienda cresce a una certa dimensione, è inefficiente e poco saggio chiedere a un responsabile dello sviluppo di eseguire entrambe le funzioni.

• Un manager di sviluppo dovrebbe essere incline a fare "immersioni profonde" in codice e / o architettura, mentre un project manager / master di scrum dovrebbe sempre preoccuparsi della vista "cose da 50.000 piedi".

• La maggior parte dei responsabili dello sviluppo ha trascorso anni a sviluppare il codice. I problemi di sviluppo sono molto familiari per loro.

  • Pertanto, sono più utili quando risolvono problemi tecnici.
• I ruoli di project manager / scrum master richiedono persone molto organizzate e molto dettagliate, ma non super-tecniche.
• Quando puoi permettere a queste persone di specializzarsi sulle cose per le quali sono brave, il business è più efficiente.
• E quando è possibile scaricare le responsabilità relative alle mischie dal piatto di un gestore dello sviluppo, può dedicare più tempo alle questioni tecniche e alla riduzione del debito tecnico.

Vorrei ascoltare gli allenatori di scrum esperti. È possibile che tu possa lavorare bene per il 99% delle volte. Tuttavia, quando arriva il temuto 1% e i ruoli in conflitto, hai la possibilità di rovinare non solo la relazione di un individuo con te, ma il benessere dell'intero team. E dopo un errore, il tuo ruolo di scrum master e manager verrebbe compromesso.

Se fossi in te, identificherei un individuo della squadra che ha il potenziale per essere il controllore di mischia e andare con lui / lei. Ho sempre considerato uno scrum master come qualcuno di cui il team si fida e che capisce il processo, il business e le cose tecniche spaventose. Se hai scelto una persona capace, un ruolo di scrum master non è (e nemmeno vicino ad essere) un lavoro a tempo pieno.