Este artículo es una continuación que proporciona un poco más de detalle sobre las métricas definidas en el artículo No busques equipos rápidos, construye equipos efectivos.
En aquel artículo se explica que la efectividad puede ser el concepto que guíe el trabajo de los equipos ágiles, así como las comunicaciones con la organización, por encima de la eficiencia o la eficacia.
Así, en aquel artículo se propone la lista de aspectos o métricas que pueden ayudarnos a ser más eficaces como equipo:
Estos elementos permiten evaluar la efectividad con un alcance más amplio y alineado con los principios de mejora continua, aprendizaje y sostenibilidad propios de los entornos ágiles. Todos estos indicadores, de los que hablaremos a continuación, ayudan a entender no solo cuánto se entrega, sino cuán saludable es el sistema de trabajo.
Como vimos en el artículo anterior de una forma más detallada No busques equipos rápidos, construye equipos efectivos, cuando se analiza la efectividad de un equipo, a menudo se pone el foco en el tiempo de construcción técnica (cycle time), pero habitualmente, antes de que una necesidad llegue a la fase de construcción, suele pasar por procesos de descubrimiento, definición, validación y priorización (lead time). Estos procesos también consumen tiempo y recursos, e influyen directamente en el valor final que seremos capaces de entregar.
Por este motivo, la optimización del flujo de trabajo debe considerar todo el proceso, desde la idea inicial hasta la entrega. Mejorar solo la fase de construcción puede resultar en mejoras técnicas, pero no necesariamente en una mejora en la calidad de los resultados, su valor o su idoneidad.
La calidad de las herramientas de gestión del trabajo que están en manos del equipo tiene un impacto directo en la efectividad. El Product Backlog y los Scrum Boards (o tableros) no son solo herramientas de visualización, sino mecanismos para facilitar la toma de decisiones y la generación de valor.
Un Product Backlog de calidad contiene elementos con algunas características importantes:
En este sentido, las historias de usuario constituyen una herramienta útil y habitual que ayuda a todas las partes a definir elementos de valor en el Product Backlog.
Cuando el backlog no cumple estas condiciones de calidad, se generan dudas, trabajo que debe rehacerse y pérdida de foco del equipo.
Los Scrum Boards reflejan el estado del flujo de trabajo en tiempo real. Si el backlog es confuso o está desactualizado, los tableros acaban mostrando información poco fiable, lo que dificulta la coordinación y la planificación.
Por el contrario, los Scrum Boards claros y actualizados permiten visibilizar cuellos de botella, detectar bloqueos que permitan al equipo actuar y facilitar la toma de decisiones con el objetivo de alcanzar los compromisos establecidos al inicio del ciclo.
La mejora de la calidad del backlog y de los tableros no es solo responsabilidad de un rol concreto (el Product Owner o el Scrum Master), sino que se trata de una práctica colectiva orientada a mejorar la transparencia y el flujo de trabajo.
Algunos indicadores o métricas útiles para evaluar esta calidad pueden ser:
En definitiva, un backlog y unos tableros de calidad no solo ordenan el trabajo, sino que mejoran la capacidad del equipo para tomar decisiones informadas y generar valor de manera sostenida.
Cómo hemos visto de forma más detallada en No busques equipos rápidos, construye equipos efectivos, la calidad del resultado es un factor clave en la efectividad real de un equipo. Entregar rápidamente pero con defectos, carencias técnicas o producto no contrastado generará trabajo adicional, aumento de costes y pérdida de confianza.
La Definition of Done (DoD) establece los criterios que debe cumplir un incremento para ser considerado completo y usable por los usuarios:
El DoD ayuda a evitar que la entrega de incrementos acumule deuda técnica o degradación que afecte a la calidad del producto en su conjunto. Por este motivo, el cumplimiento sistemático del DoD es también un indicador relevante de efectividad. Un equipo que entrega incrementos que cumplen el DoD reduce necesidades de refactoring, mejora la fiabilidad del producto y facilita la toma de decisiones basada en incrementos realmente terminados y útiles.
Los bugs son un riesgo habitual en el desarrollo de producto. Su gestión tiene un impacto directo en la efectividad del equipo. Por nuestra parte, medir los bugs permite entender:
No todas las incidencias son bugs. A veces se confunden con nuevas necesidades, mejoras o cambios de requisitos. Tampoco todos los bugs tienen el mismo impacto. Clasificarlos según severidad y urgencia permite tomar mejores decisiones.
No existe una única forma de gestionar los bugs. Algunas estrategias habituales incluyen:
En cualquier caso, es importante hacer visible el esfuerzo que supone la resolución de un bug. Este trabajo también consume capacidad del equipo e influye en los compromisos y el objetivo del Sprint. Tenerlo en cuenta facilita conversaciones realistas sobre compromisos y prioridades.
Descripción del problema
Un equipo soporta una alta ratio de bugs que afectan a la calidad de las entregas y a la confianza de la organización. Cada entrega lleva asociada la aparición de bugs que afectan al siguiente Sprint y a la capacidad de focalización del equipo.
¿Qué nos indica esto?
Algo está fallando. Lo primero que podría pensar cualquiera es que se trata de una cuestión de aseguramiento de la calidad, entendimiento del DoD o falta de calidad técnica. Pero esa podría no ser la causa. Es necesario analizar el origen de estos bugs y quizá descubramos que se trata de un problema de entendimiento de los requisitos.
Posibles impactos si no se resuelve
Un equipo que normaliza la convivencia con una alta ratio de errores puede sufrir algunos efectos negativos claros:
Posible solución
Si analizamos el origen de los bugs, quizá encontremos causas subyacentes interesantes que van más allá de la focalización en capacidades técnicas. Tal vez descubramos que el equipo sufre cambios de requisitos durante el Sprint que afectan a la estabilidad de los objetivos inicialmente comprometidos. En ese caso, la solución consistiría en asegurar que el Product Backlog tenga un nivel de refinamiento adecuado.
Cómo hemos visto de forma más detallada en No busques equipos rápidos, construye equipos efectivos, en entornos iterativos, cada incremento de producto debería aportar algún tipo de valor a sus destinatarios. Este valor no siempre son incrementos de producto, pueden ser aprendizajes, validación de hipótesis o reducción de incertidumbres.
Cuando los incrementos no se utilizan ni se validan, se pierde una de las principales fortalezas de los ciclos iterativos: la capacidad de recibir feedback de forma continua. Sin este feedback, aumenta el riesgo de construir soluciones que no responden a necesidades reales de los usuarios.
Por este motivo, es útil distinguir entre output (lo que se construye) y outcome (el impacto que genera). Un equipo puede tener mucho output y, sin embargo, poco impacto real.
La satisfacción de las personas implicadas en el producto es un indicador relevante de sostenibilidad y de efectividad para el equipo y para la consecución del producto. Un sistema que genera frustración, aunque entregue resultados, tiende a perder efectividad con el tiempo.
La satisfacción puede observarse desde dos perspectivas complementarias: la de los stakeholders y la del equipo.
La satisfacción de los stakeholders está relacionada con la percepción de valor que puedan tener en cada momento, la confianza en el equipo y la capacidad de respuesta ante necesidades cambiantes. Esta percepción puede recogerse mediante feedback periódico, encuestas o conversaciones con personas clave.
La satisfacción del equipo está vinculada a su capacidad de mantener un ritmo de trabajo estable, así como a la claridad de los objetivos que recibe y la percepción del impacto de su trabajo. Los equipos con baja satisfacción suelen ver reducida su capacidad de rendimiento con el tiempo.
Las ceremonias ágiles, como la Sprint Review o la Sprint Retrospective, pueden aportar señales tangibles sobre esta satisfacción, pero no sustituyen herramientas o tácticas concretas para llevar a cabo esta evaluación. Ya que el valor principal de estas reuniones es facilitar conversaciones abiertas y detectar tendencias, y no someter a evaluación a las personas.
La evaluación de la satisfacción es un factor relevante en la mejora de la eficiencia de los equipos. La satisfacción incorpora una visión humana y relacional en el trabajo del equipo y en las comunicaciones.
Medir la eficacia tiene sentido cuando ayuda a tomar mejores decisiones. La medición no debería convertirse en un fin en sí mismo. Las métricas, las evaluaciones y las herramientas son medios para lograr equipos cohesionados, comunicaciones más valiosas y mejores productos.
Trabajar con estas métricas tiene como objetivo iniciar conversaciones para la búsqueda activa de la mejora, y no la simple recopilación de información para alimentar un cuadro de mando o auditar equipos. Convirtamos esta información en catalizadores que potencien una actitud de colaboración y entendimiento mutuo entre equipos y organización.
En el artículo No busques equipos rápidos, construye equipos efectivos, mostramos ejemplos prácticos de cómo, incluso con baja tecnología, podemos extraer información muy valiosa que permite guiar al equipo y a la organización en el camino hacia la efectividad.
En definitiva, un equipo efectivo es aquel que genera valor real de manera sostenible en el tiempo. Este es, en el fondo, el objetivo de la agilidad. Un buen producto se construye con buenos equipos; y buenos equipos pueden existir donde la orientación al valor y la sostenibilidad importan más que la velocidad.
![calaix[À]gil.com](/img/logo.png){kind=logo}
