Mostrando entradas con la etiqueta Métricas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Métricas. Mostrar todas las entradas

sábado, 14 de junio de 2025

Portfolio Management: LVT vs KPI

 

KPIs: ¿El Retrovisor de tu Negocio? Conoce el Lean Value Tree: Tu GPS para el Futuro Impulsado por el Valor

En el apasionante viaje de gestionar un producto o un negocio, la información es poder. Un compañero me lo resumió de forma magistral: con los KPIs vemos el pasado y con herramientas como el Lean Value Tree planificamos el futuro. ¡Y tiene toda la razón!

Ambas herramientas son indispensables, pero cumplen funciones distintas, aunque complementarias, en la navegación empresarial. Pensemos en ellas como las herramientas de un coche:

KPIs: Mirando el Pasado para Entender el Presente

Un KPI (Key Performance Indicator) es un indicador y siempre será un valor medible, una métrica, que muestra cómo está el desempeño del negocio. Los KPIs sirven para una 'gestión basada en datos' del estado actual de tu empresa.

Por ejemplo, el KPI “Tasa de abandono de carrito” puede ser un KPI de ventas que te dice cuántos clientes inician una compra pero no la terminan. Este número, junto con otros, te da una foto de lo que ya sucedió o está sucediendo. Son como el retrovisor de tu coche: te muestran dónde estuviste y cómo te fue en el camino recorrido. Te permiten diagnosticar la salud actual de tu negocio y reaccionar a problemas ya presentes.

Lean Value Tree (LVT): Navegando Hacia un Futuro de Valor

Por otro lado, el Lean Value Tree, propuesto en el Modelo Operativo EDGE (Value-Driven Digital Transformation) de Jim Highsmith, es mucho más que una métrica; es una herramienta estratégica para una 'gestión orientada a objetivos y basada en el valor'.

El LVT es una visualización jerárquica que conecta la estrategia de alto nivel de tu organización (el "por qué" y los objetivos más ambiciosos) con las iniciativas y entregables concretos (el "qué" y el "cómo") que generarán valor. Se desglosa en niveles que van desde:

  • Visión: El destino final inspirador.
  • Grandes Objetivos (GOAL): Objetivos como resultados medibles y deseados para el cliente o el negocio.
  • Apuestas (BET): Sub-objetivos que funcionan como apuestas para traccionar Goals.
  • Iniciativas: Los grandes bloques de trabajo para lograr esos resultados.
  • Entregables/Features: Las piezas de producto específicas que componen las iniciativas.

El Lean Value Tree es como el GPS de tu coche: te muestra tu destino (la Visión), las diferentes rutas posibles para llegar (los Objetivos/GOALs), y los giros específicos que debes tomar (BET) y las acciones que debe hacer el conductor (las Iniciativas y Entregables) para alcanzarlo, siempre con el foco en la creación continua de valor. Determina cuáles son los objetivos y resultados que deben ser logrados en el futuro.

La Diferencia Clave: ¿Pasado o Futuro?

La distinción es clara:

  • Con los KPIs vemos el pasado y el presente: Nos dan un diagnóstico sobre el rendimiento de las operaciones que ya sucedieron o que están sucediendo. Son herramientas de monitoreo y diagnóstico.
  • Con el Lean Value Tree planificamos y construimos el futuro: Nos proporciona una hoja de ruta estratégica y flexible para alcanzar objetivos ambiciosos, siempre impulsados por el valor. Es una herramienta de dirección y acción.

Complementariedad, No Exclusión

Es fundamental entender que los KPIs no son excluyentes del Lean Value Tree, sino que lo complementan y lo incluyen para proyectar y medir los resultados clave las medidas de éxito (MOS). Para definir medidas de éxito (MOS) necesitamos usar métricas e indicadores como los KPI, para definir explícitamente metas en función de líneas base.

El Lean Value Tree te da la dirección estratégica y te ayuda a priorizar el trabajo que tienes que hacer. Los KPIs, por su parte, te dirán si las iniciativas que has definido en tu LVT (las ramas de tu árbol) están teniendo el impacto esperado y si te estás acercando a tus objetivos.

En otras palabras, el LVT te ayuda a decidir qué carretera tomar y por qué, y los KPIs te informan si estás conduciendo a la velocidad correcta y si estás manteniendo el rumbo sin que se enciendan luces de advertencia.

Ambos son indispensables para una navegación empresarial efectiva, una gestión de productos impulsada por el valor y una verdadera .





Stakeholders Management: Stakeholder CSAT

 ¡No solo tus Clientes! Mide la Felicidad de tus Socios Clave con el Stakeholder CSAT 🤩

La vida de un Product Owner es un constante malabarismo: equilibrar las necesidades del cliente final, la capacidad del equipo de desarrollo y los objetivos del negocio. Es una pista de circo donde cada acto es vital. Pero, ¡espera! Hay un actor silencioso (o no tan silencioso, dependiendo del día) que puede impulsar tu barco hacia el éxito o, ¡ay!, hacer que se estrelle: ¡tus stakeholders!

Hablamos sin parar del CSAT (Customer Satisfaction Score) para nuestros usuarios. ¿Pero qué pasa con la gente que aprueba tus presupuestos, asigna recursos, usa tu producto internamente o cuya voz es clave para la visión? ¡Ellos también tienen sentimientos! Y sí, ¡podemos medirlos!

Presentamos la métrica secreta para la armonía en la gestión de producto: el Stakeholder CSAT.

¿Qué Diablos es el Stakeholder CSAT? 🤔

Es simple: es la aplicación directa de la métrica CSAT que usas para tus clientes, pero dirigida a tus interesados clave.

La pregunta central es sencilla: "Considerando [nuestra interacción en el último sprint / el progreso del proyecto X / el valor entregado en la última release], ¿qué tan satisfecho estás?"

Las respuestas suelen ser en una escala, por ejemplo:

  • De 1 a 5 (Muy Insatisfecho a Muy Satisfecho)
  • Otra opción: De 1 a 10 (Donde 10 es lo máximo)

Luego, calculas el porcentaje de respuestas "satisfechas" (generalmente las puntuaciones más altas, como 4 y 5 en una escala de 5, o 9 y 10 en una de 10).

¿Por qué te Debería Importar la Felicidad de tus Stakeholders? 🚀 (Para el PO / Agile Coach)

Creeme, invertir en esto no es solo "ser amable"; ¡es pura estrategia!

  1. Combustible para tu Cohete 🚀: ¿Quieres más recursos? ¿Menos bloqueos? ¿Mayor apoyo para esa idea disruptiva? Stakeholders felices son tus mejores embajadores internos. ¡Son el propulsor invisible de tu producto!
  2. Detecta Incendios a Tiempo 🔥: Un Stakeholder CSAT bajo es como la alarma de incendios. Te avisa que hay desalineación, expectativas rotas o insatisfacción gestándose ANTES de que se convierta en una crisis que apague el proyecto. ¡Mejor apagar un fuego pequeño!
  3. Claridad y Alineación ✨: Al pedir este feedback, te obligas a ti mismo (y a ellos) a reflexionar sobre qué significa realmente "satisfacción". ¡Esto ayuda a desambiguar expectativas de forma proactiva y a poner a todos en la misma página!
  4. Construye Puentes, No Muros 🤝: Este acto de pedir feedback genuino y medible demuestra que valoras su opinión y que estás comprometido con su éxito (no solo el tuyo). Fomenta una relación de socios, no de simples "peticionarios" de funcionalidades.
  5. De la "Caja Negra" a la Transparencia 🔮: La "satisfacción" de los stakeholders puede sentirse como una nebulosa. El Stakeholder CSAT la hace medible, gestionable y visible, ¡adiós a las suposiciones!

¡Manos a la Obra! ¿Cómo lo Mido? 📊

Es más sencillo de lo que parece:

  1. Identifica a tus Rockstars (Stakeholders Clave): No necesitas encuestar a todo el mundo. Enfócate en los "alto poder/alto interés" y "alto poder/bajo interés" de tu Matriz de Influencia/Interés.
  2. Diseña tu Encuesta Mini-Maestra:
    • Pregunta principal: Directa y al grano. Por ejemplo: "¿Qué tan satisfecho estás con el valor entregado por el equipo en el último Sprint?" o "¿Qué tan satisfecho estás con nuestra comunicación sobre el proyecto X?"
    • Preguntas complementarias (opcional pero ¡súper útil!): "¿Por qué esa puntuación?", "¿Qué podríamos mejorar para la próxima vez?". ¡Aquí está el oro!
  3. Elige tu Momento Justo (Timing):
    • Regularmente: Mensual o trimestral, para ver tendencias.
    • Después de Hitos Clave: Tras un Sprint Review importante, un lanzamiento, una decisión crítica.
  4. ¡Acciona los Resultados! 🛠️: ¡Esto es lo MÁS importante! No solo midas, ¡actúa!
    • Analiza las tendencias: ¿Está mejorando o empeorando la satisfacción?
    • Programa conversaciones 1:1: Si hay puntuaciones bajas, ¡llama o reúne! Escucha, entiende y busca soluciones juntos.
    • Implementa cambios: Basados en el feedback.
    • Comunica: Muestra a los stakeholders cómo su feedback ha sido valorado y utilizado. ¡Esto refuerza el ciclo virtuoso!

Conclusión

El Stakeholder CSAT no es solo una métrica, ¡es una inversión en tus relaciones más importantes! Unos stakeholders satisfechos son el viento constante y fuerte en las velas de tu producto, impulsándolo hacia adelante con menos fricción y más apoyo.

Así que, Product Owner, ¡no esperes más! Mide la felicidad de tus socios clave y verás cómo tu producto y tu carrera empiezan a acelerar como un bólido! 🚀🥳

Stakeholders Management: El Engagement de los Stakeholders

 

¿Tu Sprint Review es un Monólogo o un Diálogo? Midiendo el Engagement de los Stakeholders

La Sprint Review es uno de los eventos más cruciales en el marco de trabajo Scrum. Es el momento en que el Equipo Scrum presenta el Incremento del Producto a los stakeholders, se discute el progreso y, lo más importante, se adapta el Product Backlog para el futuro. Sin embargo, ¿con qué frecuencia esta poderosa oportunidad se convierte en una simple presentación unidireccional, con la participación deseada brillando por su ausencia?

Aquí es donde entra en juego el concepto de "Engagement Rate en Reviews", una métrica informal pero vital para evaluar la efectividad de estos encuentros.

¿Qué es el Engagement Rate en Reviews?

El "Engagement Rate en Reviews" se refiere a la medición de la participación activa, el interés y la contribución de stakeholders y equipos durante eventos de revisión como la Sprint Review. Es fundamental entender que no es una métrica estandarizada en Scrum, pero puede ser cuantificada mediante indicadores cualitativos y cuantitativos para evaluar la verdadera efectividad y el dinamismo de la reunión.

No se trata solo de la asistencia, sino de la calidad de la interacción.

¿Por qué es Crucial la Participación Activa de los Stakeholders?

Un Sprint Review con bajo engagement es una oportunidad de oro perdida. La participación activa de los interesados es la savia que alimenta el crecimiento del producto por varias razones:

  1. Feedback de Valor: Es la fuente más directa y rica de retroalimentación sobre el Incremento. Sin un diálogo genuino, el Product Owner carece de la información vital para validar suposiciones y adaptar el Product Backlog.
  2. Alineación de Expectativas: Una conversación bidireccional asegura que todos los stakeholders comprendan lo que se ha entregado, lo que no, y lo que se planea. Esto reduce drásticamente las sorpresas y las desalineaciones posteriores.
  3. Generación de Ideas y Soluciones: La diversidad de perspectivas en un ambiente colaborativo puede desbloquear nuevas ideas de producto, resolver problemas complejos y encontrar caminos inesperados hacia el valor.
  4. Compromiso y Transparencia: La participación activa fomenta un sentido de propiedad compartida y compromiso con el producto. La transparencia no es solo mostrar el incremento, es co-crear la siguiente etapa.
  5. Impulso para la Mejora Continua: El feedback honesto y accionable es el combustible para las adaptaciones del Product Backlog y para la mejora continua del propio proceso de trabajo del equipo.

¿Cómo Medir el Engagement Rate en tu Sprint Review? (Indicadores)

Dado que no hay una fórmula única, podemos combinar indicadores:

Cuantitativos (Para una Visión Rápida):

  • Número de Preguntas: Cuenta las preguntas relevantes hechas por stakeholders.
  • Número de Sugerencias/Ideas: Registra las propuestas concretas para el producto o el proceso.
  • Tiempo de Diálogo vs. Presentación: Calcula la proporción del tiempo total de la reunión dedicado a la conversación abierta vs. la mera exposición por parte del equipo.
  • Asistencia de Stakeholders Clave: Porcentaje de stakeholders identificados como "Alto Poder/Alto Interés" que realmente asisten.
  • Participación en Encuestas Post-Review: Si envías una encuesta de satisfacción del evento, mide la tasa de respuesta.

Cualitativos (Para Insights Más Profundos):

  • Nivel de Interés Percibido: Observa el lenguaje corporal, la atención y la proactividad en la discusión (¿participan activamente o están distraídos?).
  • Calidad del Feedback: ¿El feedback es superficial ("me gusta/no me gusta") o es profundo, actionable y contextualizado?
  • Variedad de Contribuciones: ¿Participan diversos stakeholders o solo unos pocos?
  • Grado de Alineación Post-Review: ¿El equipo siente que hay una comprensión compartida y alineación de prioridades después del evento?
  • Satisfacción con el Evento: Preguntar directamente al final: "¿Qué tan útil fue esta review para ti?" (escala del 1 al 5).

Otra manera de medir Review´s Engagement Rate

Medir si la revisión genera conversaciones valiosas, feedback accionable y alineamiento entre el equipo y stakeholders con los siguientes indicadores clave:
  1. Participación activa: Número de stakeholders que intervienen con preguntas o comentarios.
  2. Calidad del feedback: Utilidad de las sugerencias para ajustar el producto.
  3. Satisfacción: Percepción de que el tiempo invertido fue valioso. Aqui se puede usar un Stakeholder CSAT como métrica (de 1 a 5).

Cuantitativas

MétricaCálculoSignificado
Tasa de Asistencia(Asistentes / Invitados) × 100Compromiso básico con el evento
Interacciones por PersonaTotal de comentarios / Total de asistentesNivel de participación activa 
Feedback AccionableN° de sugerencias incorporadas en el BacklogRelevancia del feedback recibido

Estrategias para Impulsar el Engagement:

Una vez que sabes cómo medirlo, aquí tienes tácticas para mejorarlo:

  • Preparación Previa: Envía el incremento (si es posible) y un resumen de los puntos clave con anticipación, junto con preguntas específicas para el feedback.
  • Demos Interactivas: No solo "mostrar", sino "dejar usar". Permite a los stakeholders interactuar con el Incremento, si la tecnología lo permite.
  • Guía el Diálogo con Preguntas Abiertas: El Product Owner y el Scrum Master deben formular preguntas que inviten a la reflexión y al debate, no solo a un "sí" o "no".
  • Tiempo para la Conversación: Limita estrictamente las presentaciones formales del equipo. El 70-80% del tiempo debe ser para el diálogo y la adaptación.
  • Enfócate en el Valor, no en las Tareas: Presenta lo que se ha logrado en términos de valor de negocio y al cliente.
  • Reconoce y Valoriza las Contribuciones: Agradece el feedback y muestra cómo se utilizará (ej., "Gracias por esa idea, la añadiré al backlog para refinarla").
  • Varía el Formato: No siempre la misma estructura. Introduce dinámicas que fomenten la participación (ej., "Dot Voting" para ideas, "Lean Coffee" para temas de discusión).

Conclusión

El Engagement Rate en tus Sprint Reviews es más que una simple métrica; es un termómetro de la salud de tu producto y de la relación con tus stakeholders. Invertir tiempo y esfuerzo en maximizar esta participación significa transformar un evento rutinario en una poderosa plataforma de colaboración y mejora continua. Un stakeholder comprometido es un aliado invaluable, y un Product Owner inteligente sabe cómo fomentar esa conexión para asegurar que el producto evolucione con el máximo valor y la mayor alineación posible.

Stakeholder Management: Midiendo la satisfacción de interesados con SSI

 Midiendo la satisfacción de interesados con Stakeholder Satisfaction Index


Midiendo el Pulso del Éxito: El Stakeholder Satisfaction Index en Proyectos Ágiles

En el complejo ecosistema de un producto o proyecto, no basta con entregar funcionalidades; el verdadero éxito reside en asegurar que los interesados (stakeholders) clave estén satisfechos con lo que se construye y cómo se gestiona. Para Product Owners y equipos ágiles, esta es una tarea crítica, pero a menudo difícil de cuantificar. Es aquí donde el Stakeholder Satisfaction Index (SSI) se convierte en una herramienta invaluable.

¿Qué es el Stakeholder Satisfaction Index (SSI)?

El SSI es una métrica compuesta que cuantifica el nivel de satisfacción de los stakeholders clave con el progreso, los resultados y la gestión de un producto o proyecto. No se limita a una simple pregunta de "sí/no", sino que busca ofrecer una puntuación global que permita rastrear tendencias y detectar áreas de mejora.

Piensen en ello como un "pulso" regular que mide la salud de la relación con aquellos cuyo apoyo es vital para el éxito del producto.

¿Por qué el SSI es Crucial para Product Owners y Equipos Ágiles?

Para un Product Owner, que es el puente entre el negocio y el equipo de desarrollo, la satisfacción de los stakeholders es un indicador fundamental del valor que se está entregando. Un SSI bien gestionado proporciona:

  1. Visibilidad Temprana de la Salud del Proyecto: Actúa como un sistema de alerta. Una caída en el SSI puede indicar problemas de comunicación, expectativas desalineadas o una percepción de bajo valor antes de que escalen a crisis.
  2. Gestión Proactiva de Expectativas: Al medir la satisfacción de forma regular, el PO puede identificar brechas entre lo que se entrega y lo que se espera, permitiendo ajustes oportunos en la comunicación o incluso en la estrategia del producto.
  3. Fomenta la Colaboración y el Apoyo: Al solicitar activamente feedback y medir la satisfacción, se demuestra a los stakeholders que su opinión es valorada, lo que fortalece la confianza y el compromiso con el producto.
  4. Maximización del Valor: Un stakeholder satisfecho es más propenso a proporcionar feedback constructivo, asignar recursos y apoyar la visión del producto a largo plazo, facilitando así la entrega continua de valor.
  5. Mitigación de Riesgos: La insatisfacción silenciosa de un stakeholder clave puede convertirse en un bloqueo, retirada de presupuesto o incluso la cancelación del proyecto. El SSI ayuda a identificar y abordar estos riesgos a tiempo.

¿Cómo Construir y Medir tu Stakeholder Satisfaction Index?

Implementar un SSI no tiene por qué ser complejo. Aquí un proceso paso a paso:

  1. Identificación de Stakeholders Clave: Utiliza herramientas como la Matriz de Influencia/Interés (Power/Interest Grid) para enfocar tus esfuerzos en aquellos con alto poder y alto interés.
  2. Definir "Satisfacción" para Cada Uno: No todos los stakeholders valoran lo mismo. ¿Qué métricas o aspectos específicos son importantes para ellos?
    • Para el CFO: Retorno de Inversión (ROI), reducción de costos.
    • Para el Director de Marketing: Adopción de clientes, viralidad.
    • Para el Gerente de Operaciones: Eficiencia del proceso, reducción de errores.
    • Para el Usuario Final (representado por stakeholders internos): Usabilidad, resolución de problemas.
  3. Elegir el Método de Recolección de Datos:
    • Encuestas Breves y Regulares: Utiliza escalas de calificación (ej. Likert de 1 a 5 o de 1 a 10) con preguntas claras sobre los aspectos relevantes. Herramientas como Google Forms o Typeform pueden ser útiles.
    • Entrevistas Semi-estructuradas: Para insights más profundos, especialmente con stakeholders de alto nivel.
    • Feedback en Eventos Scrum: Captura reacciones y comentarios directamente en las Sprint Reviews o Demos.
  4. Desarrollar la Fórmula del SSI:
    • Puede ser un promedio simple de las puntuaciones de satisfacción.
    • Para mayor sofisticación, un promedio ponderado que refleje la importancia de cada stakeholder o de cada aspecto de la satisfacción.
    • Ejemplo simplificado: SSI = (0.4 * Puntuación de Valor Percibido) + (0.3 * Puntuación de Comunicación) + (0.3 * Puntuación de Progreso)
  5. Establecer la Frecuencia de Medición: Realiza la medición de forma consistente (ej. mensual, trimestral, o después de cada lanzamiento importante).

Ejemplo

Evalúa 5 dimensiones mediante 17 preguntas 5:
  1. Respuesta a necesidades: "¿El equipo adapta el producto según tu feedback?".
  2. Frecuencia de entregas: "¿Los releases son suficientemente ágiles para tus objetivos?".
  3. Calidad percibida: "¿Los entregables cumplen estándares de usabilidad y estabilidad?".
  4. Valor generado: "¿El producto resuelve problemas críticos de negocio?".
  5. Compromiso: "¿Te sientes escuchado en las revisiones?".

Escala: Likert (ej: 1-5 puntos), con resultados agregados para preservar anonimato.

El SSI en Acción: Más Allá de los Números

El verdadero poder del SSI no está en la puntuación en sí, sino en la conversación y las acciones que genera. Una puntuación baja en un área específica debe ser una señal para indagar, comprender la causa raíz y adaptar la estrategia o la comunicación.

Al medir activamente la satisfacción de los interesados, los Product Owners no solo construyen mejores productos, sino que también cultivan relaciones más sólidas, generan confianza y aseguran un apoyo empresarial sostenido. El SSI se convie

viernes, 24 de mayo de 2019

Agile Delivery: ¿Cómo podemos medir la productividad de nuestros equipos ágiles?

Una vez que se ponen en marcha un conjunto de equipos ágiles de desarrollo de software algún Gerente TI o un Delivery Manager suele hacer la siguiente pregunta: ¿Cómo podemos medir la productividad de los equipos ágiles? Y la respuesta rápida que surge es con la velocidad. Y aquí se puede complicar todo. Permítame aclarar que tanto las palabras productividad como velocidad son riesgosas de malas interpretaciones. Antes de usar la palabra productividad es preferible usar la palabra rendimiento o prestancia: es decir “performance”. Y cuando hablamos de velocidad, es preferible no pensar en velocidad como cantidad de entrega (cantidad de historias o cantidad de story points), sino como la rapidez de entrega (tiempo de entrega).

Métricas Agile

Un equipo ágil de alto rendimiento entrega software de calidad, funcionando en producción, de valor al cliente y a la compañía, en forma rápida. La velocidad está asociada a llegar rápido al cliente con funcionalidades de calidad y con valor. Aumentar la velocidad sirve para recibir feedback rápido del cliente, poder mejorar la propuesta de valor y adaptarse rápido. El rendimiento de un equipo, desde la perspectiva técnica de TI o DevOps, incluye esto. Bien, dicho esto… ¿Qué medimos? ¿Qué métricas de rendimiento podemos usar? 

Four Key Metrics o DORA Metrics

Nicole Forsgren, Jez Humble and Gene Kim nos ofrecen una buena respuesta en su libro Accelerate. Ofrecen una definición concreta y cuantificable del rendimiento de TI. Con cuatro métricas es posible comparar empíricamente, contrastar, clasificar y, posteriormente, mejorar el rendimiento de su equipo, de su tribu o área de desarrollo de software.
  • Lead Time for Changes: el 'tiempo de entrega' (o Delibery Leat Time) es el tiempo que se tarda en pasar un ítem de requerimiento de cliente (historia de usuario) a inicio, hasta que está desarrollado y terminado (pasa el DoD). El reloj comienza, en un tablero kanban, cuando un elemento se mueve de la acumulación a cualquiera de los estados de "trabajo en progreso" y finaliza cuando el trabajo cumple con su definición interna de terminado DoD (por ejemplo, implementado y verificado en producción). El usado en DevOps es el Lead Time for Changes ("time it takes for work to be implemented, tested, and delivered"). El libro dice que se mide desde el primer commit de código hasta que se despliega en producción (“We measured product delivery lead time as the time it takes to go from code committed to code successfully running in production”). La parte de delivery del lead time —el tiempo que toma el trabajo ser implementado, probado y entregado—es más fácil medir.
  • Deployment Frequency: la frecuencia de despliegue o Deployment Frequency es para medir la frecuencia con que se despliega en producción y conduce a que los lotes sean más pequeños (historias pequeñas), a hacer eficiente el pipeline de despliegue, mejorar el flujo de trabajo. Es probable que si la frecuencia aumenta entonces la performance también. 
  • Mean Time to Restore (MTTR): (tiempo medio de restauración o Time to Restore Service) tiene más sentido medir la rapidez con que los equipos se recuperan de la falla que la frecuencia con la que ocurren. Un equipo performante es ágil para recuperarse de fallos. Aquí el reloj comienza cuando se produce una interrupción del servicio en producción y el reloj termina cuando se resuelve la interrupción. 
  • Change Fail Percentage: (porcentaje de fallos de cambios o Change Failure Rate) una medida proxy de la calidad en todo el proceso es medir cuánto se falla en hacer cambios. Aquí se combinan dos contadores: uno para implementaciones y otro para fallas. El contador de KPI de Deployment Frequency se puede reutilizar para este caso. El segundo contador aumenta cada vez que se produce un fallo posterior (HOTFIX, OPCONS, roll back/forward, or patches, etc.). La tasa de fallas es la suma de fallas dividida por la suma de implementaciones en una ventana de tiempo dada. Mi consejo es que este KPI es reactivo, se correlaciona con la calidad pero a posteriori. Recomiendo usar además alguna métrica proactiva como: deuda técnica acumulada (Accumulated Technical Debt).


Por último, cabe aclarar que medir debería ser en función de mejorar y tener KPIs o métricas de rendimiento nos ayuda a eso, a mejorar. Sirve para mejorar el sistema de desarrollo de software o TI. Como dijo Jurgen Appelo: ¡Gestiona el Sistema y no a la gente! Por último hay que considerar que las métricas o KPIs se usan en función de metas, objetivos y propósitos. Los KPI solos y por si solos no sirve de mucho.




Referencias:









jueves, 23 de mayo de 2019

Agile Delivery: No es buena idea medir la productividad de los equipos con Velocity en Story Points




¿Cómo medimos la productividad TI de nuestros equipos ágiles? ¿Y si usamos Velocity? Y, como nuestros equipos trabajan con Scrum… ¿Si usamos Story Points? mmmmm... ¡NO! Usar puntos de historia o días ideales para medir la productividad es una muy mala idea (es como medir líneas de código). Claro que parece lo más fácil, pero será definitivamente una fórmula para el desastre. Vamos a hacer que los equipos bajen su rendimiento. ¿Por qué? Por lo siguiente: 

  1. Generará inflación y engaño: Hará que los equipos comiencen a inflar gradualmente el significado de un punto, perjudicando su estimación y degradando su trabajo. Recordemos que los puntos de historia son valores relativos, como una moneda, como el dólar. Si nos van a premiar por entregar más pesos, el equipo va a sentirse motivado y presionado para entregar los mismos dólares pero más pesos. Van a generar inflación. Quiere decir que un equipo inteligente, se dará cuenta de que si inflan gradualmente sus estimaciones en el transcurso de un año, alcanzarán su objetivo o incluso lo superarán, SIN entregar más valor a la organización. 
  2. Sacará el foco metodológico de Scrum: El aumento de la velocidad no es el objetivo de scrum, sino que es entregar software funcionando, valioso y de alta calidad al cliente de una manera sostenible. Querer entregar más puntos les saca el foco. Puede hacer también que comiencen a contabilizar puntos por cualquier cosas: por hotfix, por spikes, por trabajos de research, etc. 
  3. Disminuye la calidad: por la presión o necesidad de aumentar la velocidad los equipos harán concesiones para completar las historias adicionales necesarias para obtener los números más altos. Por entregar más dejarán de prestar atención a la calidad. Introducirán deuda técnica. Es decir que la calidad sufrirá inevitablemente cuando se toman este tipo de decisiones. Puede influenciar a bajar la vara de la definición de Terminado DoD para poder liberar puntos más fáciles. 
  4. Frena el aprendizaje: Si el equipo de scrum aprende algo nuevo sobre una historia, la velocidad puede subir o bajar dramáticamente. Los Story Points varían durante la madurez del equipo. El equipo no debe alterar el trabajo de aprendizaje hecho al estimar honestamente. Al motivar la velocidad por puntos de historia se penaliza el fallo, lo cual degrada el aprendizaje. El equipo no querrá fallar. Una estimación puede estar muy lejos de la realidad, es una ESTIMACIÓN. Fallar estimando sirve para aprender. Por otro lado el equipo no va a querer dejar tiempo para investigar o innovar, ya que ese tiempo lo pueden gastar en hacer puntos. 
  5. Generar competencia entre equipos en vez de colaboración: Cuando se miden puntos se suele caer en un intento de normalizar la velocidad entre varios equipos de scrum. Esto también es una muy mala idea. Esto puede hacer que los equipos se peleen por los puntos y a veces no quieran colaborar en puntos de otros equipos. Es una comparación sin sentido ya que los equipos de scrum tienen diferentes habilidades, objetivos, herramientas y enfoques para estimar el trabajo. Los Story Points son una métrica interna del equipo que le sirve para mejorar y autogestionar su trabajo. 
  6. Puede generar culto, miedos y odios a Scrum: hay equipos que podrían usar el Método Kanban en vez de Scrum y no usar Story Points y ellos se verían afectados. Y otros pueden llegar a odiar Scrum si lo ven como herramienta de presión y estrés.

Por último, recomiendo reflexionar acerca de... ¿Por qué queremos medir la productividad de los equipos? McGregor nos decía con su Teoría X que hay gerentes o subgerentes que piensan que: “a los empleados no les gusta el trabajo, hay que obligarlos, controlarlos, amenazarlos o incentivarlos para conseguir metas”. Esta idea puede llevar a medir y controlar a la gente. En cambio, en agilidad no es esa la idea. Jurgen Appelo nos dice en Management 3.0 que: debemos gestionar al sistema no a la gente. Sumando la Teoría Y (de McGregor) a gerentes, debemos asegurar las personas correctas, liderar, formar, desarrollar competencias, hacer crecer la estructura, facilitar el trabajo, generar condiciones, asegurar infraestructura y facilitar recursos para que los equipos desarrollen software de calidad y de valor. Las personas se dirigen y se autocontrolan si están comprometidas con los objetivos. Los desarrolladores se pueden convertir en personas que desarrollen productos extraordinarios, en equipos de alto rendimiento; si tienen la libertad de desarrollar su potencial y las condiciones necesarias para desarrollar un propósito.

O sea, finalizando, la premisa es: “gestionar el Sistema y no a la gente”. Y si gestionamos el sistema de desarrollo de software de los equipos, entonces necesitaremos medir rendimiento de nuestro sistema de desarrollo de software compuesto por nuestros equipos y su infraestructura. Para eso desde el punto de vista de NEGOCIO deberíamos usar KPIs de negocio que indique la entrega de valor; y para la perspectiva DELIVERY TI (tecnología) son recomendables otras métricas de Performance, no Velocity con Story Points.
En próximas notas recomendaré KPIs de Performance.

Saludos.

Referencias:




lunes, 13 de agosto de 2018

Scrum: Métricas - Inventario


En un equipo de desarrollo de software que trabaja bajo Scrum, el código realizado para historias (producto potencialmente entregable) pero que no se ha subido a producción es inventario. En un proceso Lean se reduce el inventario, por lo que el equipo tendrá un flujo limpio y ágil si su inventario es mínimo o no lo tiene. Para ello el equipo puede medir su inventario o "Stories Inventory", en función de sus historias, mediante los siguientes indicadores:

Indicador
Descripción
Delivered Stories
Historias terminadas y aceptadas en el sprint
Released Stories
Historias desplegadas en producción en el sprint
Accumulated Delivered Stories
Total de historias terminadas y aceptadas
Accumulated Released Stories
Total de historias desplegadas en producción
Stories Inventory
Total de historias terminadas y aceptadas sin subir a producción

Gráficamente se puede visualizar de la siguiente manera: