Mejorar la eficiencia del tiempo de entrega para producir más producto en menos tiempo puede ser una buena alternativa en algunos escenarios durante el desarrollo de un producto, pero no necesariamente lo es en otros.
Pongamos que en un caso una empresa decide que debe aumentar la cantidad de funcionalidades desarrollados y entregados a los clientes en un período de tiempo, por decir un Sprint. La empresa está convencida que entregar más rápido y en menos tiempo le ayudará a mejorar su ventaja competitiva en el mercado. ¿Siempre será cierto esto? Definitivamente no siempre. Si el cliente está descontento con el producto que recibe, o si el producto tiene baja calidad por mencionar algunos casos entonces ese incremento de eficiencia puede generar o agravar situaciones que reduzcan el valor entregado a los clientes y el impacto negativo en la organización.
Algunas empresas definen objetivos a nivel de los equipos Scrum de eficiencia como por ejemplo el tiempo promedio de entrega (Cycle Time), que implican reducir el tiempo para entregar las funcionalidades y llevar a una aparente mejora de eficiencia, pero sin foco en maximizar el valor entregado a los clientes. Estas situaciones que suceden algunas veces deben ser evitadas empezando a medir a partir de los resultados o valor entregados a los clientes (Outcome) y en base a lo que se requiera adaptar las salidas (Output) necesarias.
Scrum es un marco para maximizar la entrega de valor que puede ser beneficiada por una mejora de la eficiencia del flujo para lograrlo, pero no necesariamente una mejora de eficiencia de flujo va a mejorar la entrega de valor, podría perjudicar este propósito en ciertas situaciones.
Un marco para evitar estas situaciones no deseadas al definir métricas puede ser la Gestión basada en evidencia de Scrum.org: https://www.scrum.org/resources/evidence-based-management-guide