Ser gerente de equipo y desarrollador en un equipo Scrum

Estoy administrando un equipo de 6 personas que recientemente se mudaron a Scrum.

Tenemos un Scrum Master (uno de los desarrolladores del equipo) y un Product Owner.

Como tengo bastante tiempo libre (porque mucho trabajo de administración que solía hacer ahora lo hace el Scrum Master y el propietario del producto), y dado que quiero seguir siendo técnicamente relevante, estoy haciendo un trabajo de desarrollo técnico.

Actúo como parte del equipo de desarrollo, me comprometo con algunas de las historias en cada sprint y participo en todas las reuniones como parte del equipo.

¿Crees que es una buena idea? ¿Puede contradecir la "autoorganización" del equipo?

Eche un vistazo a los pensamientos en desarrollo de Roy Osherove sobre el liderazgo del equipo en un mundo ágil en 5whys.com

Habla mucho sobre tres etapas clave que atraviesa un equipo a medida que evoluciona de Cascada a Scrum.

La fase de supervivencia (donde se encuentran la mayoría de los equipos que veo), en la que el equipo no tiene tiempo para aprender, requiere un tipo de liderazgo más de comando y control para crear ese tiempo de aprendizaje de la nada.

La fase de aprendizaje , donde un equipo tiene tiempo para aprender y la está utilizando, requiere un entrenador como líder, con estallidos de control cuando las cosas tomarán demasiado tiempo para aprender de la manera difícil (por ejemplo, no elegir el control de la fuente)

Fase de autoorganización : donde los equipos pueden resolver sus propios problemas, requiere más de un tipo de líder facilitador, que no le dice a la gente qué hacer, sino que simplemente proporciona restricciones y objetivos finales. El equipo llegará solo.

Cuando me encontré con las ideas de Roy, en OpenVolcano '10 , no sabía por qué mi equipo había dejado de mejorar. Luego me di cuenta de que el equipo había cruzado de Survival a Learning y que no había cambiado mi estilo de gestión en absoluto. Lo hice y me ayudó mucho.

Por lo tanto, sugiero averiguar en cuál de esas tres fases se encuentra y administrar en consecuencia.

Además, tome una decisión ahora y sea un líder o desarrollador. No caigas en la trampa de pensar que tienes tiempo libre hasta que estés en la fase de autoorganización. Y, si llegas allí, date cuenta de que eres un buen líder de equipo (es difícil ) y pasa a otro equipo en lugar de reintegrarte.

Los comentarios de pdr son válidos, y estoy de acuerdo con ellos. Pero no creo que sean universales para todos los casos.

Su estilo de gestión determinará qué tan bien o si debería considerar trabajar en dos roles.
Como gerente de equipo, usted tiene autoridad sobre el desempeño y las decisiones de tipo profesional para sus empleados. Esgrimido incorrectamente, la disparidad de poder entre usted y sus empleadores puede arruinar sus intentos de ser parte del equipo de desarrollo.

Mientras sea consciente de esa disparidad y delinee claramente entre sus roles, creo que puede ser tanto gerente como desarrollador. Lo he visto con éxito varias veces, y actualmente estoy trabajando en un equipo en la misma situación.

Vale la pena señalar que no puede eliminar todos los efectos de la disparidad. Habrá momentos en los que necesite morderse la lengua y contenerse de un debate enérgico. Habrá otros cuando necesite sacar la carta de triunfo y señalar que la responsabilidad final del equipo recae en usted, por lo que está haciendo un dictado.

Necesitará al menos dos desarrolladores fuertes y experimentados en su equipo que sean políticamente seguros. Su función es mantener la disparidad de poder bajo control y llamarlo si las cosas se están desequilibrando. Podrían sobrevivir con solo otro desarrollador fuerte, pero tener un segundo proporciona objetividad en caso de que ambos se encuentren en un punto muerto.

Sinceramente, me gusta cuando mi supervisor inmediato se mantiene técnicamente relevante. Facilita su comprensión de mis dificultades, y creo que terminamos con un equipo con mejor desempeño.

Pasé por una experiencia similar antes, liderando un equipo de 6 desarrolladores en un equipo Scrum. Además de lo que pdr y GlenH7 han mencionado, cosas que ayudaron:

1. El mejor evaluador del equipo de control de calidad fue realmente bueno al hacernos responsables de la calidad de nuestro trabajo, incluido el trabajo que hice. Cuando escribí un código con errores, ella me llamó de una manera que sería difícil para otro desarrollador.
2. Usualmente hacía los Sprint Demos, especialmente cuando teníamos malos sprints. Como estaba haciendo una demostración ante el CEO, fue vergonzoso cuando las cosas no funcionaban. Además de garantizar que entendía las características que otros desarrollaban, también significaba que mis cosas tenían que ser tan sólidas como las de cualquier otra persona.
3. Dejo que otros tomen decisiones. Mi experiencia es diferente a la de GlenH7, siempre encontré que era un error sacar la carta de triunfo. En cambio, hablé sobre las diferentes consecuencias de las decisiones y dejé en claro a cualquier desarrollador que estuviera trabajando en algo cuáles fueron las consecuencias para lo que pensé que era la forma "incorrecta" de hacer algo. Hay muchas razones para hacerlo, pero la más importante es que, como líder del equipo, no tienes tiempo para tomar todas las decisiones.
4. Usar un producto como Sonar puede hacer que cosas como la calidad del código sean más objetivas.