Essere un team manager e uno sviluppatore in un team Scrum

Sto gestendo un team di 6 persone che di recente si è trasferito a Scrum.

Abbiamo uno Scrum Master (uno degli sviluppatori del team) e un Product Owner.

Dato che ho un sacco di tempo libero (perché un sacco di lavoro di gestione che ero solito fare ora è svolto dallo Scrum Master e dal Product Owner), e dal momento che voglio rimanere tecnicamente rilevante, sto facendo un lavoro di sviluppo tecnico.

Faccio parte del team di sviluppo, mi impegno per alcune delle storie di ogni sprint e partecipo a tutti gli incontri come parte del team.

Pensi sia una buona idea? Può contraddire l '"auto-organizzazione" della squadra?

Leggete i pensieri in via di sviluppo di Roy Osherove sulla leadership di squadra in un mondo Agile su 5whys.com

Parla molto delle tre fasi chiave che una squadra attraversa mentre evolve da Waterfall a Scrum.

La fase di sopravvivenza (in cui si trova la maggior parte delle squadre che vedo) - in cui la squadra non ha tempo per imparare - richiede un tipo di comando più comandato e controllato per creare quel tempo di apprendimento dal nulla.

La fase di apprendimento - in cui una squadra ha il tempo di imparare e la sta usando - richiede un allenatore come un leader, con esplosioni di controllo quando le cose impiegheranno troppo tempo ad imparare nel modo più duro (scegliendo, ad esempio, nessun controllo delle fonti)

Fase di auto-organizzazione - Dove i team possono risolvere i propri problemi - richiede più di un tipo di facilitatore di leader, che non dice alla gente cosa fare, ma fornisce semplicemente vincoli e obiettivi finali. La squadra ci arriverà da sola.

Quando mi sono imbattuto nelle idee di Roy, a OpenVolcano '10 , mi sono perso completamente il motivo per cui il mio team aveva smesso di migliorare. Poi mi sono reso conto che il team era passato da Survival a Learning e non avevo cambiato il mio stile di gestione. L'ho fatto e mi ha aiutato molto.

Quindi suggerisco di capire in quale delle tre fasi ci si trova e di gestirla di conseguenza.

Inoltre, prendi una decisione ora e diventa un leader o uno sviluppatore. Non cadere nella trappola di pensare di avere tempo libero fino a quando non ti trovi nella fase di auto-organizzazione. E, se ci arrivi, renditi conto che sei un buon team leader (è difficile ) e passa a un'altra squadra invece di reintegrarti.

I commenti di pdr sono validi e sono d'accordo con loro. Ma non credo che siano universali per tutti i casi.

Il tuo stile di gestione determinerà quanto bene o se dovresti anche considerare di lavorare in due ruoli.
In qualità di team manager, detieni l'autorità sulle decisioni relative alle prestazioni e al tipo di carriera dei tuoi dipendenti. Considerata in modo errato, la disparità di potere tra te e i tuoi datori di lavoro può rovinare i tuoi tentativi di far parte del team di sviluppo.

Finché sei consapevole di quella disparità e chiaramente delineati tra i tuoi ruoli, penso che puoi essere sia un manager che uno sviluppatore. L'ho visto fare con successo diverse volte e attualmente sto lavorando a una squadra in quella stessa situazione.

Vale la pena notare che non è possibile eliminare tutti gli effetti della disparità. Ci saranno momenti in cui è necessario mordersi la lingua e trattenersi da un vivace dibattito. Ce ne saranno altri quando dovrai estrarre la carta vincente e sottolineare che la responsabilità ultima per la squadra spetta a te, quindi stai facendo un diktat.

Avrai bisogno di almeno due sviluppatori forti ed esperti nel tuo team che siano politicamente sicuri. Il loro ruolo è di tenere sotto controllo la disparità di potere e di chiamarti fuori se le cose stanno andando fuori equilibrio. Potresti cavartela con un altro forte sviluppatore, ma avere un secondo fornisce obiettività nel caso in cui voi due veniate bloccati su un problema.

Mi piace sinceramente quando il mio supervisore immediato si mantiene tecnicamente rilevante. Facilita la loro comprensione delle mie difficoltà e penso che finiremo con una squadra con prestazioni migliori.

Ho vissuto un'esperienza simile prima, guidando un team di 6 sviluppatori in un team Scrum. Oltre a ciò che pdr e GlenH7 hanno menzionato, le cose che hanno aiutato:

1. Il miglior tester del team QA è stato davvero bravo a renderci responsabili della qualità del nostro lavoro, incluso il lavoro che ho svolto. Quando ho scritto codice buggy, mi ha chiamato in un modo che sarebbe difficile per un altro sviluppatore.
2. Di solito ho fatto le demo di Sprint, soprattutto quando abbiamo avuto cattivi sprint. Dal momento che stavo dimostrando al CEO, era imbarazzante quando le cose non funzionavano. Oltre a garantire di aver compreso le funzionalità sviluppate da altri, significava anche che le mie cose dovevano essere solide come quelle di chiunque altro.
3. Lascio che gli altri prendano decisioni. La mia esperienza è diversa da quella di GlenH7, ho sempre trovato un errore estrarre la carta vincente. Invece, ho discusso le diverse conseguenze delle decisioni e ho chiarito a quale sviluppatore stava lavorando su qualcosa quali fossero le conseguenze per ciò che pensavo fosse il modo "sbagliato" di fare qualcosa. Ci sono molte ragioni per farlo, ma la più grande è che come capo squadra non hai il tempo di prendere tutte le decisioni.
4. L'uso di un prodotto come Sonar può rendere le cose come la qualità del codice più oggettive.