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

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í -.

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