Scrum y la deuda del proceso: el camino del cambio sobre la cuerda floja

Scrum y la deuda del proceso: el camino del cambio sobre la cuerda floja

Muchos coincidimos en que la fuerza de Scrum radica en su adaptabilidad. O, al menos, eso es lo que parece que hemos difundido y asimilado. Es un hecho, Scrum permite a los equipos reaccionar a los requisitos cambiantes y corregir el rumbo en cualquier momento del ciclo de vida del producto. Sin embargo, este cambio constante también puede conllevar un costo oculto: la deuda del proceso.

La deuda del proceso

Antes de continuar, veamos una breve definición. La deuda de proceso es una metáfora que usamos para describir la acumulación de ineficiencias en la forma en que se realiza el trabajo. Es similar a la deuda técnica, donde las soluciones rápidas, los atajos y las fallas en el producto crean problemas en el futuro. Pero la deuda de proceso se centra en las ineficacias dentro del propio flujo de trabajo.

En un artículo posterior profundizaré más sobre sobre este espinoso asunto.

Los equipos Scrum son grandes acumuladores de deuda del proceso

En pro de “cumplir” con los plazos y, sobre todo, con la “cantidad” de historias de usuario comprometidas en cada sprint, los equipos Scrum contraen grandes deudas de proceso. Y todo tiene como causa raíz esa comodidad de satisfacer en el corto plazo, sin preocuparse de lo que vendrá más adelante. Algo de lo que he visto incluye:

• Pobre refinamiento del Product Backlog: debido a la presión del tiempo, el equipo, con el Product Owner a la cabeza, omite un refinamiento profundo de las historias de usuario planificadas para los próximos sprints. Se basan en una comprensión superficial que conduce a historias de usuario con criterios de aceptación poco claros o faltantes y a malentendidos durante el desarrollo, cuando el equipo descubre muy tarde lagunas en su comprensión de las historias que requieren volver a trabajar.
• Reuniones diarias apresuradas y sin atención: para ahorrar tiempo, las reuniones diarias se vuelven una “izada de bandera”, eventos apresurados, superficiales y carentes de concentración. Las actualizaciones y obstáculos importantes no se analizan adecuadamente, y el Objetivo del Sprint es algo totalmente olvidado. Esto lleva a falta de transparencia, ya que los miembros del equipo no están seguros del progreso y las dependencias de los demás; también a impedimentos sin abordar y a que los problemas que podrían resolverse fácilmente durante estas sesiones se agraven y se conviertan en dificultades mayores más adelante.
• Revisión/Retrospectiva de Sprint degradadas: la atención se centra en mostrar funciones completadas, con una discusión mínima sobre las lecciones aprendidas o las deficiencias de los procesos, ocasionando el que no se aborden oportunidades de mejora ni problemas recurrentes, cuya solución podría agilizar los sprints futuros.

Cómo pagar la deuda del proceso

Contrario a lo que ocurre con las deudas financieras, no hay manera de pagar la deuda del proceso de una sola vez. Es algo iterativo, así que no intentes abordarlo todo a la vez. Uno de los casos más comunes es la constante insatisfacción de los interesados y clientes tras la entrega de cada incremento de producto. Esto abruma a los equipos que ven como su “objetivo” se siente lejos de alcanzarse.

Durante las retrospectivas, en el mejor de los casos, hemos identificado problemas como estos:

• Las historias de usuario carecen de detalles, lo que genera confusión y reelaboración durante el desarrollo.
• Se adicionan requisitos a mitad del sprint, lo que interrumpe el flujo de trabajo y provoca retrasos.
• La transferencia incompleta de conocimiento entre miembros del equipo genera una pérdida de tiempo para ponerse al día con las tareas en ejecución.

Entre otros. Estas ineficiencias son síntomas clásicos de la deuda del proceso. La falta de refinamiento del Product Backlog, los canales de comunicación poco claros y los silos de conocimiento están obstaculizando la eficacia del equipo.

Aquí es donde empezamos a experimentar, por ejemplo, con sesiones más efectivas dedicadas al refinamiento del Product Backlog: antes de la planificación del siguiente sprint, todo el equipo colabora para aclarar historias de usuario, estimar esfuerzo y priorizar el trabajo pendiente. Además, promovemos un entorno donde la conversación abierta cara a cara sea el comportamiento preferido para abordar las historias de usuario

También, cambiar o ajustar el enfoque de las reuniones diarias para enfatizar la transferencia de conocimiento. Los miembros del equipo discuten quién trabajará en tareas compartidas y se aseguran de que se aborden las preguntas pendientes de transferencias anteriores, sin olvidar el requerido “cómo vamos hacia el logro del objetivo del sprint”.

Son cambios tenues, poco a poco, pero a medida que se vigorizan y se suceden los resultados no se hacen esperar:

• Retrabajo disminuido: historias de usuario más claras minimizan la confusión y el retrabajo durante el desarrollo.
• Planificación de Sprint mejorada: el trabajo pendiente priorizado y refinado permite una planificación de Sprint más precisa.
• Transferencias más fluidas: los miembros del equipo están mejor preparados para sus tareas, lo que genera menos pérdida de tiempo y una mejor colaboración.
• Mayor motivación del equipo: el equipo se siente más empoderado y eficiente, lo que genera un aumento de la moral.

El Scrum Master y la deuda del proceso

Un principio clave en Scrum son los equipos autogestionados. Si bien esto permite a los equipos gestionar su trabajo de forma eficaz, también puede crear una brecha en la propiedad del proceso. Es la infame cultura de “cuando todo el mundo es responsable, nadie es responsable”. Esto significa que no existe una persona o grupo claro comprometido a identificar, analizar y mejorar el flujo de trabajo del equipo.

¿O sí?

Un Scrum Master juega un papel crucial en el pago de la deuda del proceso. Puede facilitar debates y acciones sobre la mejora de procesos durante las retrospectivas, además de alentar al equipo a asumir la responsabilidad.

Esto es importante, no toda el agua sucia debe recaer sobre el Scrum Master. Si bien el Scrum Master desempeña un papel decisivo a la hora de facilitar las prácticas Scrum, no debería ser el único responsable de la propiedad del proceso. Delegar y empoderar al equipo para identificar y abordar las ineficiencias es clave.

Así que, ¿qué estás haciendo para no contraer deuda del proceso? ¿Eres consciente de ella?