Essere un team manager e uno sviluppatore in un team Scrum

Question

Essere un team manager e uno sviluppatore in un team Scrum

#1 da (13 voti)
#2 da (3 voti)
#3 da (2 voti)

11

Sto gestendo un team di 6 persone che si è recentemente trasferito in Scrum.

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

Dato che ho molto 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 po 'di tecnica lavoro di sviluppo.

Mi comporto come parte del team di sviluppo, mi impegno in alcune delle storie in ogni sprint e partecipa a tutti gli incontri come parte del team.

Pensi che sia una buona idea? Può contraddire la "auto-organizzazione" della squadra?

management scrum

posta Igor Oks 09.08.2012 - 22:53

fonte

3 risposte

3

I commenti del 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 responsabile del team, hai autorità sulle decisioni relative alle prestazioni e al tipo di carriera per i tuoi dipendenti. Saldato erroneamente, 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 questa disparità, e chiaramente delinei i tuoi ruoli, penso che tu possa essere sia un manager che uno sviluppatore. L'ho visto fare con successo un numero di volte, e attualmente sto lavorando a una squadra nella 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 trattenere da un vivace dibattito. Ce ne saranno altri quando avrai bisogno di tirare la carta vincente e far notare che la responsabilità ultima per la squadra è con te, quindi stai facendo un diktat.

Avrai bisogno di almeno due sviluppatori forti ed esperti nella tua squadra che siano politicamente sicuri. Il loro ruolo è di tenere sotto controllo la disparità di potere e di chiamarti se le cose non vanno a buon fine. Potresti cavartela con solo un altro sviluppatore strong, ma avere un secondo ti fornisce obiettività nel caso in cui tu e te due ti sentano impantanato 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.

risposta data 10.08.2012 - 15:57

fonte

2

Ho già fatto un'esperienza simile prima, guidando un team di 6 sviluppatori in un team Scrum. Oltre a quello che pdr e GlenH7 hanno menzionato, le cose che hanno aiutato:

Il miglior tester del team addetto al controllo qualità è stato davvero bravo a renderci responsabili della qualità del nostro lavoro, compreso il lavoro svolto. Quando ho scritto il codice buggy, mi ha chiamato in un modo che sarebbe stato difficile da fare per un altro sviluppatore.
Di solito facevo le dimostrazioni sugli sprint, specialmente quando avevamo brutti sprint. Dal momento che stavo dimostrando il CEO, è stato imbarazzante quando le cose non funzionavano. Oltre a garantire che comprendessi le funzionalità sviluppate dagli altri, significava anche che le mie cose dovevano essere solide come quelle di chiunque altro.
Lascio che gli altri prendano decisioni. La mia esperienza è diversa da quella di GlenH7, ho sempre ritenuto che fosse un errore tirare la carta vincente. Invece, ho parlato delle diverse conseguenze delle decisioni, e ho chiarito a quale sviluppatore si stava lavorando su qualcosa delle conseguenze per ciò che pensavo fosse il modo "sbagliato" di fare qualcosa. Ci sono molte ragioni per farlo, ma il più grande è che, come team leader, non hai il tempo di prendere tutte le decisioni.
L'utilizzo di un prodotto come Sonar può rendere le cose come la qualità del codice più obiettiva.

risposta data 10.08.2012 - 16:15

fonte

Leggi altre domande sui tag management scrum

Vantaggi di RTOS rispetto a Bare Metal per la programmazione MCU? Programmazione desktop multipiattaforma: C ++ vs. Python [chiuso]

score 13 · Accepted Answer

Leggi le idee in via di sviluppo di Roy Osherove sulla leadership del team in un mondo Agile su 5whys.com

Parla molto delle tre fasi principali di una squadra che evolvono da Waterfall a Scrum.

Survival phase (where most teams I see are in) -- in which team has no time to learn -- requires a more command and control type of leadership to create that learning time from nothing.

Learning phase -- where a team has time to learn and is using it -- requires coach like leader, with bursts of control when things will take too long to learn the hard way (choosing no source control, for example)

Self Organization Phase -- Where teams can solve their own problems -- requires more of a facilitator type of leader, that does not tell people what to do, but simply provides constraints and end goals. The team will get there on its own.

Quando ho trovato le idee di Roy, in OpenVolcano '10 , ero a una perdita completa sul motivo per cui il mio team aveva smesso di migliorare. Poi ho capito che il team aveva attraversato da Survival a Learning e non avevo cambiato il mio stile di gestione. L'ho fatto e mi ha aiutato molto.

Quindi ti suggerisco di capire quale di queste tre fasi ti trovi e gestirla di conseguenza.

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