El lado oscuro de la agilidad - Frase

_

"El lado oscuro de la agilidad no es medir, es no mejorar" - Jorge Rafael Aristizabal - Agile Coach

_ 

Frases sobre las métricas

 Hola a todos, les comparto algunas ideas sobre las métricas:

“Las métricas moldean la organización”.  

 - Jorge Abad 

__

“Las métricas moldean la organización y en consecuencia la cultura”.  

 - Jorge Abad 

__

“Las métricas reflejan la organización”.  

 - Jorge Abad 

__

 

“Las métricas reflejan al líder”.  

 - Jorge Abad 

__

“Las métricas reflejan lo que inquieta a los líderes”.  

 - Jorge Abad 

__

“Como me midas me comporto”.  

 - Jorge Abad 

__

Cómo TCS Latam logró mejorar su desempeño por medio de su métrica AgilityDebt (TM)

 Si eres #AgileCoach o eres parte de un #CoE de #Agilidad te recomiendo ampliamente este artículo.

En este se habla como Tata Consultancy Services mejora su desempeño empleando el índice AgilityDebt (tm), y como se ha conducido la mejora en Tata Consultancy Services LATAM y aunque he dado puntadas en dos posts:

• Video: Moviendo TCS (500.000 personas) a la Agilidad
• Cómo Lograr el Cambio Lean-Agile en Grandes Corporaciones

El nivel de detalle compartido por Roberto Moraga Diaz da una visión completa que puede ayudar a las organizaciones a mejorar de forma significativa su desempeño.

https://www.linkedin.com/feed/update/urn:li:activity:7057039282464534528/

Cita: Siempre que haya miedo, obtendrás los números equivocados - Deming

"Siempre que haya miedo, obtendrás los números equivocados" Deming

 

--

 cita de "Accelerate" 

"As Deming said, ’whenever there is fear, you get the wrong numbers’ "http://a.co/g8vh4FE

-----

De lo que también se puede inferir

"Donde hay miedo, no habrá transparencia"

----

Para la Reflexión 

• ¿Te temen?
• ¿Tu liderazgo es desde el temor?
• ¿Qué tipo de liderazgo ejercen las personas que te reportan y tienen equipos a cargo?
• ¿Tu jefe te produce temor? 
• ¿En el área u organización en la que te encuentras, las relaciones son relaciones basadas en el temor?

Saludos ágiles

Jorge Abad

Sobre la Métrica de la Felicidad

Tomado de (1)

Hola a todos

He observado que existe un prejuicio de escepticismo al acercarnos a ciertas prácticas sencillas, y en consecuencia por su sencillez creemos que no son poderosas, la métrica de la felicidad es una de ellas, es decir, es una práctica sencilla, poderosa y que genera excelentes resultados a nivel de personas, equipos y organizacional.

Quisiera en este artículo compartirles varios pensamientos y conclusiones que he tenido usando esta métrica.

En que consiste

Consiste en reportar a todo el equipo de trabajo de forma frecuente (entre un día y una semana) que tan:

• felices estamos con lo que hacemos,
• contentos,
• o cómodos con el trabajo,

hemos estado en general, es decir, cómo percibimos la suma de las interacciones laborales, los emails, los clientes o proveedores, y todo lo concerniente al trabajo, en ese periodo de tiempo. 

Usualmente se emplea un calendario, con colores o caritas:

Tomado de (2)

Tomado de (3)

Tomado de (3)

En mi caso, con mi equipo de trabajo acordamos reportar semanalmente en una hoja de cálculo online como estuvo la anterior semana, y la calificamos con seis posibles valores:

1. Muy mal
2. Mal
3. Regular
4. Normal
5. Muy bien 
6. Genial

En la empresa de gran un amigo reportan como estuvo el día:

Estado general del equipo de trabajo durante la cuarentena del COVID-19

Resultados que brinda

• Si eres líder de un equipo, no lideras máquinas sino personas y las personas son seres emocionales y racionales, parte de ese liderazgo es validar si existe bienestar en ellos con lo que están haciendo y con la empresa en general, con el objetivo de brindar ayuda en un área donde puedas intervenir.
• Existen suficientes evidencias científicas que permiten afirmar que los equipos felices o que experimentan mayor bienestar laboral son más productivos (3)(4)(5). No se trata poner la felicidad por encima de los resultados - sobre este punto volveré más adelante-, pero si tienes un equipo desanimado, muy posiblemente sus resultados y calidad no sean los esperados.
• Mejor entendimiento del bienestar a nivel de personas, equipos y empresa
• Identificación de tendencias, en una persona o el equipo de trabajo que te permitan realizar una intervención oportuna, por ejemplo: en un área de la empresa donde trabajo actualmente implementaron esta práctica durante la crisis del COVID (y el trabajo remoto) y alguien que por tres días seguidos se reportó regular, su líder al indagar identificó que tenía problemas de zona de trabajo en casa, se corrigieron los problemas y el bienestar cambio al siguiente día.
• Los miembros del equipo se hacen conscientes del estado de ánimo de sus compañeros y su ayuda es útil en caso de dificultades.

Cómo implementarlo

• Comparta a todos el propósito de la práctica, es decir, conocer el bienestar laboral o la felicidad laboral de las personas y del equipo, con el objeto de brindar ayuda en caso de requerirse. Haga énfasis en esto: es solo información respecto al ámbito laboral.
• Logre un acuerdo sobre el uso de la práctica con todo el equipo.
• Comparta que se va a hacer con la información que se recolecta.
• Identifique la frecuencia de actualización: diaria, semanal; no recomiendo periodos más largos.
• Si es al final del daily o un ejercicio de sincronización semanal, pregunté y que califiquen el ultimo día o semana.
• Pregunte abiertamente si quienes han compartido su estado de ánimo quieren compartir la razón del mismo, no obligue a nadie.
• Como líder usted es responsable del entorno laboral de las personas a cargo - esa es su área de influencia -, si afloran retos personales, remita a su compañero a talento humano o bienestar laboral para que tenga asistencia por parte de profesionales especializados en esa área.

Qué hacer durante 

• Ponga atención a las señales
• Si alguien por varios periodos ha compartido malestar, acérquese e indague ¿qué le tiene con malestar? ¿o qué sucede en ese equipo? y ¿qué puede hacer por esa persona o el equipo?
• Obtenga promedios por áreas y por personas y generales, identifique tendencias.
• Actúe acorde a las tendencias, es posible, que alguien o el equipo requieran su intervención.

Qué no hacer

• Comprenda que no siempre tenemos días o semanas perfectas, no haga de esto una carga, ni para usted, ni para los demás
• Respete la vida personal, 
• Adicional a lo anterior, no trate de convertirse en el sicólogo de su equipo, su intervención limítela a lo laboral, pero si observa que es necesario otro profesional, remita a las a personas con dificultades a las áreas de bienestar laboral de su organización
• No obligue a las personas a explicar por qué calificaron un determinado estado de ánimo (recuerde solo invite, si la respuesta es no, no pasa nada).
• No convierta la felicidad en su objetivo máximo, y en consecuencia se vuelva todo un estado de complacencia o de chamanismo para que todos tengan cara sonriente, pero sin orientación al logro,
  
  
  
  ¡No! su objetivo y el de su equipo es generar resultados, es decir, ganar el partido (futbolísticamente hablando), por lo tanto:
• busque ganar el partido
• pero no pase por encima de las personas, ni las maltrate, no tiene sentido desde ningún punto de vista
• pero tampoco se vuelva tan complaciente que no les exija generar los resultados a los que se han comprometido al hacer parte de la organización, el área y el equipo de trabajo.
• como líder del equipo, genere las condiciones para ganar, identifique impedimentos, fricciones; resuélvalas. Ganar genera felicidad y satisfacción, espíritu de equipo, y en consecuencia mejores resultados

"Ganar, genera felicidad y satisfacción, espíritu de equipo, y en consecuencia mejores resultados"

Por último

Recuerde, usted lidera y acompaña a personas, no muebles y enseres, ser empático y entender el estado de ánimo de su equipo y las personas que lo componen le ayudará avanzar mejor.

Hasta acá este compartir.

Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Foto de Negocios creado por senivpetro - www.freepik.es
2. https://medium.com/andressalcedo/equipos-felices-son-mas-productivos-53a2379048b1
3. Niko-Niko Calendar - Tracking Team Happiness for Employee Engagement https://management30.com/practice/niko-niko-calendar/ 
4. Happiness Metric -http://scrumbook.org/retrospective-pattern-language/happiness-metric.html
5. The Happiness Dividend - https://hbr.org/2011/06/the-happiness-dividend

Tu Radar de Madurez Ágil no es la Meta, el Objetivo es Generar Valor

Hola a todos

Por lo general cuando realizamos una evaluación (assessment) del nivel de madurez ágil de un

• rol, 
• equipo, 
• grupo de equipos, 
• programa,
• área de negocio,
• framework,
• cadena de valor (value stream), 
• u organización

es común el uso de los radares (es la práctica común). Y respecto a los radadres los hay para todos los gustos, una lista por la cual podrías empezar son:

• los propuestos y sugeridos por agilityhealth https://agilityhealthradar.com/radars/
• TeamHealth® Radar
• Remote Work Health Radar
• DevOps Health Radar
• Agile Release Train
• Lean Product Health Radar
• Program Health Radar
• Enterprise Business Agility Health Radar
• Para roles tienen
• Enterprise Business Agility Strategist Health Radar
• Agile Coach Health Radar
• Agile Leader Health Radar
• Product Owner Health Radar
• ScrumMaster-Health-Radar
• SAFe® Release Train Engineer Health Radar
• Los usados en SAFe https://www.scaledagileframework.com/metrics/ :
• Business agility self-assessment
• Lean portfolio management self-assessment
• Continuous learning culture self-assessment
• Organizational agility self-assessment
• Enterprise solution delivery self-assessment
• DevOps Health Radar
• Lean-Agile leadership self-assessment
• Agile product delivery self-assessment
• Team and technical agility self-assessment
• Los de La lista de chequeo de Scrum Roosmalen (clic aquí) traducidos Lucho Salazar con:
• Lo fundamental
• Scrum Esencial
• Los Roles
• Los Eventos
• Los Artefactos
• Impedimentos
• Estimaciones
• Velocidad
• Product Backlog
• Grafica de Trabajo Pendiente
• Scrum Diario
• Escalado
• Indicadores Positivos
• Distribuido
• Reuniones
• Equipo

Sin negar, que según las organizaciones he participado en el desarrollo de los propios según los aspectos y cultura predominante - es una tarea común en este proceso de agile coaching- .

Lo que esta bien con los radares

Los radares:

• ayudan a identificar gaps
• muestran áreas de trabajo en las cuales la industria, un rol o una práctica esta poniendo interés
• permiten al agente de cambio el siguiente paso hacia el cual avanzar.

Lo que está mal con los radares y los niveles de madurez

El problema se presenta cuando el modelo de madurez se vuelve el objeto de deseo organizacional, perdiendo de vista lo realmente importante:

• la generación de valor
• la reducción del time to market
• la innovación
• la supervivencia
• la capacidad de adaptarse al cambio
• la satisfacción del cliente.

Los problemas fundamentales que he observado con los radares y modelos de madurez, son los siguientes:

• Son estáticos y de mentalidad fija
• nos hacen creer que no hay "más allá" y que si logramos eso estamos en el cima del desempeño o el objetivo buscado
• quedan facilmente obsoletos, debido a requieren de agregar otro anillo u otro sector según se progresa en el conocimento o en la práctica
• pueden llegar a convertise en el objetivo en vez de ser un medio para la mejora
• proliferan y es probable que estemos cayendo en el problema de los estandares (ver chiste abajo)
• podemos estar midiendo muchas cosas sin generar resultado o perdiendo de vista lo importante

Qué hacer entonces

Tal como lo sugiere el título del artículo, debemos enfocarnos primordialmente en métricas (valores que aumentan o disminuyen) que nos muestren si estamos o no generando valor, si estamos innovando, mejorando nuestra adaptabilidad y resiliencia, tales como:

• reducción del time to market (que cada vez sea menor 🡻)
• flujo de una pieza (que cada vez la unidad de generación de valor sea más pequeña y de a una pieza 🡻)
• cantidad de defectos (que cada vez sea menor 🡻)
• satisfacción del cliente interno (que cada vez sea mayor 🡹)
• satisfacción del cliente externo (que cada vez sea mayor 🡹)
• adopción de innovaciones propuestas (que cada vez sea mayor 🡹)
• salud, bienestar o felicidad de los equipos de trabajo (que cada vez sea mayor 🡹)

Esta forma de medir te moverá hacia la mejora continua de lo que estas buscando y tu objetivo será alcanzar la perfección tan deseada y sanamente inalcanzable (kaizen), y en consecuencia al tratar de mover estas métricas claves (aumentar o reducir su valor) hará que sistémicamente tomes decisiones que te dirijan hacia tu objetivo, con el beneficio adicional que este tipo de drivers nunca queda obsoleto.

Similar a como lo adopta el State of Devops (2), con 4 métricas puedes comprender cual es el performance de una organización respecto a este conjunto de prácticas o cultura:

Tomado de (2)

• Deployment frecuency 🡹 - Frecuencia de despliegues  
• Lead time for changes 🡻- Tiempo del proceso para cambios (desde el commit hasta producción)- 
• Time to restore service🡻 - Tiempo para restaurar el servicio
• Change failure rate 🡻- Tasa de cambios fallidos -  (aunque la verdad prefiero traducir esto como: tasa de problemas desplegados a producción)

Cerrando

No se trata pues de satanizar los radares, ¡No, ni más faltaba! pues estos sirven de guía, pero no podemos perder del foco de lo que buscamos, por lo tanto, la próxima vez que te enfrentes determinar un estado de madurez, en primer lugar, diseña y adopta métricas que te ayuden a validar si se genera valor al cliente final desde un:

• rol 
• equipo
• grupo de equipos
• programa
• área de negocio
• framework
• cadena de valor
• capacidad
• organización

y luego si lo deseas apóyate adicionalmente en los radares.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. The Key to High Performance: What the Data Says - Dr. Nicole Forsgren
• https://www.youtube.com/watch?v=RBuPlMTXuFc
• https://es.slideshare.net/nicolefv/the-key-to-high-performance-what-the-data-says 
2. State of Devops
• https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling
• https://cloud.google.com/devops/state-of-devops/
• https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
3. Una pequeña reflexión sobre los radares, las métricas y los modelos de madurez ágiles (clic aquí) 

Frase: Que sucede cuando nuestro trabajo depende del logro de objetivos

"People with targets and jobs dependent upon meeting them will probably meet the targets - even if they have to destroy the enterprise to do it." - W. Edwards Deming

"Las personas con objetivos y trabajos que dependen de cumplir estos objetivos seguramente los alcanzarán, aunque tengan que destruir a la empresa para ello" - W Edwards Deming

Una Conclusión: Cómo me midas me comporto

Hola a todos

Basados en esta frase de Deming (les recomiendo que busquen sus frases)

"Cambia la regla y usted obtendrá otro número." - W. Edwards Deming

Quisiera compartirles dos conclusiones a las que he llegado en este compartir con organizaciones y equipos

Cambia el número y obtendrás un nuevo comportamiento Cambia la métrica y obtendrás un nuevo comportamiento

o mejor

Cómo me midas me comporto

Tener esto presente me ha ayudado bastante para lograr alinear fuerzas y tener foco de los equipos y organizaciones en la generación de valor.

Hasta acá este corto compartir

Saludos Ágiles




Jorge Abad

¿Quiéres Saber que tan Ágil es tu Organización? (Una Propuesta de Cómo Medir una Transformación hacia la Agilidad)

¿Quiéres Saber que tan Ágil es tu Organización? (Una Propuesta de Cómo Medir una Transformación hacia la Agilidad) from Jorge Hernán Abad Londoño

Algunos pensamientos sobre métricas, procesos y documentación

Hola a todos

Dejo por acá estos pensamientos que me dan vueltas

Sobre las métricas

• Deben trabajar para mi y no al revés
• deben buscar abundancia y no escasez, es decir, me ayudan a mejorar y dar salud a mi entorno, no son para generar presión y desgaste de los involucrados
• Pocas métricas es mejor que muchas métricas

Sobre los métodos, procesos y mejora continua

• Deben trabajar para mi y no yo para ellos
• Los métodos, frameworks y procesos serán útiles hasta que se encuentre una mejor forma de hacer las cosas
• la mejora continua debe llevarme tan lejos como yo lo visione
• la vigilancia tecnológica es necesario para alimentar la mejora continua y saber referentes
• los experimentos son claves para avanzar en la mejora continua

Sobre la documentación

• La documentación trabaja para mí
• Se documenta lo que genera valor

Cálculo del SPI en un Proyecto Ágil

Una de las preguntas más frecuentes que se hacen quienes comienzan a trabajar en el mundo de la agilidad es, ¿cómo calculo el avance de la construcción de mi producto?, en este post quiero compartir como es posible hacerlo.

Vamos a comenzar con poner los equivalentes del método del valor ganado (1)(2) en un proyecto agil:

• Valor :
• funcionalidad puesta a disposición del cliente que le reemplaza una existente o le mejora su negocio,
• Generalmente medida en puntos en proyectos ágiles, 
• Las funcionalidades inicialmente construidas tienen mayor valor de negocio que las construidas al final debido a la priorización del backlog  (3). El valor de negocio es subjetivo y es dado por el Cliente y/o Product Owner en Scrum (3)
• Punto: 
• Percepción (debido a la incertidumbre) del esfuerzo requerido para construir una funcionalidad
• Por lo general se usa la serie de fibonacci alterada para "tallar" (poner talla), estimar una funcionalidad (historia de usuario, caso de uso) a ser construida, La serie usada es 1,2,3,5,8,10,20
• BAC 
• Presupuesto a la terminación del proyecto. Budget at Completion
• En ágil emplearemos como BAC la cantidad de puntos estimados del release
• EV
• Valor ganado del proyecto
• En ágil emplearemos la cantidad de puntos en DONE (5) al momento de hacer la medición
• PV
• Valor planeado
• En ágil emplearemos la cantidad de puntos  planeados en DONE al momento de hacer la medición.
• El insumo de los puntos planeados en Done es proporcionado por la gráfica del Burn Up Release
• Release Burn Up
• Gráfica empleada en proyectos ágiles en la cual en el eje "x" se encuentran los Sprints, en el eje "y" los puntos acumulados. De igual forma se gráfica la cantidad de puntos estimados que tendrá el release (como techo del mismo) y en el tiempo se presentan los puntos acumulados sprint tras sprint, en aras de buscar una tendencia y un estimado para lograr el posible despliegue de una versión liberable.
• SPI
• Indice de desempeño del cronograma
• Indica la proporción en la que se cumple el planeado a la fecha 
• si es mayor que 1 se encuentra el proyecto adelantado vs el planeado
• si es menor que 1 se encuentra el proyecto atrasado vs el planeado

Dado estos insumos los cálculos de los índices son:

• Avance = EV / BAC = Puntos en Done al momento de la medición/ Puntos totales del  Release

• SPI = EV / PV = Puntos en Done al momento de la medición / Puntos proyectados

Condiciones, Restricciones y Aclaraciones
Es importante aclarar que en un proyecto ágil pueden darse las siguientes condiciones:

• Si se alcanza valor de negocio más temprano se puede parar la construcción de este release y comenzar el siguiente
• Si existe una fecha límite se le puede ofrecer al cliente:
• dado que el equipo tiene una velocidad (tasa a la cual produce software sprint tras sprint) que funcionalidades desea sacar del product backlog para cumplir la fecha impuesta
• cuales funcionalidades cumplen el objetivo de negocio que quiere resolver con la solución
• Dada la incertidumbre inherente al desarrollo de software (clic aquí), muchas veces se puede contestar:
• esa capacidad de negocio la logramos aproximadamente entre el sprint 7 y 10, en función de la priorización del backlog

Espero haber aportado/ayudado a la solución de esta inquietud frecuente.

Saludos Ágiles

Jorge Abad

Post relacionados:

1. EVM, CPI, SPI en AGILE / SCRUM - clic aquí -.
2. Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI - clic aquí -.
3. Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO - clic aquí -.
4. Planning poker  - clic aqui -.
5. Una versión inicial de Definition of Done (Definición de Hecho / Terminado / Realizado) - clic aquí -.

Leído y Recomendado: Las 3 métricas claves del kanban

http://www.elproximopaso.net/2012/07/las-3-metricas-claves-del-kanban.html


Demasiado bueno.

Útil para equipos de soporte y mantenimiento

_

La métrica de la felicidad - Un elemento clave para Scrum

Hola a todos

Dentro de mi curso de Gerencia de proyectos informáticos el cual dicto en la Universidad Eafit - www.eafit.edu.co para el pregrado de ingeniería de sistemas, tengo la costumbre de poner a escribir a los estudiantes un artículo sobre un listado de posibles temas que les proporciono que tienen que ver con gerencia de proyectos y /o agilismo.

A continuación les comparto el artículo escrito por Miguel Baquero, el cual es una buena aproximación a una métrica que debe llevar el equipo y que debe ser revisada cada retrospectiva, LA METRICA DE LA FELICIDAD.





---
link al documento original - Clic aquí

La métrica de la felicidad.

Gestión de proyectos informáticos.

Miguel Baquero

mbaquer6@eafit.edu.co

Departamento de Ingeniería de Sistemas

Universidad Eafit

Medellín, Colombia

Gerentes y consultores piensan que la gente está harta de trabajar infeliz. La gente más joven en particular se resiste a trabajar bajo el esquema de mando y control, ambientes basados en culpa y castigo. Un cambio importante está sucediendo. Harvard Business Review dedicó todo un número a la Felicidad porque empleados felices conllevan a clientes felices y mejores negocios. Sin embargo, nunca se debe subestimar la capacidad humana de cometer errores. Puede pasar que el equipo sea muy complaciente, tenga exceso de confianza o no vea oportunidades para mejorar. El patrón “un peldaño a la vez”, recomienda enfocarse en un punto a mejorar, de manera que sea claro su impacto. Sin embargo, existen muchas oportunidades para mejorar y es necesario tener una forma de trabajar en las cosas que den los mayores beneficios.

A menudo se genera una larga lista de cosas que se supone ayudan a mejorar la velocidad. Al ser muchos ítems, es posible que se trabaje en algo que no logre mejorar la velocidad, y sí lo hace, no presenta una mejora importante. La gente comúnmente no se siente identificada con largas listas, por lo que no están suficientemente motivados para que funcionen. Es necesario trabajar en la mejora adecuada de manera que el equipo sienta pasión. La gente siente gran satisfacción al hacer bien su trabajo, además tienen un gran sentido de responsabilidad por su trabajo, particularmente si se encuentran en un equipo autónomo. Por esto, hay que encontrar qué mejora va a incrementar en la mayor medida posible la felicidad del equipo, e implementarlo para el siguiente Sprint.

Típicamente, el equipo decide cuál es el nivel actual de felicidad y cada uno de sus miembros expresa qué podría aumentar este nivel al máximo, luego como equipo, se decide cual va a ser la mejora que va a producir la mayor felicidad para todo el equipo. 

Existen varias maneras de medir la felicidad del equipo, pero se ha encontrado que una forma simple y subjetiva de un puntaje de uno a cinco es suficiente. La mejora deseada debe ser parte de la meta del Sprint, por lo que este patrón además, puede ayudar a formular esta meta.

Hay cierta vulnerabilidad en la expresión de estos deseos. Algunas personas podrían sentirse incómodas haciéndolo públicamente. En este caso, podrían expresarlo anónimamente. Sin embargo, esto no es lo ideal; es mucho mejor reforzar una “comunidad de confianza”, donde las personas se sientan bien expresando sus deseos. 

Enfocarse en la felicidad del equipo tiene una extraña habilidad de descubrir qué problemas evitan que el equipo sea más efectivo, no solo más feliz. Probablemente se deba a que las personas obtienen gran satisfacción al hacer un buen trabajo. Además, a menudo están en una posición que permite entender qué pueden hacerlos más efectivos y que cosas se interponen en su camino. Otra razón para que la Métrica de la Felicidad permita un mejor desempeño del equipo, es que la gente siente una mayor conexión personal y compromiso a mejorar.       

La Métrica de la Felicidad puede ayudar a prevenir el agotamiento. El agotamiento ocurre cuando la gente trabaja por largas horas o gastan mucha energía mental durante mucho tiempo sin descanso. El agotamiento puede destruir la productividad (“Every hour of overtime is offset by an hour of undertime” – Tom DeMarco) o también provocar la deserción de la gente a un ambiente más sano. Sí el agotamiento es una amenaza, alguien probablemente va a proponer como Métrica de la Felicidad, “detener las horas de trabajo no sanas”.       

La gente puede tener distintas percepciones de la felicidad, por lo que es importante no dejar a una sola persona encargarse de la Métrica de la Felicidad; es una decisión del equipo qué es lo mejor para ellos. Al mismo tiempo, cada persona debe ser escuchada, haciéndolos parte de la decisión final. Algunas personas (como gerentes con mucho tiempo en el oficio), temen que el equipo “engañe” este sistema, decidiendo que la felicidad puede ser mejorada tomando los viernes libres, por ejemplo. Esto podría ser posible, sin embargo, como todos los aspectos de la anatomía del equipo, se debe confiar que el equipo siga el espíritu del juego. (Si no se confía en el

equipo, esto viola el espíritu del juego, por lo que se tiene problemas más serios). Así como todas las mejoras, la Métrica de la Felicidad debe ser medible, de manera que indique que realmente se han producido mejoras.       

Un ejemplo: Un equipo usa la Métrica de la Felicidad de forma que puedan identificar y priorizar las mejoras. En una escala de 1 a 5 se les pregunta cómo se sienten con su rol en la compañía y como se sienten acerca de la compañía. Luego comparten qué los haría sentir mejor y el equipo utiliza planning poker para estimar el peso de las cosas que los miembros del equipo consideran importantes para esto. El equipo estima el valor (opuesto al esfuerzo) de los ítems del backlog. El equipo estimó 50 puntos. “Mejores historias de usuario” fue la mejora más importante que consideró el equipo. Remover este impedimento tuvo más de 60 puntos. El product owner se preguntó si remover este impedimento podría doblar la velocidad al obtener un mayor puntaje que todo el product backlog para el Sprint. “Mejores historias de usuario” se agregó al Product Backlog para el siguiente Sprint y una nueva Definición de Done. Esta Definición de Done fue implementada como criterios de aceptación que tenía métricas que fueron calculadas en el siguiente Spring review. Estas incluyeron:      

1. Cuantas historias de usuario estuvieron en el Sprint que no alcanzaron el criterio INVEST (immediately actionable, negotiable, valuable, estimable, sized to fit, and testable) este debe ser 0.
2. ¿Cuántas veces los desarrolladores tuvieron que acudir al product owner para clarificar una historia durante el sprint?
3. ¿Cuántas veces las dependencias forzaron una historia a estar en estado de espera durante un Sprint? 
4. ¿Cuántas historias tuvieron una eficiencia de más del 50% en el proceso? 
5. ¿Cuántas historias no fueron claras para los desarrolladores? Medir por el número de miembros que se quejaron de la historia 
6. ¿Cuántas historias implicaron mayor implementación técnica que la aclaración de la experiencia de usuario deseada?
7. ¿De cuántas historias de usuario los desarrolladores entendieron la relación entre una historia, el tópico que produjo la historia y las necesidades del negocio que la generaron? Medida por el número de miembros del equipo que tienen quejas que no entienden qué estaban haciendo durante la historia.   

Los resultados: Mientras que la mejora a la calidad de las historias de usuario nunca termina, el sprint review mostró la mejora significativa en este ítem del Backlog medido por los criterios de aceptación. Mejoras significativas resultaron en un incremento de la velocidad después de varios sprints. Después de doblar la velocidad, el impedimento cayó del encabezado de la lista y fue reemplazado por otro impedimento. Un equipo feliz es un equipo mucho más productivo.         

Referencias:

Sutherland, Jeff. SCRUM LOG JEFF SUTHERLAND. 2012 . En: http://scrum.jeffsutherland.com/2010/1 1/happiness-metric-wave-of- future.html (consultado en noviembre de 2013).

Harrison Neil B, Sutherland Jeff. PROCESS IMPROVEMENT. 2013. En: https://sites.google.com/a/scrumplop.o rg/published-patterns/retrospective- pattern-language/happiness-metric (consultado en noviembre de 2013).

Schwartz, Tony. Happiness is overrated. 2010. En: http://blogs.hbr.org/2010/10/happiness -is-overrated/ (consultado en noviembre de 2013).

------------
link al documento original - Clic aquí

Scrum: Una herramienta para el PO, ¿cuanto costo he convertido en valor? - DEUDA DE VALOR -

Hablamos mucho de deuda técnica dentro de agilismo (cosa sana y buena)

pero que tal hablar de la DEUDA DE VALOR!!!

Veamos..


Dentro de las necesidades de un PO - Product Owner, está el conocer el ROI de su producto (cosa que no es siempre fácil de calcular) y el PO cómo líder estratégico del proyecto  (el cual proporciona la visión y el direccionamiento del producto) debe trabajar en convertir el dinero / tiempo /esfuerzo invertido (el cual llamaré costo) del Team Scrum en un Release usable en producción lo antes posible.

No se trata de salir con un Release del sistema el cual no genere valor (ejemplo, un software repleto de administración de tablas maestras y de CRUDs). Se trata de que mientras el sistema no sea usado para el fin para cual fue creado (plasmado en la visión) y no haya un usuario final dándole clic, todo el esfuerzo de ser ágiles no tiene sentido y bajo este enfoque muy poco sirve:

• ser equipo Scrum 
• decir que somos Agile
• predicar el desarrollo orgánico del software
• cumplir los criterios DONE!!! de todas las historias de usuario
• tener cero errores, y deuda técnica en cero
• etc

El software cobra valor cuando es usado por los usuarios, antes no. (lo he leído, me lo han enseñado y lo he predicado, pero cuesta, a ratos plasmar esto cuesta, por múltiples razones y casuísticas - benditas heridas de guerra - )

En esa misma dirección y con la necesidad de tener herramientas para los PO con los que trabajo, pensé en esta tabla y gráficas, las cuales pongo a su consideración; y si les son útiles para mitigar el riesgo de quedarnos con "la papa caliente" de un software que noes liberado, implicando caer en una de las causas de fracaso de Scrum/Agile, habrán cumplido su misión. (si las usan y les sirven, me cuentan)

A continuación las gráficas y su explicación

Proyecto Ágil que no Genera Valor

Características principales:

• es un proyecto ágil
• Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 0% 
• probablemente cumple con todo lo que pide el PO
• pero su comportamiento es igual a un proyecto ejecutado bajo el esquema tradicional (Cascada o RUP), solo saliendo a producción al final del proyecto y poniendo en riesgo el presupuesto asignado y la reputación del PO.

Riesgos

• Alta probabilidad de cancelación del proyecto
• Alta probabilidad de cambio de PO
• Alta probabilidad de cambio del SM - Scrum Master - por no hacerle Coach al PO y guiarlo en los principios ágiles (recordemos que Scrum es como las suegras: "Siempre esta señalando tus defectos")

Causas

• Un Release Plan en el que existe alta dependencia de todas las funcionalidades según el PO,  Lo más seguro es que se argumente que se requiere un solo release para el proyecto.
• Un mal pareto de software vs funcionalidad, o sea,  el  product owner no esta convencido del  80 / 20, en que con el 20% de software es capaz de cumplir con el 80% de necesidades de negocio.
• Clasificación de funcionalidades como criticas y necesarias cuando estas en realidad no lo son.

Solución

• Coach al PO por parte del SM.
• Evaluar el Release Plan
• Proponer en producción algo con valor lo antes posible

----

Proyecto Ágil que Tuvo una Tímida Salida a Producción

Características principales:

• es un proyecto ágil
• Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 13%
• probablemente cumple con todo lo que pide el PO
• Se tuvo una salida a producción, pero este afortunado evento no se volvió a repetir.
• Su comportamiento es muy similar a un proyecto ejecutado bajo el esquema tradicional (Cascada o RUP), y su poco valor generado pone en riesgo la viabilidad del proyecto.

Riesgos

• Alta probabilidad de cancelación del proyecto
• Alta probabilidad de cambio de PO
• Alta probabilidad de cambio del SM - Scrum Master - por no hacerle Coach al PO y guiarlo en los principios ágiles (y el mismo chiste sobre las suegras...)

Causas

• Un Release Plan en el que existe alta dependencia de todas las funcionalidades según el PO,  Lo más seguro es que se argumente que se salió a producción con lo que se podía pero para cerrar el proyecto requiere el resto resto del producto.
• Un mal pareto de software vs funcionalidad, o sea,  el  product owner no esta convencido del  80 / 20, en que con el 20% de software es capaz de cumplir con el 80% de necesidades de negocio.
• Clasificación de funcionalidades como criticas y necesarias cuando estas en realidad no lo son.

Solución

• Coach al PO,
• Evaluar el Release Plan
• Proponer salir a producción con algo lo antes posible

----

Proyecto Ágil que Tiene Salidas a Producción pero aún no Convierte todo su Costo en Valor

Características principales:

• es un proyecto ágil
• Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 50%
• Se cumple con todo lo que pide el PO
• Tiene salidas frecuentes a producción pero no logra poner todo el valor en producción.
• Es un proyecto satisfactorio desde el punto de vista ágil aunque puede mejorar

Riesgos

• No Aplica.

Causas

• Existe una buena gestión del PO aunque no se cumple completamente el pareto de software vs funcionalidad.

Solución

• Evaluar el Release Plan (SM, Equipo y PO) buscando con que elementos se puede salir a producción.
• Identificar si se esta invirtiendo tiempo en funcionalidades innecesarias.

----

Proyecto Ágil que Tiene Salidas a Producción y Constantemente Convierte su Costo en Valor

Características principales:

• es un proyecto ágil
• Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 88% 
• Se cumple con todo lo que pide el PO
• Tiene salidas frecuentes a producción
• Es un proyecto satisfactorio desde el punto de vista ágil  

Causas

• Buena gestión del PO
• Buen acompañamiento del SM y del Equipo

Solución / Recomendación

• Seguir así y no bajar la guardia.

Quedo atento a su retroalimentación y/o comentarios.

Saludos Ágiles

Jorge Abad