Recientemente, en una conversación con algunos compañeros surgió una pregunta que suele ser habitual en el mundo de la agilidad. ¿Cómo podemos medir la eficiencia de nuestro equipo?
Rápidamente, la conversación se dirigió hacia el conocimiento de la velocidad del equipo. En ese momento comenté:
Pero la eficiencia no es solo una cuestión de velocidad, ¿no? Y es que antes de responder habría que entender bien qué significa que un equipo sea “eficiente”.
La eficacia está directamente relacionada con el logro de los objetivos establecidos. Una acción es eficaz cuando consigue el resultado esperado, independientemente de cómo se hayan utilizado los recursos disponibles.
En el ámbito empresarial, la eficacia pone el foco en el qué. Implica cumplir objetivos, alcanzar metas comerciales, entregar funcionalidades comprometidas o llegar a determinados hitos de negocio. Es un criterio claro y fácil de evaluar, porque se vincula directamente con resultados observables y medibles.
Este enfoque es útil para alinear equipos con objetivos concretos y focalizarlos en un objetivo claro. Sin embargo, centrarse exclusivamente en la eficacia puede invisibilizar aspectos relevantes como la sostenibilidad del esfuerzo, el aprovechamiento del talento o el uso racional de los recursos.
En entornos organizativos tradicionales, es habitual considerar que si se alcanzan los objetivos, el sistema funciona. Pero esta visión puede ocultar ineficiencias estructurales, costes ocultos o competencia por la asignación de recursos que pueden provocar problemas graves a medio plazo.
La eficacia se enfoca, por tanto, en maximizar los resultados; empleando para ello los recursos adecuados. Y priorizando en definitiva los resultados sobre la optimización de los recursos utilizados.
La eficiencia tiene que ver con el uso apropiado de los recursos disponibles. En proyectos, la primera limitación (o la más evidente) llega con el coste. Alguien decide que cierto producto tiene un techo de coste. Ya sea una licitación, una oferta comercial o cualquier otro tipo de cálculo previo. Pero también es habitual afrontar:
Cuando hablamos de limitaciones, sin embargo, no nos referimos a trabajar en la escasez, sino más bien a prestar atención a la relación entre coste y resultado. Aunque dispongas de recursos ilimitados, en eficiencia empleamos aquello que realmente es óptimo para el valor que pretendemos conseguir.
La eficiencia consiste en ser consciente de las herramientas de que disponemos y utilizarlas de la mejor forma posible para obtener los resultados deseados.
En entornos complejos e inciertos, típicos del desarrollo de producto en los tiempos actuales, donde las buenas prácticas y marcos ágiles tienen un encaje especial, alcanzar objetivos no siempre implica generar valor real. A menudo, para tratar de garantizar la evolución del producto, aspectos como el aprendizaje, el valor obtenido, el feedback continuo o la mitigación de incertidumbres tienen más repercusión sobre el futuro del producto que la entrega de funcionalidades.
En contextos de desarrollo de producto con agilidad, tanto la eficacia como la eficiencia solo tienen sentido si se relacionan con el valor generado.
En desarrollo de producto, no basta con alcanzar objetivos si eso se hace con un coste excesivo o con impacto negativo en la sostenibilidad del equipo. Tampoco es suficiente optimizar recursos si el resultado no genera valor útil para los usuarios.
¿Buscamos equipos rápidos? ¿O buscamos equipos que trabajen en un entorno en el que se pueda generar un impacto real y sostenible?
La efectividad integra lo mejor de la eficacia y de la eficiencia.
En entornos ágiles, la efectividad se manifiesta cuando los equipos son capaces de entregar valor de manera sostenida, con calidad, aprendizaje continuo y capacidad de adaptación. El objetivo real de los equipos no es ser eficientes ni eficaces, sino efectivos.
En la gestión de productos y proyectos es habitual utilizar la velocidad de entrega como indicador básico de rendimiento. Sin embargo, la velocidad por sí sola no describe la efectividad de un equipo ni la calidad del sistema de trabajo.
Un equipo puede entregar muy rápido y, al mismo tiempo, generar retrabajo, deuda técnica o funcionalidades de poco valor. Del mismo modo, un equipo puede avanzar a un ritmo moderado pero estable, entregando incrementos de gran calidad y con impacto real para los usuarios.
Por este motivo, la velocidad debería interpretarse como un indicador de capacidad (o ritmo de trabajo), y no como una medida directa de efectividad. Para obtener una visión más completa del rendimiento de un equipo, es recomendable incorporar otros parámetros interesantes, como por ejemplo:
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.
En este artículo no trataremos todas las dimensiones que introducimos aquí. Puedes encontrar todas las métricas definidas en el siguiente artículo: Equipos efectivos. Cómo evaluar la efectividad más allá de la velocidad.
Cuando se analiza la efectividad de un equipo, a menudo se pone el foco en el tiempo de construcción técnica (cycle time). Sin embargo, limitar el análisis solo a esta fase ofrece una visión parcial del problema. Hay mucho más previo a la construcción que determinará el éxito o fracaso de nuestros compromisos de construcción.
El cycle time mide el tiempo que transcurre desde que una tarea se inicia activamente hasta que se completa. Es un indicador útil para entender la capacidad de desarrollo y la fluidez del trabajo de los técnicos.
Ahora bien, antes de que una necesidad llegue a fase de construcción, suele pasar por procesos de descubrimiento, definición, validación y priorización. Estos procesos también consumen tiempo y recursos, e influyen directamente en el valor final que seremos capaces de entregar.
El lead time mide el tiempo total desde que se detecta o se formula una necesidad hasta que esta se entrega. Este indicador permite analizar el sistema de trabajo de forma global, más allá de la fase técnica y más allá del equipo de desarrollo.
Un lead time elevado puede retrasar la obtención de feedback, aumentar la incertidumbre e incrementar el riesgo de desalineación con las necesidades reales de los usuarios o del negocio.
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.
Descripción del problema
Imaginemos una funcionalidad que requiere dos semanas para su construcción, pero pasa dos meses en validaciones y priorizaciones antes de iniciarse.
¿Qué nos indica esto?
El problema no es la capacidad técnica del equipo, sino el tiempo que la necesidad pasa en espera dentro del sistema.
Posibles impactos si no se resuelve
Esto puede ser un desencadenante de efectos negativos importantes para el proyecto, como por ejemplo:
Posible solución
Visibilizar la situación. Estudiar mecanismos de validación menos jerárquicos. Aplicar tableros de trabajo para la preparación de estas tareas que hagan visible la situación de esta y del resto de tareas inmersas en este proceso. Limitar las tareas que están en proceso de validación (aplicar un WIP).
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. Se trata de un acuerdo explícito que garantiza un nivel mínimo de calidad compartido por el equipo y la organización. Algunos de estos criterios son:
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. De este modo, facilita que el equipo pueda trabajar de forma estable y teniendo en cuenta aspectos que van más allá de la pura construcción de nuevas funcionalidades.
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. El DoD también hace explícito qué significa que un trabajo esté realmente terminado, facilitando la transparencia entre el equipo y la organización. Esta claridad ayuda a alinear expectativas y a entender el nivel de calidad necesario para generar valor de forma sostenida.
Descripción del problema
Un equipo soporta presiones sobre su Cycle Time y, para ir más rápido, decide saltarse ciertas pruebas que tradicionalmente requieren mucho tiempo y esfuerzo, como pueden ser por ejemplo las pruebas de regresión.
Inmediatamente la organización percibe este aumento de velocidad. Todo hace pensar que el equipo ha mejorado notablemente en eficiencia. Pero, ¿es efectivo?
Pasado un tiempo se realiza un despliegue de una funcionalidad importante que genera un error crítico e inesperado.
¿Qué nos indica esto?
El aparente ahorro de tiempo inicial acaba repercutiendo en deuda técnica y fallos graves de estabilidad en el producto.
Posibles impactos si no se resuelve
El aparente ahorro de tiempo inicial acaba repercutiendo en deuda técnica y fallos graves de estabilidad en el producto.
Posible solución
El DoD es una pieza fundamental en el marco de trabajo. Es una garantía para un equipo enfocado en la calidad, y no solo en proporcionar producto rápidamente. Debemos explicar la importancia de esta herramienta en la efectividad del equipo. Y no solo en el equipo, sino en toda la organización. Este es un ejemplo de eficiencia aparente. Lo que buscamos en los equipos es la garantía de efectividad real.
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, aun así, poco impacto real.
No se trata solo de entregar producto per se, sino de validar si la dirección elegida en la evolución del producto genera valor real. Un equipo puede ser muy efectivo operativamente y, sin embargo, estar construyendo el producto equivocado. En la evaluación de la eficiencia de un equipo, puede ser útil observar indicadores relacionados con el valor obtenido, como por ejemplo:
Estos indicadores ayudan a entender si el esfuerzo invertido se traduce en valor realmente útil, y no solo en volumen de entregas.
Descripción del problema
Un equipo es capaz de entregar muchas nuevas funcionalidades, pero estas no tienen una coherencia adecuada con lo que los usuarios necesitan ahora. Los usuarios siguen pidiendo otras necesidades que no llegan.
¿Qué nos indica esto?
El equipo está generando outputs, lo que podría hacer pensar que es eficiente. Pero esos outputs no son necesariamente outcomes. El problema, por tanto, no es la capacidad del equipo, sino la deseable alineación con valor real.
Posibles impactos si no se resuelve
Esto puede desencadenar efectos negativos importantes para el proyecto, como por ejemplo:
Posible solución
Como Scrum Masters tenemos una conversación de valor con el Product Owner, con el fin de tomar conciencia de la importancia de un Product Backlog bien priorizado.
Com hemos visto al principio de este artículo, Para obtener una visión más completa del rendimiento de un equipo, es recomendable incorporar otros parámetros interesantes, como por ejemplo:
Puedes encontrar información en detalle de las métricas de las que no hemos hablado aquí en el siguiente enlace Equipos efectivos. Cómo evaluar la efectividad más allá de la velocidad.
Medir la eficacia tiene sentido cuando ayuda a tomar mejores decisiones. La medición no debería convertirse en un fin en sí mismo. La ley de Goodhart: “Cuando una medida se convierte en objetivo, deja de ser una buena medida”. Las métricas, las evaluaciones y las herramientas son medios para conseguir 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.
Por ejemplo, si tomamos el caso de la diferencia entre Lead Time y Cycle Time: Ya hemos visto en el ejemplo práctico que un Cycle Time corto no puede garantizar valor real y útil para los usuarios si este sufre un Lead Time excesivo. Una vez detectada esta problemática podemos hacer seguimiento de la evolución de estos dos indicadores a lo largo del tiempo, para evaluar si nuestras conversaciones y propuestas de solución son efectivas.
Ni siquiera necesitamos una herramienta tecnológica ni un cuadro de mando para hacer este seguimiento. Anotemos la fecha en la que se solicitaron algunas funcionalidades importantes, la fecha en la que se empezaron a construir y la fecha en la que se entregaron. Hagamos esto durante un tiempo y observemos si el tiempo de espera se reduce o no. Es decir, si el Lead Time se acerca al Cycle Time.
En cinco minutos y con post-its (o con una pequeña hoja de cálculo) puedes tener a tu alcance una herramienta potente. Y además será una herramienta que busca la mejora no solo en el entorno técnico, sino en toda la organización.
¿Cómo podemos hacer partícipe a la organización de esta alerta? La reunión de Retrospectiva podría ser el espacio ideal para lanzar una pregunta: “Hemos descubierto que el Lead Time es cuatro veces superior al Cycle Time. ¿Qué podemos hacer para reducir el tiempo de espera de las funcionalidades más críticas?”
Otro ejemplo: Cuando hemos hablado sobre la calidad del Product Backlog y la necesidad de asegurar su refinamiento, debemos conseguir que esto no se quede en un simple discurso. Podemos proponer, por ejemplo, que en la Sprint Planning, antes de empezar, pidamos al equipo que valore (por ejemplo del 1 al 5) la calidad de la información del Backlog de cada uno de los ítems que se tratarán en la planificación. Esto nos da información (subjetiva pero útil) sobre si nuestros esfuerzos de refinamiento van por buen camino o no.
En definitiva, un equipo efectivo es aquel que genera un impacto positivo en el producto 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}
