kanban

Cómo elegir un buen WIP Limit

El agilismo es una mentalidad, una manera de entender el desarrollo de software que cuando te sumerges te va salpicando poco a poco en muchos aspectos de la vida.

Cuando comenzaba en esto de las formaciones uno de los principios ágiles por los que pasaba rápidamente por encima era:

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.”

Cuando estuve ayudando a nuestros amigos de Product Hackers me tocó ponerme el gorro de Product Owner y este principio al que no le daba mucha importancia… se convirtió en mi preferido. Sólo en el momento en el que todas las piezas encajaron a nivel equipo, empresa, cliente, etc… y conseguimos un entorno de desarrollo sostenible y constante, empezamos a entregar valor de verdad y satisfacer las necesidades prioritarias de nuestros clientes una y otra vez creando una relación de confianza que nos permitió alcanzar grandes éxitos.

Wip limit: Creando el espacio

Una vez me hicieron la pregunta: “Si tenemos una capacidad máxima de delivery, ¿cómo que no limitamos la capacidad de entrada?”

Más o menos me quedé así:

Y es que…. ¿sirve de algo meter más trabajo del que va a salir en un sistema? Si tengo una depuradora de agua en mi piscina… ¿le intentaría meter más agua de la que es capaz de depurar para intentar depurar más? Si lo que quiero es pagar una gran factura de reparación y una mirada incrédula de un técnico de depuradora… entonces puede que sí.

Y es que limitar el WIP es precisamente lo que nos permite que nuestro sistema sea estable y constante en el tiempo. Es como una tubería donde solo entra caudal si sale.

WIP limit: La palanca magica

Hubo un señor que demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. Ahora estaréis pensando…¿y por qué me cuestas esta gran anécdota Nacho? Pues porque este señor se llamaba Little, y esta es la ley de Little y es la base de Kanban:

Como vemos, el WIP es la relación entre el lead time y el throughput rate o delivery rate. También podemos ver como afecta el WIP al lead time mirando un CFD (Cumulative Flow Diagram):

¿Cómo elegir mi WIP Limit?

La relación entre cuanto menos WIP menos lead time está clara con la ley de little o el CFD. Así que alguien puede pensar… ¡pues pongo 1 de WIP limit! Eso nos deja la paradoja del One piece flow dónde te aseguras que cuando una tarea entra en el sistema sale muy rápido, pero tu delivery rate se verá afectado y será muy bajo. ¿Esto es malo? ¿esto es bueno? Pues ni bueno… ni malo… en algunos entornos necesitarán un tiempo de respuesta muy rápido y no les importará tanto la tasa de entrega y en otros entornos necesitarán un equilibrio mayor.

En una de mis vidas pasadas colaboraba con un cliente muy tradicional dónde había una pequeña galia trabajando con Kanban y funcionando muy bien. Ellos querían poner en producción al menos una vez a la semana. Pero esta empresa solo permitía subir una vez al mes. En esta situación…. ¿un lead time de 1 o 2 días me ayuda? ¿O puedo pensar en abrir un poco el WIP, aumentar un poco el lead time, pero subir el delivery rate? La capacidad de absorción de nuestros clientes es un factor a tener en cuenta también.

Creo que este vídeo explica muy bien como puede ser una búsqueda de el WIP deseado (Nota: en el vídeo se habla de cycle time que es el tiempo que está la tarea desarrollándose. El Lead Time es el tiempo desde que me comprometo hasta que lo entrego. Como es de suponer, están estrechamente relacionados)

En definitiva, hay que encontrar un equilibrio entre el Lead Time y el Delivery Rate.

¿Cómo elijo mi primer WIP limit?

¿Cómo elijo ese primer WIP limit que mediré, inspeccionaré y adaptaré si aún no tengo métricas?. El primer WIP limit habrá que elegirlo según la experiencia de los miembros del equipo o con consejo externo. Lo importante es tener una mentalidad empírica para inspeccionar y adaptar así que tampoco me volvería loco eligiéndolo.

Una frase que a mi me sirvió: “El WIP limit debe doler”. Es una restricción. Muchas veces los equipos tienen a pensar… si somos 4… y cada uno puede con 2 o 3 cosas a la vez… ¡pues pongamos 10! Como ya he dicho antes este número no está ni bien ni mal. Habrá que medir, inspeccionar y adaptar si hace falta. Pero una primera elección que nos duela suele resultar más acertada la mayoría de las veces. Como probar uno por persona en todo el sistema. Pero como vimos antes, cada entorno es un mundo y persigue diferentes métricas.

¿Qué pasa si cambio el WIP limit?

Imaginemos que quieres bajar el Lead Time porque quieres ganar predictibilidad y poder asegurar un SLA más bajo. En ese momento decidís bajar el WIP limit. Ahora te tocará esperar a que el sistema se vacíe para ver como funciona. Es como si tienes una cisterna de 5 litros y la cambias a una de 3. No podrás ver como se comporta el nuevo sistema hasta que se vacíe y se llene de nuevo. Es un proceso que pasará de forma natural y no requiere ningún esfuerzo extra que no sea respetar vuestras reglas y paciencia.

Conclusiones

Limitar el WIP es un arma muy poderosa para crear un entorno sostenible. Siempre es difícil elegir el primer WIP, pero hay que acordarse de que:

Se puede cambiar en cualquier momento. Siempre que se esté persiguiendo la mejora del sistema y no una auto-trampa para eliminar una restricción que nos molesta.
Hay que tener en cuenta la capacidad de absorción de nuestros clientes
Es una restricción y como tal, la primera vez que lo estipulamos, es buena señal si nos duele.
Hay que mirar (al menos) nuestras métricas de Lead Time y de Throughput para ir equilibrando entre ellas cambiando nuestro WIP si fuera necesario.
Una vez cambiado el WIP Limit, el impacto no es inmediato.

Simula un flujo de Kanban con esta herramienta

En ocasiones es complicado explicar cuales son los beneficios de enfocarse en la optimización de flujo en lugar de la optimización de recursos, tal y como vimos la semana pasada en el artículo sobre el mito de la eficiencia. Aunque la teoría diga que a más enfoque en eficiencia de flujo, más valor, en las organizaciones modernas es difícil entender que alguien pueda estar simplemente parado, sin hacer nada, esperando a que le llegue trabajo. Es ineficiente.

A principios del 2017, también escribí sobre como la obsesión por la eficiencia está matando a las organizaciones de desarrollo de Software. Como me dijo un jefe de compras de IT de una gran compañía, su mayor pesadilla es estar contratando recursos que no necesita.

Sin embargo, este miedo es completamente absurdo. Dada la situación del desarrollo de Software y su complejidad, es completamente imposible optimizar todos los elementos del sistema. Intentarlo sólo lleva a la frustración y a una capacidad de entrega y de adaptación al mercado cada vez menor.

Hace unos días descubrí una herramienta de Gaslight que te permite simular precisamente esto. A igualdad de trabajo, ¿Que diferencia supone el enfocarnos en intentar tener todos nuestros recursos ocupados en lugar de simplemente dejar que se enfoquen en terminar trabajo lo más rápido posible?

En mis experimentos, he llegado a ver como la diferencia en lead time usando el doble de trabajadores para un mismo backlog ha supuesto una mejora de lead time de apenas el 5%. Cuando trabajamos en un modo en el que tenemos que esperar a tener un número de cosas suficientemente grande para desarrollar o poner en producción, nuestro lead time puede llegar a triplicarse.

Esta herramienta es muy fácil de usar. Pulsa Start para comenzar la simulación. Puedes seleccionar si quieres trabajar en lotes y el número de trabajadores que quieres en cada uno de los fases de trabajo. Además puedes ajustar el tamaño del WIP en las colas. Ofrece estadísticas muy detalladas.

Pulsa aquí para acceder a la herramienta.

El mito de la eficiencia

Hace unos meses, en un esfuerzo por reducir mi altísima carga de trabajo, contraté a una empresa de Granada para llevar la gestión del Marketing Online de los cursos públicos. Nada muy sofisticado, apenas consistía en llevar campañas de Google Adwords, Facebook, la gestión de las publicaciones en redes sociales y un rediseño del material y la web. Mi principal problema era de tiempo, no de conocimiento. Para mi, es mejor externalizar todo lo que no añade directamente valor a las formaciones y centrarme en mejorar su calidad.

Saqué dos horas de mi agenda para sentarme a hablar con ellos y explicarles cuales eran los detalles y la problemática que tengo. Sabía que tocaba hacer muchos deberes y podía aprovechar las dos semanas siguientes para trabajar en lo que hiciera falta. Tres semanas después, contactaron por primera vez conmigo después de nuestra reunión para enviarme un presupuesto. Había perdido mi ventana de oportunidad.

A pesar de todo, intenté darle salida y buscar tiempos antes de las 8 de la mañana para hacer reuniones telefónicas y darles lo que necesitaran. Todo se encasquilló en torno al diseño de unos banners, que en un principio estaban presupuestados pero luego no lo estaban. Les dije que si, que necesitaba avanzar, pero la discusión siguió en torno a si serían 90€ o 120€ más por hacer los banners. Me da igual, les dije. Necesito sacar esto adelante.

Siete semanas después de sentarme por primera vez, por fin pudimos darle salida a la primera campaña en Adwords. No había banners y del resto de cosas que quería hacer ni siquiera tenía un presupuesto. La gota que colmó el vaso fue cuando descubrí que pretendían cobrarme sus servicios por adelantado. Unos servicios que, por lo que había visto hasta ahora, eran increíblemente ineficientes. Desde el punto de vista del flujo.

Cuando les comuniqué que no pagaría por adelantado más que lo que estaba estipulado en el contrato, la persona del departamento de Publicidad me remitió al departamento de Administración, que a su vez me dijo que tendría que remitirme al departamento de gerencia. ¿Sabes cuantos empleados tiene esta empresa, incluidos los socios? 11. Entre solo 11 personas habían creado un entramado de departamentos y de colas de espera que serían el deleite de cualquier ejecutivo de un call-center de Telefónica.

Eficiencia de recursos y eficiencia de flujo

Desde el punto de vista de esta pequeña compañía, probablemente tienen un entramado eficiente. Alguien que se encarga de comercial, algunas personas lo hacen de publicidad, hay un departamento de administración. Todos funcionan como silos perfectos que se comunican entre ellos. Están equivocados. La eficiencia matará su compañía.

Es la manera perfecta de maximizar el número de horas que una persona está ocupada. De identificar si hay una sobrecarga de trabajo en un área determinada. No contratan más gente hasta que el sistema está al borde del colapso.

Es eficiencia de recursos.

Los recursos son limitados y el objetivo es maximizar su eficiencia introduciendo nuevos recursos sólamente cuando es completamente necesario.

El problema reside en que esta eficiencia de recursos no tiene en cuenta la satisfacción del cliente. Yo, como cliente que planea invertir miles de euros al mes en sus servicios, espero una atención rápida y deliciosa.

Cualquier compañía digital entiende que lo importante no es cuan eficientes seamos, sino la velocidad de adaptarnos a las necesidades del cliente. En otra compañía de similar tamaño, me reuní directamente con la persona que se encarga de la publicidad, que además es el único punto de contacto para mi, como prospecto o como cliente. En un par de horas tenía un presupuesto y el tiempo para tener la campaña online era de un par de días.

Este enfoque se llama eficiencia del flujo.

Aquí, lo importante no es utilizar todas nuestras horas de forma óptima, sino que el tiempo de espera sea el mínimo, mientras que la densidad del valor añadido sea máxima.

Si contamos con que el tiempo de creación de valor añadido: Reunión, definición, alta de campañas, facturación y cobro son 15 horas en ambos casos, la eficiencia de la primera compañía es de apenas un 1.2%, mientras que en la segunda compañía es del 20.8%.

Como se puede ver, lo importante no es optimizar la eficiencia de los subprocesos, sino la experiencia global.

Cada vez que introducimos una optimización en uno de esos subprocesos, reducimos la eficiencia de flujo del total de la experiencia de cliente.

La base de Lean

Esta diferencia entre eficiencia de recursos y eficiencia de flujo es la base de Lean, un proceso que situó a la Toyota de la posguerra como el mayor fabricante de automóviles del mundo, por encima de compañías americanas y europeas con un porcentaje de optimización de recursos mucho mayor.

Esta es también la base de la transformación digital, en la que prima la velocidad de respuesta al consumidor que la capacidad de optimizarnos internamente.

10 herramientas para una gestión ágil de Producto con Scrum y Kanban

Una vez que tu organización ha empezado a usar Scrum, Kanban o ambos para desarrollar sus productos, es normal que surja le necesidad de plantearse utilizar una herramienta digital para la gestión del Product Backlog y del flujo de trabajo. En este post veremos unas cuantas.

En el mercado existen muchas opciones para gestionar el desarrollo de producto usando Scrum y Kanban. Aunque casi siempre la necesidad de una herramienta se justifica, es importante descubrir y usar una que realmente se adecue a vuestras necesidades.

¿Necesitamos una herramienta? ¿Si es así, cual?

Muchos equipos toman apresuradamente la decisión de utilizar una herramienta para la gestión de su flujo de trabajo sin ni siquiera tener en cuenta lo que necesitan. Esto desemboca en situaciones en las que se elige una herramienta extremadamente complicada que hace todo el trabajo mucho más difícil.

Ten en cuenta que una herramienta puede introducir complejidades adicionales debido a el exceso o la falta de características para vuestro producto, y que la mayoría de las conocidas en el mercado requieren de bastante tiempo de configuración y adaptación a vuestro proceso, para que no os fuercen a cambiarlo.

Las primeras herramientas que muchos equipos utilizan son una hoja de excel o Post-its. Esto normalmente es suficiente para los primeros Sprints. Sólo recomiendo saltar a otro producto en caso de que las necesidades sean muy evidentes.

Mi top 10 de gestores de proyectos para Scrum y Kanban

Las más populares y corporativas:

Atlassian JIRA

Esta herramienta se enfoca en ofrecer un stack completo de Product y Project Management, desde la gestión de Portfolio y Budgeting hasta integración continua, pasando por un wiki y un sistema de Help Desk. Lo mejor es la integración de la suite. Lo peor es el esfuerzo de configurarla y adaptarla. La versión cloud empieza desde 10$/mes por usuario.

VersionOne

A raíz de una fuerte colaboración con Scaled Agile Inc, VersionOne ha ido ganando popularidad durante los últimos años. Ofrece un stack similar al de Atlassian, quizás más enfocado en el framework SAFe, carece de herramientas de integración continua aunque tiene integraciones muy interesantes. La version coludo para un equipo es gratuita. Para 20 personas es 175$/mes

CA Agile Solutions

Anteriormente conocida como Rally, fue la herramienta de referencia para corporaciones durante muchos años. Al igual que JIRA, se integra con la suite de soluciones de CA. El precio es gratuito durante los primeros días

Orientadas a Scrum

TargetProcess

Esta herramienta que lleva seis años en el mercado, se enfoca en el desarrollo de Producto más que de Proyectos, desde el Story Mapping hasta el incremento. TargetProcess se encuentra a medio camino entre Active Collab y Pivotal Tracker, permitiendo a la vez una gestión clásica y ágil de los proyectos.

Active Collab

Otro de los clásicos. Éste se enfoca más en Project Management tradicional. Te permite hacer tracking de horas y de proyectos con algunos módulos más orientados a la planificación ágil de producto. Su principal objetivo es competir con Basecamp, la herramienta más establecida en gestión de proyectos tradicional.

Pivotal Tracker

Esta herramienta está diseñada por Pivotal Labs, una compañía de desarrollo ágil de software que da servicio a clientes.

Pivotal ha sido durante años un referente en cuanto a diseño y usabilidad, y esa ha sido su mejor baza contra herramientas mas grandes.

Taiga

Taiga es un proyecto Español que lleva poco tiempo en el mercado pero es muy prometedor. Taiga incorpora una gestión simple de Product Backlog Ítems (aunque ellos les llaman historias de usuario), un tablero para los equipos y permiten hacer planificación de producto dentro de la propia herramienta. Para equipos pequeños es gratis.

Específicas para Kanban

Swift Kanban

Esta es la referencia en el mundo Kanban, incluye tanto el desarrollo con Kanban como la gestión a través de Enterprise Services Planning. Swift Kanban colabora activamente con LeanKanban en el desarrollo de ESP y métricas avanzadas de flujo para corporaciones.

Kanbanize

Esta pequeña empresa Europea se ha ganado un hueco entre aquellos equipos que se enfocan en una mejora del Flow Efficiency. Lo mejor es la capacidad de definir correctamente las columnas de un workflow en Kanban y poder visualizar métricas de un servicio.

Trello

Trello es tremendamente popular aunque no es más que un tablero virtual de Post-its®, que permite hacer un seguimiento por columnas y tiene plugins que permiten hacer una ciertas integración de métricas. No es la más aconsejable desde mi punto de vista.

Precauciones a la hora de elegir una buena herramienta

Es normal que un equipo o la organización tienda a buscar una solución para todo que cubra todas las necesidades. Product Backlog. Portfolio Management. Integración continua ¿Por qué no?. Conteo de horas, también. Wiki, por supuesto.

Al final lo que ocurre es que la herramienta elegida es tan grande que no se le da apenas uso. Cuando hablamos de herramientas pensadas para el mundo corporativo, como pueden ser JIRA o VersionOne, los equipos tienen que terminar adaptándose a los flujos de trabajo de la herramientas en lugar de la herramienta a la suya.

Personas e interacciones por encima de procesos y herramientas

Agile Manifesto

Así, muchas organizaciones terminan haciendo el Scrum que les dice su herramienta en lugar de hacer Scrum bien y salvar los problemas de la herramienta, lo cual va en contra de los principios ágiles escritos en el Agile Manifesto.

Eso provoca problemas de toda índole, siendo el más importante el que la organización tiene que funcionar como la herramienta y no al revés. Si pudieras decirme las diferencias con tu competidor ¿Cuantas te vienen a la mente?. Si sois tan distintos, por qué queréis utilizar el mismo proceso.

Inspeccionar y adaptar

El truco para elegir una herramienta es no hacer grandes apuestas y dar la oportunidad de que los equipos y la organización tengan la oportunidad de probar distintas cosas y adaptarse. No puede ser decisión de la dirección o del Scrum Master, sino que tiene que ser un proceso de aprendizaje.

Lamentablemente, muchos equipos ni siquiera tienen la oportunidad de saber qué es Scrum antes de que se les imponga una herramienta, que en ocasiones presenta más impedimentos de los que resuelve.

Un software nunca te hará ágil, sino todo lo contrario.

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.

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.