• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

valor

Cómo la eficiencia hundió tu empresa

Hace unos días di un curso para una compañía muy conocida. Casi al final del segundo día, uno de los asistentes, Manager, me dijo: ¿Entonces cómo mido la eficiencia de la gente? ¿La eficiencia de la gente? Sí, claro… si trabajan o si no.

Estaba anonadado. Casi no sabía qué decir.

Justo en ese momento de la clase hablábamos de medir la productividad a través del throughput (ritmo de entrega) y la variabilidad de cada uno de los ítems entregados. Una alternativa mucho mejor al uso de Story Points. Tan distinta como comparar la homeopatía con un tratamiento médico de doble ciego.

Un ejemplo: Si un equipo entrega de media 10 Product Backlog Items y otro entrega cinco, eso no nos da mucha información. Los PBIs pueden ser más grandes o más pequeños, o el equipo tener distintas capacidades técnicas, el stack puede ser más o menos complicado y un sinfín de situaciones.

Pero si además de decir si un equipo entrega 10 o 5, lo acompaño con el número -medio- de días que tardan en entregar, entonces si tengo una métrica realista. Dos equipos, uno entregando 10 PBIs y otro entregando 5, que entregue en 20 y 10 días respectivamente, tendrán una productividad similar.

Pero esto no era suficiente.

La preocupación de este alumno era distinta. No le preocupaba el valor. No le preocupaba lo que se entregaba. Le preocupaba que su cliente viera a la gente -gente por la que paga- ocupada todo el día. Y claro, enfocándose en generar valor, es difícil que eso pase. Veamos por qué.

Eficiencia vs Valor

Hoy en día, las compañías deciden enfocarse en la eficiencia, y encuentran que los frameworks como Scrum o los métodos de Management como Kanban requieren de un salto de fe desde la eficiencia, entendida como todo el mundo debería de estar trabajando a toda velocidad, hacia el enfoque de valor.

Sin embargo, ¿qué es valor? Hace unas semanas, estuve con todos los Product Owners de una conocida startup en Barcelona. Juntos, llegamos a la conclusión de que su trabajo los había convertido en meros gestores de horas. Su misión era que los desarrolladores estén ocupados. Si la gente no trabaja ocho horas, entonces no son eficientes. Error.

Valor, en el negocio del desarrollo de Software, es llegar antes que los demás al mercado. Validar y seguir. Fallar y rectificar. Eso es la agilidad. Mientras no hacemos una release de Software al cliente, el valor que generamos es cero.

Cuando nos enfocamos en que todo el mundo esté ocupado, entonces tendemos a crear colas. Como en el desarrollo de Software por naturaleza las distintas tareas que podemos hacer tienen una alta variabilidad, entonces las colas tienden a crecer hasta el infinito. Que todo el mundo esté ocupado significa, inequívocamente, que nuestro ritmo de entrega tenderá a cero.

Conseguir una release supone ineficiencia. Sólo podríamos alcanzar un estado de alta ocupación y alta entrega si todas las tareas tuvieran exactamente la misma carga de trabajo. Lamentablemente, en el Software, debido a su naturaleza de crear siempre cosas nuevas, las cargas varían mucho.

La ley de los retornos disminuidos

Un 95% de las empresas trabajan totalmente ciegas a sus economías internas. Ni las entienden, ni saben que existen. Ni pueden ni saben cuantificar cuál es el coste de decidir hacer una nueva feature en lugar de invertir en mejorar la calidad técnica del producto.

Algunos desarrolladores de producto comprenden “algunas variables”, y por ejemplo te dirán que lo más importante es reducir el tiempo de desarrollo -cycle time-, pero no tienen ni idea de cuánto va a afectar al total del ciclo de vida del desarrollo de producto o a su beneficio.

¿Qué sentido tiene reducir el tiempo de proceso si al final estoy limitado por otras variables?

Esto es algo habitual en la gran corporación. Por ejemplo, los bancos están invirtiendo cantidades ingentes de dinero en mejorar sus procesos de desarrollo usando Scrum, Kanban, SAFe o Nexus. Sin embargo, para poder lanzar una aplicación a producción, siguen necesitando a un comité de cambios que apruebe la subida a producción. Este comité se reúne una vez cada tres meses, limitando toda la mejora obtenida mediante Scrum a cero. ¿Qué sentido tiene desarrollar de manera ágil si al final vamos a llegar al mercado al mismo tiempo que lo hacíamos antes?

Por otro lado, la única manera de comprender la importancia económica de las colas que creamos cuando nos enfocamos en que todo el mundo esté ocupado -eficiencia-, es cuantificar el coste de retraso -cost of delay- en los proyectos de desarrollo de producto. A pesar de eso, sólamente el 15% de los desarrolladores de producto conocen el cost of delay asociado con sus proyectos y productos.

Cost of Delay

El cost of delay tiene una fórmula simple: ¿Cuánto me cuesta si no entrego a tiempo? A tiempo no es la línea temporal que me he marcado en mi plan de proyecto, sino el momento en el que el mercado me lo demanda. ¿O acaso lanzarías una campaña de Navidad en Febrero?

Un detalle: Cuando me refiero a desarrolladores de producto, no me refiero a ingenieros de software, ni programadores. Me refiero a todos aquellos implicados en el desarrollo de producto, desde el Product Manager hacia abajo, todos deben ser conscientes de estos elementos.

Prosigamos.

Así, estos tipos de Producto, se enfocan en variables proxy como la utilización (¿Trabajamos al 80% o al 90%?; ¿Está todo el mundo ocupado?) o la reducción del cycle time (Tenemos que tardar menos en desarrollar esta nueva feature) que en llegar antes el mercado con un MVP. Pero que todo el mundo siga muy ocupado.

Este vídeo lo explica muy bien:

Al final, esto se llama trabajo por lotes. ¿Te suena? Sí, esta es la base de PMBOK o Prince2. Trabaja por lotes que así serás más eficiente. Sin tener en cuenta que los lotes retrasan exponencialmente la salida al mercado y nos suponen una pérdida económica.

Métricas circunstanciales vs Métricas directas

El peligro de enfocarse en estas variables circunstanciales es que éstas interactúan unas con otras.

Mejorar la utilización de la capacidad de trabajo disponible tiene el efecto beneficioso de mejorar la eficiencia y el efecto negativo de incrementar el cycle time.

Para entender el impacto neto, hay que comprobar ambos efectos. Para hacerlo, hay que expresar los cambios de todas las variables proxy en la misma unidad. Esta unidad es life-cycle profit impact, que es la última medida de éxito en el desarrollo de productos. Si quieres leer más sobre esto, puedes hacerlo en el libro Lean Product Development Flow de Don Reinertsen.

Métricas ágiles fundamentales (II)

Después del primer post sobre métricas ágiles, donde se exponía como medir conceptos como el Average Customer Lead Time, Cycle Time y WIP a través de su relación con la Ley de Little, quedó pendiente una explicación de métricas de producto a nivel circunstancial y cómo agregarlas a alto nivel

El problema de la Pizza

Imaginemos que nos asociamos con nuestros mejores amigos para abrir una Pizzeria. Por supuesto, para poder elaborar un plan de negocio y seguirlo, necesitaremos de una serie de métricas que nos indiquen como va el negocio. La más importante son los ingresos y los beneficios. Pero más allá, ¿Que podríamos medir?

Podemos imaginarnos muchas cosas que nuestro negocio nos permite medir, como el número de Pizzas entregadas en cada viaje en moto, las pizzas más rentables, el número de repartidores, el número de reclamaciones, el valor medio de un pedido, etc…

Métricas directas vs Métricas circunstanciales

En realidad, todas estas métricas se pueden agrupar en dos tipos de métricas: directas y circunstanciales. Las directas son las que tienen una aplicación directa sobre el valor que generamos, mientras que las circunstanciales nos dan información que debe ser agregada antes de poder usarla para obtener valor.

En el caso de nuestra Pizzeria, el número de pedidos entregados por viaje en moto de nuestro repartidor podría ser una buena métrica, hasta que nos preguntamos: ¿Realmente son rentables estos viajes? Si estamos regalanado nuestras Pizzas por debajo de precio, cada viaje en moto no sólo no agrega valor a nuestro negocio sino que genera valor negativo: Nos cuesta dinero.

En una gran Telco, el Management de area decidió implementar un bonus para aquellos que encontraran más bugs dentro de la aplicación. El resultado fue espectacular, el número de bugs reportados se incrementó en más del 100%. Sin embargo, un análisis posterior reveló que la mayoría de estos bugs eran descripciones similares o iguales a problemas ya conocidos dentro de la aplicación

¿Cómo medimos entonces el valor?

En primer lugar, hay que tener claro que significa valor para la organización. Esta es simple: Valor es la capacidad de generar beneficio económico. Para organizaciones sin ánimo de lucro es: Capacidad de generar un beneficio para la sociedad. Ojo, beneficio económico o beneficio social no sólamnete son euros contantes y sonantes, sino que pueden incluir, por ejemplo, una mejora en la valoración de la compañía.

Una definición clara de valor es parte de una estrategia de negocio, apoyado en una visión y misión clara. Lamentablemente, muchas organizaciones no tienen claro estos puntos antes de lanzar nuevos productos o compañías al mercado.

Metricas circunstanciales -> Métricas directas

Volvamos al ejemplo de la Pizza. Si medir el número de pedidos por viaje no tiene sentido sin considerar el beneficio de cada pedido, ¿Cómo podemos transformar esas métricas circunstanciales en métricas directas? Mediante la agregación y el balanceo. En el caso de nuestra Pizzería, tendremos que buscar la manera de agregar diferentes métricas para obtener una que nos permita saber si somos rentables o no.

Métricas directas en el desarrollo de Software

Cuando desarrollamos un producto de Software nos encontramos en una situación aún más complicada. No sabemos que parte de nuestro Software y de la inversión que hacemos influye más en la generación de valor para nuestro producto o compañía.

No he conocido a ninguna compañía que mida el efecto que un training de Scrum como el que yo mismo hago en su creación de valor. O de una Hackaton. La mayoría lo hacen siguiendo una filosofía de Cargo Cult. Lo hacen porque otros lo hacen. No son capaces de relacionarlo con su propia creación de valor.

La mayoría de las métricas que podemos obtener en el desarrollo de Software son puramente circunstanciales.

Aquellas métricas más directas no sirven para ajustar la estrategia. Sin embargo, podemos usar las métricas cricunstanciales para medir directamente el valor utilizando el framework de Evidence Based-Management.

Evidence-based Management

EBMgt surge por parte de Scrum.org como una respuesta a la pobre medición y seguimiento que hacen las organizaciones que usan Scrum de su valor. La idea es prestada de la Medicina Basada en la Evidencia (MBE). Para poder tomar una decisión, es necesario tener pruebas que den soporte a esa decisión, evitando las decisiones basadas en el conocimiento común o las corazonadas.

Evidence-based Management propone una serie de tres métricas directas desagregadas en 12 métricas circunstanciales obtenidas de la información de la compañía: Valor actual, Time to Market y Capacidad de innovación.

Evidence Based Management metrics

Valor actual

El valor actual se obtiene de la agregacion de cuatro métricas:

  • Ingresos por empleado: Se obtiene midiendo los ingresos brutos/número de empleados. Nos indica una rentabilidad bruta por empleado.
  • Satisfacción de los empleados: Porcentaje de empleados que se califican a sí mismos como “Satisfechos” o “Muy satisfechos”.
  • Satisfacción de los clientes: % de clientes que se consideran “satisfechos” o “muy satisfechos”. Se puede sustituir por el Net Promoter Score.
  • Product cost Ratio: Coste de la inversión de mejoras (training, herramientas, espacios de trabajo) comparado con el cambio en ingresos brutos

Si introducimos mejoras en el proceso de despliegue fomentando DevOps y formamos al equipo para que use

Scrum pero nuestros ingresos brutos se mantienen o descienden, entonces sabremos que no estamos enfocandonos en el área de la compañía que requiere atención. Al igual que la medicina, hay que dar un tiempo para ver como evoluciona el paciente antes de tomar otras acciones.

Time to Market

El tiempo que tardamos en llegar al mercado es una métrica fundamental de negocio, ya que nos permite medir el coste de oportunidad perdido usando el Cost of Delay correspondiente a un producto o una característica existente de nuestro producto. En EBMgt lo medimos en base a tres métricas circunstanciales:

  • Frecuencia de Release: El tiempo que pasa entre release funcionales, no de corrección de bugs o mantenimiento.
  • Estabilización de Release: Tiempo que pasa entre que se completa el código y se lanza realmente a los clientes.
  • Cycle time: El tiempo que necesitamos para entregar una pequeña funcionalidad nueva (no bugs) al cliente

Es importante reseñar que, si al igual que en el caso anterior, fomentamos DevOps para reducir nuestro Time to Market, si tenemos gran deuda técnica, no haremos más que pagar esa deuda técnica y nuestros valores de esta métrica permaneceran estáticos. Para eso tenemos la siguiente.

Capacidad de innovación

Nuestra última métrica directa es una medición de nuestra capacidad para innovar. Para ello utilizamos cinco métricas circunstaciales que nos daran una idea de cómo de bien lo hacemos en este área.

  • Versión instalada: % de clientes en la última versión comparado con el número de versiones mantenidas
  • Índice de uso: % de funcionalidades usadas más del 50% del tiempo
  • Ratio de innovación: % del presupuesto dedicado a desarrollar nuevas funcionalidades. A mayor porcentaje, menor Coste de propiedad (TCO).
  • Densidad de defectos: % de cambio de bugs en producción desde la última medición
  • Product Cost Ratio: Coste total de gastos, incluyendo gastos operacionales/ingresos brutos.

Agregando todas estas métricas podemos tener una idea excelente de cual es nuestra capacidad de innovar. Así, una organización con una gran deuda técnica verá reflejada en esta métrica su deuda técnica, que le impide innovar.

La idea de todas estas métricas, que pueden cambiar de una compañía a otra, es proporcionar un marco para la toma de decisiones, no de ser decisiones en sí mismas. Teniendo una medida continua de estas métricas, que es fácil de obtener mediante los sistemas de información que tienen las organizaciones hoy en día, tendremos un marco que nos permitirá actuar con eficiencia sobre el sistema, independientemente de sus ineficiencias locales.

Leer más

Si quieres leer más, puedes descargar el whitepaper de Evidence Based Management.

Si quieres aprender más sobre como generar y medir valor en tu organización, te recomiendo le eches un vistazo a nuestros próximos cursos de Product Owner en Madrid y Barcelona.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad