¿Por qué la gerencia está más preocupada por las horas de JIRA que por seguir los valores de Scrum?

Como en muchos otros proyectos, también estamos utilizando JIRA para gestionar tareas e historias de usuarios, y Scrum como metodología Agile. Al final de cada día, ScrumMaster proporciona el gráfico de trabajo pendiente al equipo de PMO.

Sin embargo, el primer conjunto de preguntas que surgen durante cada reunión semanal con el equipo de PMO son:

  • ¿Por qué el equipo no quema horas correctamente en JIRA - 5 horas por día?
  • Si cada miembro del equipo está quemando horas (~ 5-6 horas por día) y las registra correctamente en JIRA, ¿por qué la línea roja (de valores restantes) en el gráfico de trabajo pendiente no se acerca tanto a la guía ?
  • ¿Quién en el equipo no está registrando horas?
  • ¿Por qué se debe recordar al equipo todos los días que registre las horas en JIRA?

Hablando con franqueza, todo el equipo está bastante harto de todas estas preguntas tontas, y todos nos preguntamos si en realidad estamos siguiendo los valores de Scrum, o simplemente manteniendo JIRA para mostrarle a la PMO que todos estamos siguiendo Scrum y tenemos un diagrama de quemado perfecto.

Para mí, siempre me he estado preguntando sobre tres puntos: -

  • ¿Por qué la gerencia está más preocupada por el diagrama de trabajo pendiente de JIRA que por seguir los valores de Scrum en el desarrollo del proyecto?
  • ¿Por qué a algunos miembros del equipo no les gusta registrar horas en JIRA con diligencia todos los días?
  • ¿Hay algo que el equipo pueda hacer para que este registro de horas (por cada miembro del equipo) sea un proceso más fácil, para que la gerencia no nos moleste con preguntas tan malas?

¿Alguno de ustedes puede aclarar mis tres dudas mencionadas anteriormente, para que todos podamos convertirnos en un mejor equipo Scrum?
¡Gracias a todos de antemano, y agradezco su tiempo y sugerencias para ayudarme!

No estoy seguro de que podamos responder por qué su gerencia está interesada en A en lugar de B. Me parece más productivo preguntarles a ellos que a nosotros.
Creo que aquí hay una buena pregunta sobre la interacción con los gerentes que usan métricas para la gestión de proyectos. Por favor, vuelva a elaborarlo siguiendo esas líneas.

Respuestas (3)

Puedo sentir la frustración en tu publicación. Como alguien que hizo la transición de una PMO a una función Agile, puedo entender ambos lados de la moneda.

Su pregunta tiene múltiples componentes que abordaré por turnos, pero todos ellos tienen una comunicación efectiva en su núcleo.

¿Por qué la gerencia está más interesada en el registro de horas?

Esto podría ser una serie de cosas, pero la gerencia absolutamente debe realizar un seguimiento de las horas de trabajo realizadas. Podría ser una o una combinación de las siguientes razones.

  • La empresa debe dar cuenta del valor para los accionistas que se invierte. La entrega efectiva es solo una forma de rastrear el valor, también es necesario asegurarse de que la entrega esté más o menos relacionada con la cantidad de horas de esfuerzo previstas.
  • Auditoría externa y cumplimiento de gobierno. Si su empresa es un PLC, la carga regulatoria y de auditoría aumenta y las horas registradas son un componente crítico de ese proceso. Recuerda; cuando alguien recibe su salario mensual, esa es la inversión de los accionistas de alguien que se transfiere y ese accionista espera un nivel mínimo de retorno de la inversión para pagar ese salario. No es irrazonable simplemente registrar las horas trabajadas, ¿verdad?
  • Horarios . Si está adjunto a una PMO, es probable que el equipo de desarrollo tenga múltiples flujos de trabajo de proyectos o programas. El departamento no es un recurso gratuito, sus desarrolladores deben asignarse a un centro de costos por el trabajo que realizan para que los proyectos puedan ser seguimiento para asegurarse de que están dentro del presupuesto.
  • Demanda de recursos . No subestime que la forma principal en que la gerencia decide aumentar o reducir los recursos es contrastando el esfuerzo planificado en días/horas hombre con un cronograma fijo de tiempo muerto. Si las demandas de recursos exceden la fecha límite, traerán recursos. El registro de horas es una parte fundamental para garantizar que la planificación sea efectiva y precisa. Obtiene desarrolladores y evaluadores adicionales si es necesario, pero el registro de horas es fundamental para hacer ese caso comercial.
  • Confianza. En este momento, parece que la gerencia tiene algunos problemas de confianza con respecto al departamento. Es posible que usted sea un equipo Scrum incipiente, el proceso es nuevo para ellos, no se vendió de la manera correcta o necesitan controlar los recursos de tiempo completo del departamento. Todos estos síntomas son una falta de confianza.

La dura verdad es que nunca permitiría que un empleado renuncie al seguimiento de sus horas si ni siquiera puede realizar un seguimiento de sus horas. ¿Tiene sentido?

En el ejército solíamos tener un dicho:

"Cuando puedas administrarte a ti mismo, te daremos un rifle. Cuando puedas administrar tu rifle, te daremos un vehículo. Cuando puedas administrar un vehículo, te daremos subordinados..."

Si su equipo ni siquiera puede realizar el seguimiento de horas, ¿por qué demonios deberían ser liberados de la tarea? Es un artículo simple que toma menos de 5 minutos. Me sorprende que la gerencia no haya tomado ya medidas más estrictas. Si tu equipo quiere independencia, tiene que ganársela.

¿Por qué mi equipo no registra horas?

Esto es en parte un problema de psicología, pero también indica que no se les ha explicado el valor del seguimiento de horas. Si se les ha explicado el valor y continúan descontando un proceso que la Gerencia considera valioso, entonces usted tiene un equipo disfuncional , posiblemente centrado en uno o dos personajes fuertes que están impulsando al resto del grupo.

En ese caso, debe tomar medidas para inculcar disciplina en el equipo. Un Scrum Master es el maestro-sirviente del equipo. La mayoría de las personas se enfocan en la parte de sirvientes para mostrar humildad, pero no olviden el rol de amo. Imponga su voluntad al equipo para asegurarse de que comprendan exactamente lo que se tolerará y lo que no.

Comunicar al equipo que

  • Las horas deben registrarse al final de cada día.
  • Consolidará todos los registros diariamente e informará sobre los que faltan
  • A los infractores constantes se les informará en su evaluación anual
  • Los infractores constantes están defraudando al equipo porque cuanto antes cumplen, antes puede que la gerencia confíe en el equipo y elimine el proceso.

Siempre es fácil culpar al proceso de gestión en lugar de hacer un análisis de causa raíz; en mi experiencia, la mayoría de los gerentes tienen un razonamiento sólido para los informes y procesos que solicitan. Además, en el futuro, si necesita escalar o desafiar las estimaciones de planificación y no tiene registros que respalden su caso comercial, espere que los recursos vayan a un jefe de departamento que pueda hacer cumplir el registro.

Buena suerte, incluso plantear este problema en PM.SE indica que tiene excelentes cualidades para solucionar el problema.

Actualización 2019

Esta respuesta representa una instantánea en el tiempo de dónde trabajé y cómo me acerqué a Agility. Debo decir que, hoy en día, no apoyo absolutamente la división de horas y la división de horas en sí misma es un síntoma de un olor a proyecto que requiere un análisis de causa raíz. Indica falta de confianza en un equipo o recursos divididos entre entregas. Es, en definitiva, una pésima manera de facilitar el desarrollo de software.

Además, el software funcional es el método principal para demostrar el valor . Todos los demás artefactos son humo y espejos.

Mantengo mi respuesta, ya que muestra el viaje que todos tomamos hacia los valores ágiles, pero ya no la apoyo como un consejo para la comunidad de desarrollo o gestión de proyectos.

Realmente aprecio su tiempo para responder a mis preguntas, y cada uno de sus puntos es fiel a su esencia. Estoy totalmente de acuerdo con eso.
Sin embargo, tengo una pregunta más. A veces reviso el gráfico de trabajo pendiente de JIRA (v 6.4) e informo cuántas horas se han registrado durante el día. Pero no encuentro ninguna forma de tener una lista de aquellos miembros que no registraron horas para ningún día. ¿Pueden ayudarme con algún JQL (JIRA Query Language) adecuado o de alguna otra manera? ¡Gracias de nuevo!
Desafortunadamente, no uso JIRA, aunque otros departamentos de mi organización sí lo hacen. Podría preguntarles si está dispuesto a esperar 24 horas. Sospecho que CodeGnome o Niels tendrán una mejor comprensión de JIRA y recomendaría acercarse a ellos.
Venture2099 - No hay ningún problema, ayer obtuve la solución: - 1. Navegue hasta el proyecto deseado. 2. Elija Resumen (pestaña) > sección Informes > Informe de seguimiento de tiempo. ¡Gracias!
Me gusta el énfasis en que al equipo no se le explica el valor. A menudo encuentro que el estrés en torno a las horas de presentación de informes es, en esencia, un problema de comunicación.
A menos que las horas sean facturables, reportarlas es generalmente una pérdida de tiempo. El requisito para hacerlo es a menudo sobre el estatus relativo, no sobre el valor. En organizaciones donde todos reportan horas, probablemente este no sea el caso. Pero esas organizaciones son pocas y distantes entre sí. Para las organizaciones que requieren horas de informes, pero no exponen esos informes, el valor para esos informes es casi seguro negativo.
@AndrewProck: claramente no leíste mi respuesta. Tendremos que estar de acuerdo en que no estamos de acuerdo. El requisito de facturar/seguimiento de horas es casi SIEMPRE acerca del valor de seguimiento.
Leí tu respuesta. No estoy seguro de por qué asumirías que no lo hice. Eso es un poco grosero en realidad.
@AndrewProck, no es de mala educación asumir que no leyó mi respuesta. Me vinieron razones muy concretas y válidas para el seguimiento de horas. La publicación es la más votada y se ha marcado como "la respuesta". Sin embargo, su respuesta fue un par de líneas desechables que esencialmente decían "esta respuesta es incorrecta, las horas de informe tienen un valor negativo". Así que sí... Asumo que en realidad no leíste lo que había escrito.
Si bien aquí hay argumentos válidos para el seguimiento del tiempo (aunque no estoy de acuerdo con muchos de ellos), no aborda el problema de JIRA. Y eso es en realidad una llave inglesa gigante. Mucha gerencia quiere usar JIRA como una herramienta de seguimiento del tiempo, que simplemente no lo es. Y en muchos sentidos interfiere con el proceso ágil con el que se supone que JIRA está ayudando.
En cuanto a mi opinión sobre el seguimiento del tiempo: youtube.com/watch?v=_ogxZxu6cjM
Al igual que Andrew, tendría que estar en desacuerdo con este enfoque de arriba hacia abajo. Específicamente, "siempre es fácil culpar al proceso de gestión en lugar de hacer un análisis de causa raíz; en mi experiencia, la mayoría de los gerentes tienen un razonamiento sólido para los informes y procesos que solicitan". En mi experiencia, el análisis de causa raíz de este escenario casi siempre conducirá a gerentes con malas razones como "mi jefe lo quiere" o "en realidad no confío en los desarrolladores". Si desea evidencia reciente de los efectos negativos de este estilo de gestión "porque yo lo digo", búsquelo en Google, hay mucho por ahí: Drive, etc. :)
Al leer esto más, en realidad no estoy de acuerdo con casi todo lo que Venture aconseja, básicamente microgestión de arriba hacia abajo y lo opuesto a los valores ágiles modernos. El Scrum Master no es un maestro del equipo en ningún sentido de la palabra, son líderes 100% servidores y, en todo caso, retadores del status quo (que en este caso significa un seguimiento de horas desafiante). Incluso diría que la mayoría de las empresas ágiles modernas ven a todos los que están fuera de los equipos de entrega, incluida la gerencia, como sirvientes del equipo. Con toda seriedad Venture, realmente recomiendo leer Drive, Joy Inc., Leaders Eat Last, etc.
Has cometido un error fundamental @JeffLindsey. Has asumido que yo personalmente apoyo la división de horas. Yo no. Empujé contra eso y gané esa pequeña victoria para mi equipo. Sin embargo, demasiadas personas en la comunidad ágil sienten que se pueden ganar todas las batallas contra la alta dirección, lo que simplemente no es cierto. A veces, "ellos" ganan y los principios ágiles pasan a un segundo plano. Esa es la realidad. Así que mi respuesta comenzó desde allí. Puede estar en desacuerdo conmigo, pero no puede cambiar el mundo y todas las estructuras de gobierno corporativo. Mi pedigrí de liderazgo está bastante bien informado y leo mucho.
Si ingresa a una auditoría regulatoria para un PLC y le piden hojas de tiempo, es mejor que las tenga. Los principios ágiles no evitarán que se quede sin trabajo ese día y que se redacte un nuevo "PM ágil" que tenga la capacidad de combinar los requisitos de entrega rápida con las prácticas laborales normales de una oficina de gestión de programas. Podemos pasar todo el día charlando sobre las prácticas de trabajo aspiracionales que queremos, pero no intentemos pintar eso como la realidad del mundo porque simplemente no lo es. Además, el ScrumMaster es absolutamente el Maestro-Servidor del equipo.
Muéstrame en los valores ágiles donde dice que cada empleado está altamente motivado y siempre ofrece valor y busca el desarrollo profesional... muéstrame donde dice que los recursos individuales divididos en múltiples proyectos no deben rastrear las horas que pasan apoyando a los que difieren proyectos... muéstrenme dónde dice Agile es incompatible con un entorno regulatorio. no lo hace Es un conjunto de valores que deben interpretarse de manera única en cada entorno.
Cambié mi carrera de un PM a un desarrollador, ahora sé cómo apesta esta idea de horas de registro. Si necesito registrar mis horas dedicadas a cada tarea cada día, es válido y factible. Sin embargo, Jira obliga a las personas a registrar la hora de inicio, lo que será un problema... Es muy difícil averiguar la hora exacta al final del día, y si te atreves a registrar la hora después de cada trabajo, será difícil manejar la realizar múltiples tareas y retrasar el procedimiento.
Apreciado por la actualización @Venture2099

¿Por qué la gerencia está más preocupada por el diagrama de trabajo pendiente de JIRA que por seguir los valores de Scrum en el desarrollo del proyecto?

3 razones comunes para este tipo de comportamiento son:

  1. Falta de confianza
  2. Poca comprensión de las metodologías ágiles; todavía pensando en términos de cascada
  3. El equipo de entrega no cumple con los compromisos

¿Por qué a algunos miembros del equipo no les gusta registrar horas en JIRA con diligencia todos los días?

O se percibe como una pérdida de tiempo, o el miembro del equipo no comprende el valor de realizar la actividad, o no ha recibido refuerzo para continuar con esta práctica.

¿Hay algo que el equipo pueda hacer para que este registro de horas (por cada miembro del equipo) sea un proceso más fácil, para que la gerencia no nos moleste con preguntas tan malas?

  • Generar confianza
  • Honrar compromisos
  • Educar a la PMO sobre metodologías ágiles
  • Muéstreles una forma alternativa de seguir el progreso del trabajo
  • Despida a la PMO actual y contrate a una que entienda Agile;)

Para facilitar el registro de horas en Jira, puede utilizar el programa asistente de registro de trabajo. El asistente de registro de trabajo toma todos los filtros de Jira, obtiene una lista de los problemas de sprint actuales, por ejemplo. Te avisa cuando no registras tiempo. Es posible publicar automáticamente o hacerlo manualmente y corregir algunos registros cuando sea necesario. Cree algunos tickets de marcador de posición para el tiempo de inactividad, como reuniones de sprint u otros gastos generales que no sean de sprint.

No estoy seguro si lo hace, pero no calcule las tareas en horas, cambie a puntos de historia (esto es compatible con Jira). Para la gerencia es más difícil convertir el trabajo realizado en horas y compararlas. El trabajo se hace cuando se hace, no cuando el equipo lo estima. Algunas tareas tomarán más tiempo, otras tomarán menos tiempo. El trabajo pendiente está ahí para brindar información si va a terminar su pronóstico y adaptarse en consecuencia si el plan no funciona.

Creo que la gerencia está preocupada por las horas, porque les pagan a los desarrolladores por hora. Cada hora es dinero extra. Explique cómo Scrum brinda a los desarrolladores más enfoque y que es más difícil desviarse de cosas que no son importantes.

Una vez estuve en una presentación de Scrum por parte de Jeff Sutherland y dijo que lo primero que cambia en una empresa es eliminar el seguimiento del tiempo. Lea también la publicación de su blog Time Tracking is Anti-Scrum: ¿Qué hace cuando lo necesita para la facturación?

Se acordó en general en una clase de capacitación de Scrum en Copenhague ayer con líderes de proyecto experimentados que operan en CMMI Nivel 5 en IBM y en otros lugares que pedir a los desarrolladores que completen las hojas de tiempo reduce la productividad del equipo en al menos un 10%. Odian hacerlo, es trabajo duplicado, obviamente es "desperdicio", y solo lo hacen empresas que no tienen ni idea sobre el desarrollo de productos lean.

Niels: creo que esto hará dos cosas. La gerencia exigirá una tabla de conversión de puntos a horas (y sería correcto hacerlo aunque los puntos son relativos). La segunda es que una mirada superficial al debate horas vs puntos revelará el blog de Mike Cohn donde argumenta con éxito que todas las tareas de sprint deben estimarse en horas. Intentar eludir la gestión con esoterismo ágil empeorará el problema en mi mente.
El principal problema que tengo con las horas es que los desarrolladores sienten la presión de terminar la tarea en cuestión en esta ventana de tiempo. Conduce a atajos y estrés. Si bien deberían centrarse en la calidad y hacerlo realmente bien en lugar de pensar que se acabó el tiempo para esta tarea. Personalmente me gusta medir en días-hombre, cuántos días-hombre se necesitan para terminar esta tarea es más fácil de responder y menos exacto. ¿Tiene un enlace al blog de Mike Cohn? Google conduce a múltiples resultados. Me gustaría leer más y pensar en ello. Ya que siempre es la misma lucha con la gerencia... :)
Hola, Niels: esta es la publicación de blog relevante y Mike alienta el desafío directo a través de los comentarios, por lo que estoy seguro de que apreciará sus pensamientos. mountaingoatsoftware.com/blog/…
@NielsvanReijmersdal, creo que el problema de que los desarrolladores se sientan presionados para terminar en la ventana de tiempo tiene más que ver con cómo se presentan las estimaciones que con las unidades de la estimación. Mi equipo estima en "días-persona ideales" y enfatizo que a) es mi trabajo convertir eso en días calendario para la administración, y b) lo importante es mejorar en la estimación con el tiempo, en lugar de terminar dentro del estimar.
Este es un buen contrapeso a la respuesta aceptada que sigue diciendo mgmt quiere ver "valor". El valor es el software de trabajo. No sirve de nada trabajar 80 horas si nada funciona lo suficientemente bien como para ir a prod. ++