Quali sono gli aspetti negativi dei responsabili dello sviluppo come Scrum Masters?

È opinione comune che i team manager non dovrebbero essere maestri della mischia, ma faccio fatica a capire perché. Per il contesto, sono un responsabile dello sviluppo di applicazioni con 4 sviluppatori in uno Scrum Team. Vengo da uno Scrum Master e ho introdotto la mischia all'organizzazione. Ho creato la squadra da zero e ho chiarito che tutto ciò che faccio è facilitare la squadra e che prendono le decisioni. Come squadra siamo molto aperti - mi hanno persino messo a tacere per un po 'in piedi per eliminare la sensazione di "segnalazione" che stavamo iniziando a ottenere. Una mancanza di apertura è generalmente la più grande discussione contro il manager come scrum master, ma gestito bene, è facilmente superato con la giusta cultura.

Sono stato avvertito da esperti scrum coach che questa è una situazione pericolosa e ci sono rischi "se le cose vanno male". Per come la vedo io le 2 posizioni non sono in conflitto, in entrambi i ruoli ho lo stesso obiettivo per la squadra e gli individui. Scrum risolve i conflitti all'interno del team, che tradizionalmente potrebbe essere un ruolo di manager. La natura autogestita degli sprint toglie l'assegnazione del lavoro che un manager farebbe tradizionalmente.

Tutto quello che vedo davvero a sinistra da prendere come manager di sviluppo è assicurarsi che le esigenze individuali siano soddisfatte, gli obiettivi di carriera, il posto di lavoro ecc. Ho un incontro settimanale con ciascun membro del team per sollevare eventuali problemi e gestire eventuali attività amministrative. Gran parte di questo riguarda direttamente la squadra, o il mio ruolo di scrum master comunque.

Capisco nelle grandi organizzazioni come ciò possa essere ingestibile e un ruolo separato, ma per una piccola organizzazione non potremmo certamente giustificare un altro Scrum Master o Responsabile dello sviluppo.

Per favore, mi illumini sulle insidie ​​dei gestori dello sviluppo come Scrum Masters, esclusi i punti che ho sollevato sopra e che ho già superato.

In sostanza, hai un conflitto di interessi. Il compito di un manager è rispettare le scadenze. Il compito di uno scrum master è garantire che le stime siano il più accurate possibile e lavorare a un ritmo sostenibile. Un manager tende a volere più lavoro in uno sprint, e uno scrum master tende a desiderare un importo che può essere realisticamente finito, indipendentemente dalle scadenze esterne. Anche se un buon manager può bilanciare quel conflitto, è molto più facile quando il lavoro è diviso tra due persone. I gestori di solito sono molto più adatti al ruolo di proprietario del prodotto.

Non c'è niente di sbagliato nel recitare come scrum master se nessuno nella tua squadra ne ha familiarità, ma la tua squadra vedrà dei benefici se lasci quel ruolo dopo pochi mesi. È importante che quel ruolo sia visto come un pari. Anche i maestri di mischia non gestionali 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 alla squadra cosa fare. Un mastro scrum non ha questa autorità al di fuori del rispetto dei principi di Scrum.

Cosa significa questo? L'input del manager avrà implicitamente un peso maggiore. Potresti non volerlo, o volerlo, ma alla fine della giornata, la carriera e la busta paga dei membri del tuo team dipendono in qualche modo da te. E loro lo sanno. E questo indebolisce la relazione.

Puoi ancora farlo? Ovviamente. Hai solo bisogno di lavorare molto duramente per rinforzare che sei un servo-leader e dall'alto in basso non volerà.

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

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

Esaminerò quelli che ho visto come i principali conflitti di interesse; se non pensi che qualcuno di questi si applichi alla tua situazione, allora forse puoi fare entrambe le cose. Ma assicurati di ricontrollare queste assunzioni su base regolare per assicurarti di non cadere in nessuna di queste trappole:

1. I responsabili tecnici sono in genere responsabili di un determinato ruolo all'interno di più team. Se è solo una squadra, allora è più un "lead" che un "manager". Questa ripartizione delle responsabilità significa meno tempo con il team e meno tempo con il progetto / prodotto e tende a condurre a una gestione dello stile "hit and run".

2. I responsabili tecnici hanno molti altri compiti manageriali nei confronti dell'azienda. Devono fare coaching / formazione, revisioni delle prestazioni, interviste / assunzioni, pianificazione di infrastrutture / risorse a lungo termine e altro ancora. Questo può facilmente diventare un lavoro a tempo pieno da solo e significa molto poco da spendere per facilitare.

3. Un programma intenso può anche imporsi nella squadra; i manager tecnici potrebbero aver bisogno (o desiderare) di attirare i membri del team nelle riunioni in quello che il team ritiene essere un momento inopportuno. Normalmente è compito del mastro scrum gestire e cercare di eliminare le interruzioni, ma è impossibile esserne obiettivi quando si ha il proprio programma di cui preoccuparsi. Gli Scrum Master raramente devono incontrarsi separatamente con i membri del team perché tutte queste riunioni sono già programmate (stand-up, retrospettive, ecc.)

4. I manager tecnici devono affrontare le preoccupazioni trasversali del progetto e il loro naturale impulso sarà quello di provare a standardizzare tutto: librerie, controllo del codice sorgente, algoritmi, layout, colori, qualunque cosa. Mentre questo può effettivamente essere una buona cosa per l'azienda, alla fine non lascia nessuno ad andare a battere 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" alla base di 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 svolto e quanto tempo dovrebbe impiegare. Questa non è una brutta cosa come manager , ma come scrum master spesso significa distorcere i membri del team in progetti o stime che altrimenti non avrebbero concordato - 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 te lo diranno e potrebbero anche non realizzarlo da soli. Anche se chiarisci che stai semplicemente chiedendo e non dicendo, nella loro mente, 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 tu possa fare al riguardo - è il loro atteggiamento e non il tuo che conta.

Se sei sicuro di non cadere mai in nessuna di queste trappole, allora provaci ... ma ripeto, assicurati di convalidare frequentemente le tue ipotesi parlando con il tuo team (e altri team / manager!) e assicurati che non stiano accadendo in modo sottile o inconscio che forse non noti.

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

... ma essere bravi in ​​entrambi non significa necessariamente che puoi essere bravo in entrambi allo stesso tempo, sempre . Stai attento.

Questa non è religione e le regole di Scrum non sono dogmatiche. Se c'è mai stato un caso per un ruolo di Manager Risorse umane / Srum Master combinato, ne hai fatto uno buono. Fai attenzione alle insidie ​​che hai citato, ma non ci sarà mai un unico insieme di regole che si adatta perfettamente a ogni situazione.

Se la tua squadra si sente a tuo agio nel recitare entrambi i ruoli, non c'è motivo di scuotere le cose solo per adattarsi alle regole di un libro.

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

Quindi, forse ti scusi dalle retrospettive per risolvere questo problema. Ora il tuo team sta facendo retrospettive senza un mischia, limitando potenzialmente anche 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 riportate due possibili organizzazioni di team. Entrambi possono avere successo. Sono diversi. (Non sono le uniche opzioni possibili.)

1. La squadra ha un leader designato ufficialmente. Il capo squadra è in ultima analisi responsabile delle prestazioni complessive delle squadre. Il caposquadra potrebbe non prendere tutte le decisioni, ma il caposquadra ha l'ultima parola su tutte le decisioni.
2. Il team è auto-organizzato e non ha un leader designato ufficialmente. Tutti i membri del team sono responsabili della propria performance complessiva e del team. Scrum Master facilita il processo Scrum, ma non è autorizzato a prendere decisioni unilaterali per il team.

Sembra che la struttura della tua vera squadra sia la numero 1, ma usando la terminologia e diversi processi di Scrum, stai sottintendendo che la struttura è la numero 2. La mia opinione è che # 1 non è 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 aiuterebbe a spiegare che mentre vedi il valore nel separare i doveri di un manager e di una scrum master, ciò non è fattibile per l'azienda.
2. Consegnare le responsabilità di Scrum Master, per quanto è possibile, a qualcun altro. Anche se devi ancora mantenere alcune responsabilità come eliminare i blocchi stradali e deviare le distrazioni dal resto dell'organizzazione, ti aiuterà comunque a far svolgere gran parte del lavoro di Scrum Master da un pari.

Quali sono gli aspetti negativi dei responsabili dello sviluppo come Scrum Masters?

I responsabili dello sviluppo sono assunti per:

• Risolvi i problemi di sviluppo .
• Monitorare e ridurre il debito tecnico.
• Crescere lo staff tecnico.

Il loro background e competenza li predispongono a concentrarsi su questioni tecniche .

D'altro canto, vengono assunti i project manager / scrum master;

• Garantire il successo del progetto.
• Assegnare lavoro e valutare 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.
• Inoltra lo stato del progetto alla direzione superiore.

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

• Un responsabile dello sviluppo dovrebbe essere incline a fare "immersioni profonde" nel codice e / o nell'architettura, mentre un responsabile di progetto / responsabile della mischia dovrebbe sempre preoccuparsi della visione "50.000 piedi" delle cose.

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

  • Pertanto, sono più utili quando risolvono problemi tecnici.
• I ruoli di responsabile di progetto / scrum master richiedono persone molto organizzate e orientate al dettaglio, ma non super-tecniche.
• Quando puoi permetterti di permettere a queste persone di specializzarsi sulle cose in cui sono bravi, l'azienda è più efficiente.
• E quando è possibile scaricare le responsabilità relative alla mischia dalla piastra di una mangiatoia, può dedicare più tempo alle questioni tecniche e alla riduzione del debito tecnico.

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

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