miércoles, noviembre 27, 2019

Ejemplo de reporte de la "PMO Ágil"

Hola a todos

Les comparto un ejemplo de reporte que podría realizar una "PMO Ágil", donde se observan los diferentes aspectos de la gestión del portafolio ágil (ver post anterior).

Recuerde, se puede incluir estos o diferentes campos de acuerdo a su contexto, esta es solo una propuesta que permite ver los aspectos de:
  • Construcción del Producto
  • Calidad del Producto
  • Salud de los Equipos
  • Uso del Producto
  • Desempeño del Producto en el Negocio
dentro del portafolio de productos que se están desarrollando con marcos ágiles.




Reporte General


A continuación cada una de las secciones.
Durante el Desarrollo o Construcción del Producto


Calidad del Portafolio 


Salud de los equipos



Uso del Producto

Desempeño del Producto en el Negocio
Con este tipo de reportes y de transparencia generada (ojala con una frecuencia de dos meses al mes), se podrán tomar acciones y la "PMO Ágil"(1) fungir como ese Scrum Master Organizacional: preocupada por:

  • La generación de valor
  • remover impedimentos organizacionales
  • promover la inspección y adaptación (agilidad) organizacional




Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias


  1. En el mundo de 

lunes, noviembre 25, 2019

Métricas Sugeridas para la "PMO Ágil"

Hola a todos

Hace poco compartí un post sobre Métricas para Product Owners (ver aquí), y basado en esa aproximación y considerando que para las PMO que en la actualidad tienen Productos y Proyectos desarrollados de forma ágil, las métricas comunes de CPI (Cost Performance Index) y SPI (Schedule Performance Index), fuera de que es difícil calcularlas, no proporcionan mucho valor en ese contexto, considerando que lo que se busca es la generación de valor y no la construcción del alcance.


Importante: De ahora en adelante cuando se mencione la palabra Portafolio se referirá a una colección de productos que tienen un propósito común dentro de una organización y que están siendo construidos empleando algún marco o metodología ágil



Basado en lo anterior propongo este Modelo de Métricas a seguir en una "PMO" Ágil(2), esta aproximación tiene como pilares:
  • Durante la Construcción
    • Salud de los equipos
    • Desarrollo o Construcción del Portafolio
    • Calidad del Portafolio
  • Durante el Uso
    • Uso del Portafolio
    • Desempeño del Portafolio en el Negocio






Las métricas a considerar dentro de cada uno de estos pilares son:

  • Durante la Construcción
    • Desarrollo o Construcción del Portafolio
      • Frecuencia de despliegues del producto (1) (También puede interpretarse como cantidad de releases en un periodo de tiempo)
      • Lead Time para cambios (1) (También puede interpretarse como Time to Market de cualquier cambio sobre el producto, nuevas versiones, etc)
      • Probabilidad de cumplir el rango de fechas de release 
      • Sprints sin cumplir con velocidad (es decir, inferior al 80% de velocidad del equipo)
      • Velocidad del portafolio (6)
      • Predictibilidad del portafolio (6)
      • Presupuesto invertido (8)
      • Deuda de valor
        • % de costo construido puesto en producción
        • % del valor construido puesto en producción
    • Calidad del Portafolio
      • Tiempo para restaurar el servicio (1)
      • Tasa de cambios fallidas (1)
      • Defectos encontrados en desarrollo
      • Defectos encontrados después de cada liberación
      • Defectos postergados para una versión futura
      • Tickets de soporte por día o semana
      • Deuda Técnica
      • Cobertura de pruebas unitarias
      • Cobertura de pruebas funcionales automatizadas
    • Salud de los equipos
      • Lead Time promedio de resolución de impedimentos (8)
      • Mejoras realizadas 
      • Escalamientos sin ser resueltos
      • Experimentos realizados
      • Cantidad de Vacantes (8)
      • Tiempo sin cubrir vacantes (8)
      • Tiempo sin Product Owner
      • Tiempo sin Scrum Master
      • NPS
        • del Product Owner acerca del Equipo 
        • del Equipo hacia el Product Owner
        • del Scrum Master hacia el Equipo
        • del Equipo hacia el Scrum Master
      • NPS del Equipo acerca del trabajo en la organización (es decir, la pregunta a realizar, sería.¿De 1 a 10 que tanto recomendaría trabajar en esta organización?)
  • Durante el Uso
    • Uso del Portafolio
      • Tráfico
      • Tasa de Retención
      • Duración de la sesión
      • Número de acciones del usuario por sesión
      • Proporción de usuarios activos diarios / usuarios activos mensuales 
      • Tráfico (fuentes de tráfico)
      • Porcentaje de rebote (porcentaje de usuarios que encontraron el producto y se fueron)
      • Tasa de Rotación (Clientes perdidos / Clientes totales)
      • Número de sesiones por usuario
      • Usuarios por función o por volúmenes de transacción (semanal, mensual)
    • Desempeño del Portafolio en el Negocio
      • Validación del Business Case
      • Satisfacción del cliente (el NPS es una buena opción)
      • Hipótesis validadas/Hipótesis planteadas
      • Los OKR del portafolio
      • Valor liberado (interna y externamente)
      • Ingreso mensual
      • ROI mensual del portafolio
      • Ingreso promedio del usuario (Average revenue per user -ARPU)
      • Customer Lifetime Value (CLTV or LTV)
      • Costo de adquisición del cliente (CAC)

Cerrando

Nuevamente la recomendaciones son las mismas que se hizo con el articulo de Métricas para Product Owners(3):
  • no trates de abarcar todo desde el inicio
  • crece orgánicamente el uso de las métricas
  • esta es una propuesta
  • toma lo que te sirva
  • y no olvides la orientación y generación de valor unido con la salud de los equipos de trabajo
Ver acá un -ejemplo aquí-.

Hasta acá este compartir

Saludos Ágiles
Jorge Abad


Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. Tomado de "2019 -  Accelerate State of DevOps Report"- https://cloud.google.com/devops/state-of-devops/
  2. Quedo debiendo el post de el por qué de cada métrica, pero este MVP, no dudo que genere valor como una primera aproximación
  3. Métricas para Product Owners - http://www.lecciones-aprendidas.info/2019/10/metricas-para-product-owners.html
  4. PMO - Una Propuesta de Responsabilidades y Nuevos Nombres en el Mundo Lean-Agile - http://www.lecciones-aprendidas.info/2019/08/pmo-una-propuesta-de-nombre-y-funciones.html 
  5. Scrum: Una herramienta para el PO, ¿cuanto costo he convertido en valor? - DEUDA DE VALOR - http://www.lecciones-aprendidas.info/2013/10/scrum-una-herramienta-para-el-po-cuanto.html
  6. Tomado de https://www.scaledagileframework.com/metrics/
  7. Evidence-Based Management Guide -https://www.scrum.org/resources/evidence-based-management-guide
  8. Sugerido por Paola Becerra - (ver su perfil aquí)


jueves, noviembre 21, 2019

Mi notas sobre OKR


Hola a todos

Quisiera aprovechar este post para compartir mis notas sobre OKR, tomadas de el artículo de Dan North - https://dannorth.net/2017/05/01/applying-okrs/





Para más información sugiero consultar mi banco de imágenes en: https://co.pinterest.com/jorge_abad/tips-management-y-management-30/okr-s/

Saludos ágiles

Jorge Abad








martes, noviembre 19, 2019

Frase: El mayor riesgo de todos sería no aceptar ninguno






"The biggest risk of all is not taking one." - Mellody Hubson




"El Mayor riesgo de todos sería no aceptar ningunto" - Mellody Hobson

La Transparencia, el Burndown Físico, el Kanban Fisico y el Efecto Hawthorne - Si me observas me comporto diferente

Tomado de 1


Hola a todos

Quisiera compartirles una conversación que constantemente sostengo con scrum masters, agile coaches, project leaders y diferentes de personas encargadas de equipos ágiles al momento de explicarles los beneficios de la transparencia y del sprint burndown chart físico y el kanban del sprint físico versus las herramientas digitales.

Y por qué no una herramienta

Siempre al abordar la forma de conocer el avance del equipo, hay una preferencia a sugerir Jira, o cualquier otra herramienta para tener registro de la finalización de ítemes de backlog (por lo general historias de usuario) y sus tareas durante un sprint.

Y la verdad eso no le veo lío, una herramienta digital me permite recolectar datos, saber estadísticas, concluir sobre comportamientos o problemas comunes.

Lo que observo es poco útil para facilitar la transparencia, pues siempre necesitaré hacer ingreso a una herramienta para saber el estado (tal vez me tome unos segundos, o alguien me pregunte algo y me distraiga o se me olvide), cosa muy distinta si tengo un burdown físico o un kanban físico al lado del equipo, siempre será facil ver y reconocer el estado sin preguntarle a nadie.


Tomado de 2 - Sugerencia de un Scrum Board 

Adicional que se genera el efecto Hawthorne, que es más efectivo el "RC - léase Erre Ce", es decir, la Respiración en el Cuello (4) o la pregunta frecuente:
"¿y cómo van?"
Pues el burndown y el kanban alcanzan a generar ese nivel de transparencia y compromiso.

Por lo tanto, es importante conocer el propósito de cada herramienta

  • la información digital me proporciona estadísticos 
  • y la información física transparencia 
es importante pues comprender esto y hacerle entender al equipo que no se está duplicando información, ambas tienen propósito distinto.

El Efecto Hawthorne

"El término fue creado en 1955 por Elton Mayo cuando analizaba antiguos experimentos realizados entre los años 1924 y 1932 en Hawthorne Works (una fábrica de la Western Electric a las afueras de Chicago). Los experimentos fueron coordinados por Elton Mayo, con la colaboración de Frist Roethlisberger, la Universidad de Harvard y el ingeniero de la Western Electric, William Dickson. En Hawthorne Works encargaron un estudio para comprobar la posibilidad de aumentar la productividad de sus trabajadores aumentando o disminuyendo las condiciones de iluminación ambiental. La productividad de los trabajadores pareció aumentar en el momento en el que se instauraron los cambios, y no sólo se produjo en los casos en los que los niveles de iluminación eran aumentados, sino también en aquellos casos en los que la iluminación se reducía. Al momento de terminar el estudio, los niveles volvieron a los niveles normales. La explicación sugerida fue que la mejora en la productividad no se debió a los cambios operados sobre los niveles de iluminación, sino al efecto motivador que supuso entre los obreros el saber que estaban siendo objeto de estudio." (2)


Por lo tanto podríamos concluir:
"si me observas me comporto diferente"


Los beneficios de la Gestión Visual

Adicional, contar con la información física nos permite obtener los beneficios de la gestión visual (5)
  • El 90% de la información transmitida al cerebro es visual
  • Las imágenes son procesadas 60.000 veces mas rápido que el texto
  • La gestión visual mejora la habilidad de aprender/comprender por encima del 400%

Cerrando

Bajo todo lo anterior mi recomendación sigue siendo,
"A pesar de que tengas un sistema para registro de avance de tu sprint, genera un burndown chart físico y un kanban de manera de que exista transparencia y todos podamos ayudar y conocer el estado del sprint de manera fácil"

Ventajas
  • No tengo que ingresar login y password
  • Es público
  • Es transparente
  • Implica foco, coraje y compromiso tanto al interior del equipo como hacia la organización
  • Todos sabrán si requerimos o se requiere ayudar
  • Si alguien nos pregunta como va el sprint le señalamos el tablero y seguiremos en lo nuestro (obvio cordialmente)
  • y por último (desde mi punto de vista) es más efectivo que el "Erre Ce"(4)

Sprint Burndown Chart Físico o en Papel

Sugerencias y Advertencias

  • Si tu equipo Scrum desde su creación registró su avance en herramientas digitales, haz el experimento del burndown físico, saca tus conclusiones y compártelas.
  • Esta práctica es muy útil en equipos coubicados, es decir todos en el mismo lugar
  • Si tu equipo es remoto, esta práctica es difícil de implementar, mas no imposible.
  • Una buena página para generar el burndown es - http://www.burndowngenerator.com/



Hasta acá este compartir, bienvenido el feedback

Saludos ágiles
Jorge Abad



Notas, Observaciones, Comentarios y Referencias

  1. Photo on Visualhunt.com
  2. https://agiledigest.com/agile-digest-tutorial-2/preparing-working-scrum-board-sprint-board-n/
  3. https://es.wikipedia.org/wiki/Efecto_Hawthorne
  4. RC - Erre Ce. Acrónimo que simboliza el micromanagement y su preguntas constantes y frecuentes como: ¿y cómo van? ¿les falta mucho? ¿cuánto les falta?, etc.
  5. https://ernestoolivares.es/pensamos-90-en-imagenes/

lunes, noviembre 18, 2019

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



sábado, noviembre 16, 2019

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