¿El seguimiento del tiempo facturable para las ceremonias de Scrum en JIRA es un antipatrón?

La respuesta directa a su pregunta es que la forma en que factura su tiempo al cliente no se aborda en Scrum. Por tanto, no existe un modelo de facturación que sea expresamente anti-scrum. Si agregar un lugar en el tablero donde realiza un seguimiento del tiempo es la forma más fácil para que su equipo lo controle, siéntase libre.

Ahora, existen modelos de facturación que pueden incentivar comportamientos anti-Scrum. Por ejemplo, si está facturando por cuarto de hora para cada persona en el evento Scrum, el cliente puede presionarlo para que deje fuera de la reunión a las personas que deberían incluirse. Eso iría directamente en contra de Scrum, pero la facturación en sí está bien.

Scrum funciona mejor si tiene una buena propiedad del producto, iteraciones de longitud fija y un equipo estable. Si el trabajo atrasado lo determina el cliente y el equipo es estable, entonces (salvo licencias y ausencias inesperadas), esperaría que el costo por iteración sea fijo. Entonces, si necesita prorratear el costo por elemento, la forma correcta es dividir el costo de la iteración (incluidos los eventos) por el esfuerzo relativo invertido en cada historia.

Para un sprint de dos semanas, anticiparía que los eventos de Scrum no supondrán más del 10 % del esfuerzo del equipo. Pero la mayor parte de eso es el tiempo que se pasa con el PO (Planificación, Revisión y Refinamiento), por lo que si el PO es el cliente, el costo de los eventos debería ser muy visible y estar bajo su control de todos modos.

Muchos equipos de scrum registran las horas realizadas en cada elemento del backlog del sprint, aunque a menudo principalmente para su propio beneficio, por ejemplo, para optimizar el trabajo y comprender el impacto del bloqueo. Si es importante para el cliente, le sugiero que registre eventos en el backlog del sprint (es decir, tareas) mientras continúa estimando el backlog del producto usando puntos. No veo ningún gran problema en hacer eso.

TL;RD

Scrum se basa en una metodología de control empírico. Si bien no se establece directamente en la Guía de Scrum, esencialmente postula una tasa de ejecución más o menos constante para cada Sprint, lo que permite un presupuesto predecible al estimar la cantidad de Sprints que probablemente se necesiten para alcanzar un objetivo "suficientemente bueno". (Consulte Planificación de lanzamiento ágil para obtener más información al respecto).

En general, el presupuesto/facturación debe basarse en el costo promedio de sus Sprints (por ejemplo, 7 personas en 40 horas por semana) en lugar de tratar de ser más granular. Los eventos de Scrum son una sobrecarga del marco, y facturarlos como elementos de línea separados no ayudará a nadie a medir los resultados.

Si bien su caso de uso puede ser diferente, tratar de facturar el proceso del marco por separado de las actividades prácticas de desarrollo es un olor a proyecto. Implica fuertemente que la gerencia no ve ningún valor en la planificación, la comunicación o la coordinación, y probablemente intentará exprimir los "gastos generales" para obtener eficiencias de costos pírricas a costa de los eventos esenciales de inspección y adaptación. Si lo hacen, es probable que rompan el proceso y se queden con ambas mitades.

Una inmersión más profunda

Los ejecutivos me pidieron que también hiciera un seguimiento de todas las ceremonias de Scrum en JIRA.

No define su rol en su publicación original, pero voy a asumir "Scrum Master". Independientemente, este es un momento de enseñanza para usted, el Equipo Scrum y el resto de la organización. ¡Quizás incluso el cliente también!

Es una buena apuesta que este es un problema X/Y . Una buena manera de descubrir el verdadero problema subyacente es utilizar la técnica de los cinco por qué . Considere esta cadena de preguntas de ejemplo:

1. ¿Por qué desea que el tiempo dedicado a los eventos de Scrum se registre en JIRA?
2. ¿Por qué es útil realizar un seguimiento del tiempo dedicado a las actividades esenciales del marco por separado de otras actividades?
3. ¿Por qué la gerencia o el cliente necesitarían distinguir entre diferentes tipos de actividades requeridas por nuestros procesos internos?
4. ¿Por qué esta información mejoraría el proceso de desarrollo o entrega?
5. ¿Por qué esta información alimentaría KPI y métricas basadas en resultados?

Esta cadena (o una similar que se adapte mejor a su caso de uso y se ajuste dinámicamente a las respuestas proporcionadas) probablemente dará como resultado una o más declaraciones de causa raíz que indiquen:

• Falta de confianza en el equipo o en el proceso de desarrollo ágil.
• Pensamiento mágico, como la falacia de utilización del 100 % .
• Incapacidad de la organización para aceptar los valores, principios y objetivos de un proceso incremental o iterativo.
• Un deseo de usar Buzzword Management™ para reclamar agilidad sin comprometerse realmente con el marco.
• Un estilo de gestión que busca un botón de "ir más rápido" sin una disposición a pagar los costos en el proceso y el cambio de cultura.

Scrum no es un botón mágico para ir más rápido. Es un marco que utiliza la planificación empírica para crear un proceso sostenible con una cadencia predecible. Puede aumentar la eficiencia, pero en este caso la eficiencia significa "hacer más de las cosas correctas y construir más de lo que importa" en lugar de simplemente acelerar el ritmo al deshacerse de todos los molestos gastos generales del proyecto .

Descubra la intención real de este objetivo de gestión. Si tiene sentido, involucre al equipo para determinar la mejor manera de rastrearlo. Si es un ejercicio inútil, eduque al equipo de gestión (y posiblemente al cliente) sobre cómo funciona realmente Scrum y qué palancas les brinda el proceso de control empírico para administrar los costos, el cronograma, la calidad y el cambio.

Estoy confundido. Dices que facturas horas al cliente. Por eso entiendo "horas de trabajo".

Las ceremonias de Scrum son parte del trabajo que está haciendo el equipo . Cuando realiza una reunión diaria, por ejemplo, lo hace para que el equipo coordine su trabajo en el sprint. Hablas del trabajo allí, no del clima, o de cómo tu gato metió la cabeza en un frasco y fue tan divertido... ¿Por qué registrar esta vez por separado? ¿Con qué propósito? Esto es lo más importante que hay que averiguar: ¿"por qué"?

En proyectos más tradicionales, realiza un seguimiento del tiempo en varias tareas, para comparar el tiempo estimado con el consumido real y usarlo para realizar un seguimiento del progreso del proyecto. ¿Estamos en camino? ¿Estamos detrás? etc. También realiza un seguimiento de los gastos generales de gestión de proyectos por separado, como reuniones, creación de informes, tareas administrativas, etc. Esto es útil para ver cuánto esfuerzo se necesita para gestionar el proyecto (es decir, las cosas necesarias para organizar el trabajo). ¿Fue un proyecto fácil? ¿Fue difícil de manejar? ¿Era un proyecto normal? ¿Podemos esperar el mismo porcentaje de gastos generales de gestión en proyectos similares en el futuro?

Si esa es la razón para medir el tiempo dedicado a las ceremonias de Scrum (es decir, para ver cuánto se necesita para organizar el trabajo, que en sí mismo es trabajo), entonces podría tener algún sentido, incluso si es solo por tener este hábito de su antiguo metodología y resulta difícil sacudirse.

Pero recuerde que la medida del progreso en Scrum es el software que funciona , con el trabajo de mayor valor primero. No es la cantidad de horas que trabajó en comparación con la cantidad estimada o restante que aún le queda . Además, en Scrum, las ceremonias están encuadradas en el tiempo . Hay un techo máximo para la cantidad de tiempo que consumirá en lo que llama "tiempo Scrum". Tiene sentido medir esto y ver si va más allá del techo, en cuyo caso eso podría ser una señal de que algo está sucediendo, algo que necesita arreglarse o mejorarse, pero todavía no veo cómo este "tiempo Scrum " encaja con las horas que facturas.

Cómo facturas tu trabajo no es realmente una técnica a favor o en contra de Scrum. Pero la razón de "por qué" podrías hacerlo de una forma u otra podría ser . Si, por ejemplo, realiza un seguimiento del "tiempo Scrum" por separado y a alguien no le gusta el número que obtiene, es posible que se sienta tentado a reducirlo. ¿Por qué tantas reuniones diarias? Solo toma uno a la semana, el lunes. ¿Las retrospectivas tardan demasiado? No los hagas más. etc. Si este es tu primer proyecto Scrum y no sabes realmente lo que estás haciendo, terminarás con más problemas que cómo facturar al cliente.

¡Así que descubre por qué!

Es una mala práctica porque Scrum no tiene ceremonias. Scrum tiene eventos y sirven para inspección y adaptación. La planificación del trabajo y el seguimiento del progreso no son gastos generales, sino una parte integral del proceso de entrega. Esto está claro en la Guía Scrum.

Desde el punto de vista del cliente, el seguimiento del tiempo es interesante porque no quieren pagar el almuerzo del equipo, la reunión semanal de control de calidad, el simulacro de incendio, la capacitación en seguridad, lo que sea, pero tiene poco sentido medir el tiempo de los eventos de Scrum por separado. Y seguramente no está al unísono con el manifiesto ágil ya que la negociación del contrato parece ser más importante que la colaboración con el cliente. Pero hacer que su cliente sea ágil es mucho más difícil que hacerlo usted mismo.

Por otro lado, ningún sistema de seguimiento del tiempo es perfecto, por lo que mientras los objetivos de facturación y presupuesto estén respaldados adecuadamente, el problema es de otra persona. La autoridad del Scrum Master claramente no cubre asuntos financieros y legales.

Muchos equipos de scrum registran las horas realizadas en cada elemento del backlog del sprint, aunque a menudo principalmente para su propio beneficio, por ejemplo, para optimizar el trabajo y comprender el impacto del bloqueo. Si es importante para el cliente, le sugiero que registre eventos en el backlog del sprint (es decir, tareas) mientras continúa estimando el backlog del producto usando puntos. No veo ningún gran problema en hacer eso.

Seguimiento del tiempo además de la estimación (supuesta)... ¿cuándo se supone que este equipo debe funcionar? Personalmente, veo un gran problema en hacer esto. Como Asesor, Scrum Master o Gerente, puede comprarlo porque no perderá su tiempo personal, pero el equipo no estará contento con eso.

A la pregunta original. Desde un punto de vista financiero, tiene mucho sentido cobrar los costos completos, incluidos los gastos generales de gestión y procesos, como las ceremonias de Scrum. Alguien debería pagarles un salario.

Desde un punto de vista operativo, las ceremonias de seguimiento parecen una sobrecarga adicional que no agrega ningún valor y deteriora la moral del equipo, como podemos ver en su publicación. La empresa ya está "pagando" los gastos generales de primer orden de Scrum y luego otra ronda de gastos generales de segundo orden para rastrearlos y finalmente transferirlos al cliente :)

Si bien hay una serie de razones por las que es una buena o mala idea y qué tan granular quiere ser, existe un compromiso: una aplicación de Jira para el seguimiento de tiempo automatizado que no requiere registro manual y puede manejar "gastos generales" sin Entradas. Sin embargo , deberá aprender un poco más sobre Kanban .