¿Tener múltiples roles (líder tecnológico + programador + Scrum Master) va en contra de las pautas de la metodología Scrum/Agile?

Soy cofundador de una startup de software (software de informes con muchas estadísticas y matemáticas). Hay un director ejecutivo y un "gerente de proyecto" (en realidad, un vendedor sin experiencia en la gestión de proyectos de software)

Creé el software y contraté en su mayoría a programadores junior.

Sigo siendo el líder técnico de facto, ya que a menudo se me necesita para ayudar con las tareas y la resolución de problemas, la planificación de versiones y la implementación.

Ahora propuse un curso Agile a todos, incluidos los gerentes, y comencé a actuar como Scrum Master porque quiero que las personas asuman más responsabilidades y dividan los roles (y porque no tenemos recursos para contratar a un Scrum Master a tiempo completo). Tengo una certificación Scrum Master, pero es mi primera experiencia práctica.

Sin embargo, siento que lo soy todo... - co-fundador (probablemente una parte interesada en la metodología Agile) - CTO - Scrum Master - líder técnico - y sí, programador

¿Eso no choca un poco con una metodología Scrum/Agile? ¿Cómo debo lidiar con eso (dado que probablemente surgirán problemas personales del grupo)?

Respuestas (2)

No hay nada en el enfoque Agile ni en el marco Scrum que diga que un individuo no puede tener múltiples roles.

Sin embargo, existen algunos riesgos en el enfoque que está tomando:

  • ¿Tiene el tiempo para hacer todos estos roles de manera efectiva?
  • En un equipo de desarrollo de Scrum no hay roles que no sean 'miembro del equipo'. Tener un CTO/líder técnico en el equipo puede limitar los beneficios de autoorganización y empoderamiento del marco Scrum.
  • Puede haber un conflicto de intereses entre los roles de las partes interesadas y Scrum Master. El Scrum Master debe centrarse en la facilitación y hacer que las cosas funcionen sin problemas. Es difícil hacer eso mientras se priorizan y explican los requisitos.

Mi consejo sería usar sus retrospectivas para evaluar cuidadosamente qué tan bien están funcionando las cosas. Si usted y el equipo identifican problemas, puede ser necesario ajustar o eliminar algunos de los roles que tiene.

Entiendo que no hay funciones en el equipo de desarrollo, pero mi función es "natural"... surge debido a mi habilidad, experiencia y responsabilidad... Hago hincapié en que el equipo no tiene funciones...
Siempre existe el peligro de que un desarrollador junior no se sienta capacitado para discutir con el CTO. Pero si funciona para usted y los miembros del equipo están felices de presentar argumentos, ¡entonces no hay de qué preocuparse!

Scrum master suele pasar sus días facilitando (no participando en) el standup diario; ayudar al equipo a mantener su gráfico de trabajo pendiente; configurar retrospectivas, revisiones de sprint o sesiones de planificación de sprint; proteger al equipo de interrupciones durante el sprint; eliminar obstáculos que afecten al equipo; guiando al propietario del producto a través de historias de usuarios más técnicas y fomentando la colaboración entre el equipo Scrum y el propietario del producto. Según estas funciones que realiza un Scrum Master, su equipo puede salir adelante sin una persona dedicada si el propietario de su producto sabe todo sobre el cliente y siempre está ahí para el equipo de desarrollo sin la guía del Scrum Master; su equipo de desarrollo tiene una cultura de comunicación tan saludable que las reuniones diarias son redundantes y se suman a la sobrecarga general del proceso; el diagrama de trabajo pendiente y otros artefactos se mantienen automáticamente y no generan gastos generales para el equipo de desarrollo; el equipo opera sin distracciones y puede despejar fácilmente todas las obstrucciones por su cuenta.

Hola usuario, bienvenido a PMSE! Parece que su respuesta tiene parte de ESTA publicación de BLOG ; siendo ese el caso, sería bueno agregar un descargo de responsabilidad a su respuesta.