Ser gerente de equipe e desenvolvedor de uma equipe Scrum

Estou gerenciando uma equipe de 6 pessoas que recentemente se mudaram para o Scrum.

Temos um Scrum Master (um dos desenvolvedores da equipe) e um Product Owner.

Como tenho muito tempo livre (porque muito trabalho de gerenciamento que eu costumava fazer agora é feito pelo Scrum Master e pelo Product Owner), e como quero permanecer tecnicamente relevante, estou fazendo algum trabalho de desenvolvimento técnico.

Atuo como parte da equipe de desenvolvimento, comprometo-me com algumas das histórias em cada sprint e participo de todas as reuniões como parte da equipe.

Você acha que é uma boa ideia? Pode contradizer a "auto-organização" da equipe?

Leia os pensamentos em desenvolvimento de Roy Osherove sobre liderança de equipe em um mundo ágil no 5whys.com

Ele fala muito sobre três estágios principais pelos quais uma equipe passa à medida que evolui de Waterfall para Scrum.

A fase de sobrevivência (na qual a maioria das equipes que eu vejo) - na qual a equipe não tem tempo para aprender - exige um tipo de liderança mais comando e controle para criar esse tempo de aprendizado do nada.

Fase de aprendizado - em que uma equipe tem tempo para aprender e o está usando - requer um treinador como líder, com explosões de controle quando as coisas levarem muito tempo para aprender da maneira mais difícil (escolhendo nenhum controle de origem, por exemplo)

Fase de auto-organização - onde as equipes podem resolver seus próprios problemas - requer mais um tipo de líder facilitador, que não diz às pessoas o que fazer, mas simplesmente fornece restrições e objetivos finais. A equipe chegará lá por conta própria.

Quando me deparei com as idéias de Roy, no OpenVolcano '10 , fiquei completamente perplexo com o motivo de minha equipe ter parado de melhorar. Então percebi que a equipe havia passado da Survival para a Learning e eu não havia mudado meu estilo de gerenciamento. Eu fiz isso e isso ajudou muito.

Então, sugiro descobrir em qual dessas três fases você está e gerenciar adequadamente.

Além disso, tome uma decisão agora e seja um líder ou desenvolvedor. Não caia na armadilha de pensar que você tem tempo livre até entrar na fase de auto-organização. E, se você chegar lá, perceba que é um bom líder de equipe (é difícil ) e passe para outra equipe em vez de se reintegrar.

Os comentários do pdr são válidos e eu concordo com eles. Mas não acredito que sejam universais para todos os casos.

Seu estilo de gerenciamento determinará quão bem ou se você deve considerar trabalhar em duas funções.
Como gerente de equipe, você tem autoridade sobre as decisões de desempenho e tipo de carreira para seus funcionários. Manejada incorretamente, a disparidade de poder entre você e seus empregadores pode arruinar suas tentativas de fazer parte da equipe de desenvolvimento.

Desde que você esteja ciente dessa disparidade e defina claramente suas funções, acho que você pode ser um gerente e um desenvolvedor. Eu já vi isso feito com sucesso várias vezes e atualmente estou trabalhando em uma equipe nessa mesma situação.

Vale a pena notar que você não pode eliminar todos os efeitos da disparidade. Haverá momentos em que você precisará morder a língua e evitar um debate animado. Haverá outros quando você precisar puxar o trunfo e apontar que a responsabilidade final pela equipe está com você, então você está criando um diktat.

Você precisará de pelo menos dois desenvolvedores fortes e experientes em sua equipe que sejam politicamente seguros. O papel deles é manter a disparidade de poder sob controle e alertá-lo se as coisas estiverem desequilibradas. Você poderia conviver com apenas outro desenvolvedor forte, mas ter um segundo fornece objetividade, caso vocês dois fiquem travados em um problema.

Sinceramente, gosto quando meu supervisor imediato se mantém tecnicamente relevante. Isso facilita a compreensão das minhas dificuldades, e acho que terminamos com uma equipe com melhor desempenho.

Passei por uma experiência semelhante antes, liderando uma equipe de 6 desenvolvedores em uma equipe Scrum. Além do que pdr e GlenH7 mencionaram, coisas que ajudaram:

1. O melhor testador da equipe de controle de qualidade foi muito bom em nos responsabilizar pela qualidade do nosso trabalho, incluindo o trabalho que fiz. Quando escrevi o código de buggy, ela me chamou de uma maneira que seria difícil para outro desenvolvedor.
2. Eu costumava fazer as demonstrações do Sprint, principalmente quando tínhamos sprints ruins. Desde que eu estava demonstrando para o CEO, foi embaraçoso quando as coisas não funcionaram. Além de garantir que eu entendesse os recursos desenvolvidos por outros, também significava que minhas coisas tinham que ser tão sólidas quanto as de qualquer outra pessoa.
3. Eu deixo os outros tomarem decisões. Minha experiência é diferente da do GlenH7, sempre achei um erro puxar o trunfo. Em vez disso, conversei sobre as diferentes consequências das decisões e deixei claro para quem já estava trabalhando em algo quais eram as consequências para a coisa que eu pensava ser a maneira "errada" de fazer alguma coisa. Há muitas razões para fazer isso, mas a maior delas é que, como líder da equipe, você não tem tempo para tomar todas as decisões.
4. Usar um produto como o Sonar pode tornar coisas como a qualidade do código mais objetivas.