Los desarrolladores de mi empresa registran horas en JIRA. Los Gerentes/Scrum Masters no registran horas tan religiosamente. Solo iniciarían sesión para las ceremonias de Scrum. Como gerente, puedo ver la razón por la que no agrego mis Tareas al Sprint, ya que reunirse con las partes interesadas, ayudar al equipo con dificultades técnicas, relacionarse con los clientes, etc., no son buenos candidatos para un Sprint de desarrollador. Estos no pueden ser planeados ni arreglados ni nada por el estilo. Y el Equipo no necesita saber los detalles de estos, ya que no son el tipo de Tareas que cualquier miembro debería poder hacer. Solo yo haré estas tareas y, si bien puedo pedir comentarios a mi equipo, no es necesario que preparemos estas tareas como tales.
Recientemente tuvimos una conversación con Recursos Humanos sobre cómo encontrar una manera de registrar el trabajo de los gerentes. Obviamente, podemos crear tareas JIRA para nuestro trabajo, pero luego, como no se agregan al Sprint, no se cuentan para la cantidad de trabajo completado para un proyecto en particular.
¿Puede compartir alguna idea sobre cómo está gestionando esto en su empresa? ¿Creamos un Sprint separado para gerentes, a través de proyectos? ¿O creamos una Historia en cada Sprint para cada categoría de Tareas que realizo durante el Sprint, como gerente? Tenemos de 6 a 10 gerentes con diferentes tamaños de equipo asignados a cada uno de ellos.
HR va a utilizar el desglose. En su mayoría, sería una auditoría del tiempo dedicado y algunas ideas sobre las áreas en las que las personas pasan el tiempo.
Este es un antipatrón conocido. Si el equipo tiene éxito, el Scrum Master (como parte del equipo) está contribuyendo a su éxito general. Si el equipo está fallando, entonces el Scrum Master (nuevamente, como parte del equipo) está fallando junto con ellos.
El equipo tiene éxito o fracasa como un todo. Tratar de desentrañar el desempeño individual para marcos basados en equipos es un anti-patrón. La forma de manejarlo es educar a la organización sobre cómo evaluar de manera efectiva el desempeño de todo el equipo, no secuestrar sistemas de emisión de boletos como JIRA para rastrear las horas de trabajo.
Si no te sientes capacitado para tener esa conversación, eso también es un problema. Hable con su gerente de línea, entrenador ágil u otro patrocinador del proyecto, y asegúrese de que estén apoyando completamente la cultura orientada al equipo de Scrum. Hacer cualquier otra cosa es una abdicación de sus responsabilidades como Scrum Master.
Si el equipo falla de forma rutinaria en cumplir con sus Objetivos de Sprint, entonces este es un problema que todo el Equipo Scrum debe abordar durante las Retrospectivas de Sprint. Ni una Oficina de Gestión de Proyectos (PMO) tradicional ni Recursos Humanos (HR), y por el amor de Dios, ¡¿por qué Recursos Humanos está siquiera en esta imagen?!— deberían participar en la evaluación de los procesos o la utilización dentro del equipo.
Si bien una comunidad de práctica ágil siempre es una buena fuente de asesoramiento e información, la organización debe analizar los resultados (p. ej., "¿El equipo cumple sus Sprint Goals la mayoría de las veces?") en lugar de las métricas de utilización. Tratar de convertir horas individuales en una propuesta de valor es la antítesis de los principios ágiles básicos.
El seguimiento de las horas de mano de obra dentro del proyecto es intrínsecamente una métrica de utilización y, en menor medida, una métrica de seguimiento de costos o contabilidad de costos. Cuando se realiza correctamente a nivel de programa, Scrum generalmente tiene una tasa de ejecución promedio por Sprint que es esencialmente fija. El seguimiento de las horas de trabajo en lugar de los resultados simplemente no se ajusta a este modelo, excepto cuando la organización está violando los principios básicos al agrupar equipos o asignar personas (un segundo antipatrón) a varios equipos (un tercer antipatrón). No hagas esas cosas.
No habilite la disfunción organizativa ni apoye antipatrones conocidos. Educar a la organización sobre cómo se debe aplicar el marco y cómo ser más ágil en su enfoque comercial y en las interacciones con el equipo es una parte esencial del trabajo del Scrum Master.
Si RR.HH. quiere saber cuántas horas al día trabajan las personas, o cuándo se toman tiempo libre, esas son solicitudes razonables relacionadas con los salarios que tienen poco que ver con Scrum como marco de gestión de proyectos. Sin embargo, el seguimiento de tiempo granular es un antipatrón, así que asegúrese de no tener un problema X/Y aquí.
Diga "no" a las métricas de utilización, pero utilice técnicas como los 5 porqués para comprender el problema real que RRHH está tratando de resolver. Es posible que pueda ayudarlos a resolver X en lugar de Y sin dañar su implementación de Scrum.
erik
shaibee