Tips para una PMO perdida en el Mundo Ágil

Tips para la PMO perdida en el Mundo Ágil from Jorge Hernán Abad Londoño

Tratar a las personas como personas

"In real life, the most practical advice for leaders is not to treat pawns like pawns, nor princes like princes, but all persons like persons"

- James MacGregor Burns

"En la vida real, el consejo más práctico para los líderes no es tratar a los peones como peones, ni a los príncipes como príncipes, sino a todas las personas como personas" 

. -James MacGregor Burns

---
Somos personas, no recursos.

Una Reflexión sobre el Costo del Retraso, DevOps y la Curva de Maersk

Hola a todos

Desde hace un tiempo vengo trabajando, e incluyendo en mis entrenamientos el concepto de Costo del Retraso (Cost of Delay), el cual desarrolló magistralmente Donald Reinertsen  en su libro The Principles of Product Development Flow, y una de sus frases más famosas es:

"Si solo puede cuantificar una cosa, cuantifique el Costo del Retraso" -Donald Reinertsen

Algunas definiciones de este concepto son:

Costo del retraso:

• El costo del retraso es "una forma de comunicar el impacto del tiempo en los resultados que esperamos lograr". (1)

• "¿Cuánto nos costaría si esto se retrasara 1 mes?"(1)

• "¿Qué valdría para nosotros si pudiéramos obtener esto 1 mes antes?"(1)

•  ¿Cuánto dejamos de ganar si nos atrasamos un mes?

• ¿Cuánto le cuesta a la compañía por unidad de tiempo no tener una funcionalidad liberada oportunamente?

Y justo con esta aproximación me encontré en el reporte de DevOps elaborado por DORA en https://devops-research.com/, en este informe, se observa la gráfica elaborada en Maersk por el equipo de desarrollo de un proyecto en donde se representa el costo del retraso/semana vs la cantidad de requisitos liberados en esa unidad de tiempo (del cual se infiere el Lead Time promedio del requisito). 

En esta gráfica se visualiza el costo del retraso generado por liberar tres requisitos por semana, sumando aproximadamente 7 millones de dólares, a liberar más de 23 requisitos en ese mismo periodo de tiempo y reduciendo este costo casi a cero.

Esta curva es asombrosa, pues genera consciencia de varios aspectos:

• la importancia de estar generando valor de forma continua
• el impacto en los ingresos de la organización de una estrategia de liberación pausada o continua
• cualquier esfuerzo de mejora en el ciclo de desarrollo de software y en su proceso de liberación, conlleva a un impacto económico que puede llegar a ser exponencial.
• la importancia de liberar continuamente para validar hipótesis y adaptarse rápidamente al mercado.
• la capacidad de validar hipótesis en un escenario de alto rendimiento es exponencial

Bajo este panorama surgen varias preguntas

• ¿Su organización mide el costo del retraso de sus proyectos?¿de uno solo? ¿de todo su portafolio?¿la PMO lo hace?
• ¿Como sería la curva costo del retraso por semana para los requisitos de tu organización o de tu proyecto?
• La discusión sobre si Ágil-DevOps es barato desaparece, la pregunta que aparece es 

¿qué tan costoso te esta saliendo no ser Ágil-DevOps (Agile-DevOps)?

• ¿cómo será la curva en los de alto performance, es decir, Google, Facebook, Amazon, Netflix, etc?

Hasta acá este compartir

Saludos Ágiles


Jorge Abad

Referencias, Comentarios, Notas y Aclaraciones

1. https://en.wikipedia.org/wiki/Cost_of_delay

Antipatrón: Solo liderar la primera línea y no gestionar la red

Hola a todos

Quisiera compartir uno de las disfunciones que he observado en la gestión de equipos y de las redes vinculadas a los mismos, convirtiéndose en uno de los obstáculos en los esfuerzos  de cambio cultural y de liderazgo hacia ambientes de más colaboración, adaptación al cambio, innovación, mejora continua, y generación de valor.

Utilizaré el esquema de antipatrón para compartirlo.

Antipatrón: El líder solo exige y promueve un alto estándar a su equipo y no gestiona la red  de personas y el ecosistema a cargo.

Problema: El líder solo gestiona su equipo adyacente exhibiendo y demandando valores de alto estándar pero no valida si su equipo y su entorno lo está haciendo, infiriendo o suponiendo que su equipo hará lo mismo con las personas a cargo.

Consecuencias:
existen varias consecuencias

• positivas: que todo su equipo exhiba y demande estos valores de alto estándar generando una cultura altamente positiva.
• negativas: 
• que parte de su equipo exhiba y comparta hacia la red un alto estándar de valores y otra parte del equipo no lo haga generando una cultura desigual y heterogénea
• que su equipo no exhiba los valores con los que son tratados y se generen resultados maltratando a las personas, con una cultura de presión, irrespeto y miedo.

Causas:

• Inocencia del líder
• Tolerancia del líder de cualquier estilo de liderazgo sin importar el trato que se le da a su red

Solución

En caso de que el líder este interesado en que su cultura de alto estándar se propague por el resto de su red se sugiere:

• no confiarse de evaluaciones 360
• realizar reuniones o conversatorios con cierta cadencia (mensual, bimestral o trimestral) con los equipos de la red para validar estilos de liderazgo

Se me vienen a la mente dos citas relacionadas con este tema:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar."- Gruenter and Whitaker, School Culture Rewired

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar"- Jurgen Appelo

Con base en lo expuesto en este post se le podría precisar algo a ambas citas:

"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar en su equipo de trabajo y toda la red de personas a cargo"

----

"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar en su equipo de trabajo y toda la red de personas a cargo"

y como dice Deming:“Todos ya están haciendo lo mejor que pueden; los problemas están con el sistema ... solo el management puede cambiar el sistema", pero el sistema somos nosotros (1) y como nos relacionamos, ahí se encuentra la clave para generar el cambio o promover un alto estándar de cultura y valores.

Hasta acá este compartir, bienvenidos sus comentarios.

Saludos Ágiles

Jorge Abad

Referencia

1. De Colección: Culpamos el sistema, pero el sistema somos nosotros  http://www.lecciones-aprendidas.info/2019/07/culpamos-el-sistema-pero-el-sistema.html

PMO - Una Propuesta de Responsabilidades y Nuevos Nombres en el Mundo Lean-Agile

Hola a todos

Relacionado con el post anterior sobre #NoProjects, se observa que el concepto de Proyecto para Desarrollo de Soluciones de Software en este entorno VUCA(1) no tiene mucho sentido, pues este va migrando a conceptos como:

• productos
• iniciativas
• épicas de negocio (2)
• flujos de valor
• value streams
• corrientes de valor
• cadenas de valor

Adicionalmente, las áreas que los coordinan también van migrando sus nombres a:

• Centro de Excelencia
• Centro de Excelencia Ágil 
• Centro de Excelencia Lean y Ágil
• LACE - Lean Agile Center of Excellence (3)
• Lean Portfolio Management Office (4)

De todo esto lo que me inquietan varias cosas

• ¿será que va a ocurrir lo mismo que con los Centros de Innovación? 
• Que solo el Centro de Innovación es responsable de la innovación en la organización y no es una capacidad requerida en toda la empresa (a propósito una mala aproximación al concepto)
• si estamos en entornos donde los productos y value streams son responsables de su flujo de valor y de sus resultados. 
• ¿Qué valor tiene que se gestionen como proyectos?, Pero más aun
• ¿Que valor tiene que otro trate de gestionar los recursos que estoy administrando de forma eficiente?
• Si decidimos llamar a la nueva PMO como "Centro de Excelencia Ágil" entonces se dedicará a medir: 
• ¿cantidad de equipos ágiles, cantidad de retrospectivas, etc? ¿es de valor medir esto? -obvio que no-.
• si la gestión de valor es realizada de forma excelente por los equipos de producto y value streams,¿tiene sentido una figura como una PMO o algo similar?

Responsabilidades de la "Nueva PMO"

Respecto a las funciones de esta "Nueva PMO" esta se podría dedicar entre otros:

• Promover el pensamiento (mindset) lean-agile
• Promover la experimentación (rapida y barata) que permita evolucionar o encontrar más fuentes de valor para la organización y sus clientes.
• Promover una cultura de obsesión por el cliente y la generación de valor
• Promover que la organización y su entorno sea medida como un reactor nuclear en tiempo real (Data Driven Organization)
• Promover y medir la salud emocional de todos los equipos de la organización, promoviendo su estabilidad y alto desempeño
• Medir la generación de valor de los diferentes:
• productos, 
• iniciativas, 
• value streams 
• y portafolios
• Identificar los impedimentos organizacionales, removerlos o ayudar a removerlos
• Identificar los riesgos organizacionales y trabajar en mitigarlos o reducirlos.
• Promover la mejora continua del toda la organización (Delivery, Áreas de negocio, Áreas de soporte), al igual que sus ciclos a todo nivel.
• Promover cadencias de sincronización y alineación tanto a nivel de equipo como de toda la organización.
• Ayudar a validar si las hipótesis de los Casos de Negocio (Business Cases), se están cumpliendo.
• Ayudar a que los procesos organizacionales sean cada vez más Lean

Haciendo un símil esta Nueva PMO se parece más a un Scrum Master Organizacional (ver 5):

• Promoviendo la generación de valor
• Promoviendo la excelencia y la mejora continua.

¿Y el Nombre?

Bajo este listado de responsabilidades un conjunto de nombres factibles para una Nueva PMO son:

• Grupo Promotor del Valor
• Grupo Promotor del Flujo de Valor
• Grupo Promotor del Pensamiento Lean-Agile

En últimas, el nombre es importante, pues da significado, pero las funciones que ejecute lo son más.



y ¿tu tienes alguna propuesta de nombre?

Bienvenido el feedback

Saludos Ágiles

Jorge Abad

Notas, Comentarios, Referencias y Observaciones

1. VUCA =  volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad, ver más en:
• https://es.wikipedia.org/wiki/VUCA 
• https://en.wikipedia.org/wiki/Volatility,_uncertainty,_complexity_and_ambiguity
2. https://www.scaledagileframework.com/epic/
3. https://www.scaledagileframework.com/lace
4. Basado en la propuesta de SAFe https://www.scaledagileframework.com/lean-portfolio-management/
5. http://www.lecciones-aprendidas.info/2017/03/softskills-scrum-master.html

Mi Encuentro con NoProjects - Una Cultura de Valor Continuo

Hola a todos


Desde que comencé a caminar en el mundo ágil vi como poco a poco el concepto de proyecto de software iba perdiendo fuerza en el mundo corporativo y comenzaba a tomar fuerza el concepto de producto de software (a continuación un tweet de hace unos años)

Veo cada vez más en la industria del software, el concepto de Producto mucho más fuerte que Proyecto.

— Jorge Hernán Abad L. (@jorge_abad) November 15, 2017

Aclarando sobre Proyectos y Productos

Pero para entender mejor en que nos estamos metiendo, comencemos por las definiciones:

Proyecto: "Es un esfuerzo temporal realizado para crear un producto, servicio o resultado único". (1)

La anterior es la definición técnicamente aceptada y elaborada por el PMI  -Project Management Institute . www.pmi.org, pero para producto la definición no es fácil de hallar, acá comparto algunas definiciones que tienen sentido en el propósito de este post:

Producto: Cosa producida ( tipica definición de la RAE)(2)
Producto: Un producto es una cosa o un objeto producido o fabricado, algo material que se elabora de manera natural o industrial mediante un proceso, para el consumo o utilidad de los individuos.(3)
Producto: un producto es un objeto o sistema disponible para uso del consumidor; Es todo lo que se puede ofrecer a un mercado para satisfacer el deseo o la necesidad de un cliente. (4)
Producto:

• algo que es fabricado, cultivado para ser vendido, usualmente es algo que es producido por un proceso

• Un servicio que los clientes pueden comprar de una organización financiera para invertir o ahorrar dinero

• algo que está disponible para la venta(5)

Producto: Del latín productus, se conoce como producto a aquello que ha sido fabricado (es decir, producido). Esta definición del término es bastante amplia y permite que objetos muy diversos se engloben dentro del concepto genérico de producto. De esta manera, una mesa, un libro y una computadora, por ejemplo, son productos. (6)

Producto: Cualquier bien material, servicio o idea que posee un valor para el consumidor o usuario y sea susceptible de satisfacer una necesidad.(7)

Podría entonces basado en lo anterior entender que un producto es elaborado y es de valor para un usuario o consumidor.

Basado en las anteriores definiciones se entiende que los proyectos de software:

• son finitos
• tienen alcance, tiempo, y costo fijos (importante ver la nota 12)
• tienen recursos definidos (importante ver la nota 12)

Implicando por lo tanto:

• se desarrollan en ambientes de certidumbre
• su seguimiento y éxito esta basado en la gestión del alcance, tiempo y costo incurrido.
• la administración de estos esté enfocada en la administración y optimización de los recursos (insumos, tiempo de las personas) y no en el valor generado.
• su enfoque de alcance definido, genere definición previa del alcance, adicionalmente que su adaptabilidad sea lenta y requiera procesos adicionales de control de cambios.

Generando algunas veces que estos:

• cuenten con bajo involucramiento del negocio
• cumplan el alcance pero no generen valor
• usen sus recursos definidos pero no generen valor.

Mientras, los productos de software

• nacen
• no tienen una fecha de finalización prevista
• pueden ser construidos por uno o varios proyectos, o por un enfoque diferente
• pueden construirse en escenarios de certidumbre como de Altísima Incertidumbre
• pueden o no evolucionar
• morirá el día que deje de ser rentable su uso o existencia
• el alcance es un medio para generar valor
• pueden alcanzar valor antes o después de lo planeado
• están radicalmente enfocados en la generación de valor (o ¿Quién quiere hacer un producto que nadie va a usar?), por lo tanto validan si generan valor o no.
• Su éxito no se mide en cumplimiento o la gestión optimizada de recursos sino en el valor generado.
• Requieren de involucramiento del negocio

Algunas veces es posible no se construya el producto correcto, pero esto se puede solucionar con validaciones tempranas con Productos Mínimos Viables - o MVP por sus siglas en inglés-  propuesta por Lean Starutp, y liberaciones o releases frecuentes que permitan retroalimentación de los usuarios y el mercado.

Mi encuentro con #noprojects

Justo en esa búsqueda de entender más sobre:

• productos
• cadenas de valor (value streams)
• épicas de negocio (como las llamaría SAFe (8))
• o iniciativas

 y como su gestión se diferencia de la gestión de proyectos, (la actualmente no aplica para el mundo del desarrollo de software(9)), me encontré hace unos meses con #noprojects - https://noprojects.org -  y el minilibro publicado en infoq.com - #noprojects - A Culture of Continuous Value (clic aquí) de Evan Leybourn y Shane Hastie, que explica una cultura orientada a la gestión del valor y como podemos tener éxito en ese enfoque.

A continuación comparto dos imágenes que he traducido, y que son bastante útiles para entender este paradigma.

Referencia : https://twitter.com/rkasper/status/1032251628143882240

#noprojects

Triangulo de #noprojects (10)

Triángulo de #noprojects traducido

Queda entonces la tarea de quedarse con estas imágenes o ir leerse el libro.

Les dejo con esta frase de Mark Twain (o al menos se la atribuyen a él)

Saludos ágiles

Jorge Abad

Notas, Comentarios, Referencias y Observaciones

1. “It's a temporary endeavor undertaken to create a unique product, service or result.”.https://www.pmi.org/about/learn-about-pmi/what-is-project-management
2. https://dle.rae.es/?id=UH9P99t
3. https://www.significados.com/producto/
4. Traducido de wikipedia - https://en.wikipedia.org/wiki/Product_(business)
5. https://dictionary.cambridge.org/es/diccionario/ingles/product
6. https://definicion.de/producto/
7. http://www.diclib.com/cgi-bin/d.cgi#.XWNHs-j0nIU#ixzz5xfhGQ3il
8. https://www.scaledagileframework.com/epic/
9. Este tópico no lo resolveré acá, pues es justo la explicación de por qué hoy los métodos ágiles son más exitosos que los tradicionales y hay cientos de post en ingles y español sobre esto.
10. Referencia https://twitter.com/fbnkss/status/1133762339373813760
11. Adicionalmente el ciclo de vida de proyectos y producto es distinta
• proyecto = inicio, organización y preparación, ejecución y cierre
• producto = introducción, crecimiento, madurez y retiro
12. Felipe García compañero de la Ágiles Colombia me hacia la precisión que los proyectos tienen: alcance, costo, tiempo, riesgos, recursos y calidad, en total seis restricciones, cosa cierta, pero los esquemas de contratación tradicionales solo manejan estas tres variables (alcance, tiempo y costo) y penalizan al proveedor diciendo: "¡usted debe hacerse cargo de los recursos, la calidad y los riesgos, para eso los contratamos!",  - ¡hágame el bendito favor, que descaro!(clic aquí para regresar)

Una propuesta para Daily de un equipo Kanban

Hola a todos

Según la Guía de Scrum -https://scrumguides.org/ - respecto al daily afirma: "El Equipo de Desarrollo es el encargado de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia la Meta de Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más en discusiones.

• ¿Qué hice ayer que ayudó al Equipo de Desarrollo lograr el Objetivo del Sprint?
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?"

Algunos equipos Scrum siguen haciendo las famosas tres preguntas

• ¿Qué hice ayer?
• ¿Qué voy hacer hoy?
• ¿Qué impedimentos tengo?

Aun así lo que sugiere la guía respecto a preguntarnos "¿si vamos a lograr el objetivo?" es un elemento clave para generar incrementos de valor en el marco Scrum, pero este post es sobre Kanban, y en este modelo de trabajo lo que existe es un flujo continuo (se espera sea de valor, para el negocio o para el equipo), y para este tipo de equipos también se sugiere una sincronización diaria, a continuación les comparto una sugerencia para preguntas o afirmaciones para esta reunión corta de no máximo 15 minutos:

• Afirmaciones o preguntas compartir por cada miembro del equipo:
• ¿en qué he estado trabajando?
• ¿qué necesito para cerrar lo que tengo en curso?
• tengo impedimento(s) y es/son :____________/ no tengo impedimentos
• yo me ofrezco a ayudar con__________
• yo me ofrezco ayudar a________
• un facilitador o líder del equipo podría al final del daily de cada mienbro de equipo, podría preguntar:
• ¿quien necesita ayuda?
• ¿en que estado están los impedimentos?¿como hacemos para resolverlos?
• ¿algo importante a compartir que debamos saber todos?

El facilitador o líder del equipo y el equipo mismo, deben poner foco en:

• desbloquear el flujo
• enfocarse en cerrar tareas
• terminar de abrir

Una sugerencia para equipos o dueños de una actividad o proceso

En caso de que el daily sea realizado por varios equipos o personas encargadas de una parte del proceso, se sugiere realizar el daily comenzando por la persona o equipo que finaliza el proceso y terminar con el que comienza, de esa manera nos enfocamos en terminar cosas y no en abrir.

hasta acá este compartir

Saludos ágiles

Jorge Abad.

Unas diapositvas para entender qué significa hacer realmente una Transformación Ágil

Qué significa hacer realmente una Transformación Ágil de Jorge Hernán Abad Londoño

Podcast: ¿Qué es el Agilismo y para qué sirve?

Un mal líder puede estropear la cultura y el sistema

Quisiera aprovechar el blog para compartir algo que he visto y que todos sabemos

"Un mal líder puede estropear la cultura y el sistema"

Me explico, en este trasegar acompañando organizaciones en su transformación hacia la agilidad he visto de todo, tal como:

• organizaciones llenas de procesos con equipos muy dinámicos dando excelentes resultados
• organizaciones sin procesos detallados con resultados lentos
• organizaciones con procesos de adorno
• organizaciones con líderes inspiradores y líderes desmotivadores
• y toda clase de combinación pervesa, positiva y mediocre de las anteriores

Llevándonos a decir con Deming

Y en esa misma dirección recordé ésto que publiqué hace un tiempo en linkedin.

Cosa cierta, pero cada vez creo que esto de culpar al sistema, la cultura, los incentivos, los procesos, las métricas, los kpi, etc. es una excusa frecuente, cuando muchas veces una de las causas raíces a muchos problemas sistémicos son:

• el liderazgo
• y la forma como interactuamos

Es por tanto clave intervenir tanto el liderazgo como la forma como interactuamos, pero primeramente el liderazgo, sino será muy poco lo que podamos mejorar en el sistema y la cultura.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

De Colección: Culpamos el sistema, pero el sistema somos nosotros

Me encanta esta cita de Seth Godin

https://seths.blog/2016/06/the-problem-with-complaining-about-the-system/

The problem with complaining about the system …is that the system can’t hear you. Only people can. And the problem is that people in the system are too often swayed to believe that they have no power over the system, that they are merely victims of it, pawns, cogs in a machine bigger than themselves. Alas, when the system can’t hear you, and those who can believe they have no power, nothing improves. Systems don’t mistreat us, misrepresent us, waste our resources, govern poorly, support an unfair status quo and generally screw things up–people do. If we care enough, we can make it change.

Que podría traducirse como:

El problema de quejarse acerca del sistema ... es que el sistema no te oye. Solo la gente puede oir. Y el problema es que las personas en el sistema a menudo se sienten inclinadas a creer que no tienen poder sobre el sistema, que son simplemente víctimas de él, peones, piñones en una máquina más grande que ellos mismos. Por desgracia, cuando juntas que el sistema no puede escucharte, con aquellos que creen que no tienen poder, nada mejora. Los sistemas no nos maltratan, no nos tergiversan, no malgastan nuestros recursos, no gobiernan mal, no apoyan un status quo injusto y, en general, no arruinan las cosas, las personas lo hacen. Si nos importa lo suficiente, podemos hacerlo que cambiar.

Mi opinión sobre SAFe (Scaled Agile Framework): sí, es un buen comienzo y resuelve ciertos problemas de escalado

Constantemente leo y escucho dentro del mundo ágil: fanáticos, detractores, amigos por conveniencia, amigos con derechos, relaciones casuales y relaciones duraderas, affairs, mercenarios, fundamentalistas y todo tipo de relaciones con los frameworks, métodos y metodologías que caen en la sombrilla del Manifiesto Ágil (clic aquí) y eso es bueno, pues genera interesantes discusiones, conclusiones y fuentes de aprendizaje.

En este camino he aprendido que no hay recetas únicas para resolver problemas que tienen los equipos de trabajo que hacen soluciones de software. Desde el punto de vista ágil me declaro Scrum por fuera y Kanban por dentro - pongo de manifiesto que cualquier framework ágil sin excelencia técnica es un desperdicio y dolor de cabeza -, de ahí en adelante lo que funcione será útil para mí, o sea, en pocas palabras soy un mercenario del escalado de ágil.

A nivel de frameworks he trabajado en el mundo ágil con:

• Kanban
• Scrum
• Scrumban
• Playbacks (para BPM)
• Scrum de Scrums
• Nexus
• SAFe
• Scrum@Scale
• y en compañía con el equipo de profesionales que trabajo actualmente también hemos generado nuestros híbridos y combinaciones.

Y aunque confieso que cuando vi el diagrama de SAFe - Scaled Agile Framework me asusté y me pareció algo complejo, quisiera compartir en este post lo que he vivido con el framework (1), cuándo recomiendo desplegarlo, los problemas que he visto que soluciona, y sus beneficios. Comencemos entonces.

Algunos problemas sistémicos escalando la agilidad

Cuando he trabajado escalando ágil con más de 3 equipos con el mismo Product Backlog, en grandes organizaciones me he topado con los siguientes problemas:

• Product Owners que no están al menos tres sprints adelante de su equipo realizando definiciones y resolviendo dependencias
• Product Owners reactivos (similar a la anterior)
• Pobre gestión de dependencias entre equipos (consecuencia de la primera)
• Crecimiento de la complejidad
• Poca o nula comunicación entre equipos
• Se excede la capacidad de los equipos de soporte (infraestructura, riesgos, pruebas no funcionales, legal, etc).
• No se mejora sistemáticamente

y aunque todo esto se podría resolver sin el marco de SAFe, en organizaciones grandes cuesta generar este tipo alineación y sincronización debido a que su cultura actual - que es justo la que se quiere dinamizar y aumentar la colaboración - no les permite espacios para este tipo de coordinación

Cuándo recomiendo comenzar con SAFe

Considerando lo anterior cuándo recomiendo comenzar con SAFe:

• Existe una cultura de gestión tradicional muy fuerte
• Existen al menos 4 equipos trabajando con el mismo Product Backlog
• Los Product Owner no tiene dedicación de al menos el 50% para ejecutar el rol correctamente.
• Se están presentando problemas de gestión de dependencias y
• Se están presentando problemas de gestión de la capacidad de las áreas de soporte

Algunos Beneficios

A continuación comparto algunos beneficios conseguidos en las implementaciones de SAFe que he acompañado, así como algunas que he conocido en la industria:

• Beneficios Generales
• Usa Scrum y Kanban como base, lo que permite una mejora sistemática
• Mínimo cada dos semanas hay software funcionando
• Se sale a producción por demanda
• Se tiene al cliente como fundamento y validación de hipótesis
• El latir de Program Increment comienza a dinamizar las organizaciones y a fuerza del hábito termina agilizando el entorno.
• SAFe y cualquier marco ágil requiere de excelencia técnica y de DevOps, SAFe lo pone de forma explícita como insumo para su ejecución.
• La demo gigante al final del ciclo del Program Increment genera un espacio de celebración que genera motivación a los participantes y a la par "presión" social para equipos que han decidido no trabajar con el profesionalismo mínimo que deberían tener.
• Beneficios Asociados al Program Increment Planning  (PI Plannig)
• Genera Product Owners proactivos, pues deben estar adelantados al menos 2 o 3 meses en su horizonte de tiempo para la sesión.
• Durante los dos días de PI Plannig genera alineación entre equipos y la organización
• Se resuelven dependencias entre equipos, áreas de negocio y áreas de soporte
• Los equipos de un mismo programa se alinean con el propósito de la solución
• Los equipos del programa se ayudan entre sí, pareciendo una gran tribu. He visto a estos equipos:
• tomar historias de usuario de otros equipos
• probar software que otros equipos hicieron
• expresar su disponibilidad para ayudar a otros
• inquietarse como programa
• celebrar juntos como programa
• Existe validación de capacidad por áreas de soporte
• No permite avanzar con supuestos irreales,
• Permite identificar un plan factible (no fijo) para el próximo ciclo de 2 a 3 meses, es decir un plan sobre el cual se puede hacer inspección y adaptacion.

Si deseas un ejemplo de resultados organizacionales generados con el framework de SAFe te recomiendo el link de la referencia (1).

Y las Conclusiones

A continuación comparto algunas conclusiones:

• SAFe en su nivel esencial (o sea a nivel de programas) lo considero un buen comienzo, para agilizar la organización, los otros niveles (Portafolio, Grandes Soluciones, Full SAFe) contienen prácticas que son buenas guías, pero las organizaciones determinarán cuales implementar y cuales no.
• No he conocido la primera gran organización que ha desplegado el 100% de SAFe
• Es un buen comienzo, propone soluciones interesantes a nivel de portafolio y de priorización
• Su orientación a flujos de valor - value streams -, propuesta por muchos en el Mundo Ágil, resuelve problemas sistémicos generados por los silos
• Sugiero desplegar SAFe con Scrum@Scale para dinamizar la toma de decisiones, y acelerar el flujo de información a nivel organizacional, tanto horizontal como vertical.
• SAFe es un medio, no el fin en sí, lo que se quiere es proporcionarle a la organización la capacidad de adaptarse al entorno de forma dinámica.
• En caso de que la organización fuera proclive a la agilidad, prefiero un enfoque más orgánico con una combinacion de Design Thinking + Scrum + Kanban + DevOps y prácticas de Scrum@Scale

Por último, quienes no lo han vivido, los invito a experimentarlo,  ver las sinergias organizacionales que son consecuencia de implementar el marco y después compartan sus experiencias, de esa manera todos crecemos.

Hasta acá este compartir.


Saludos ágiles

Jorge Abad

Notas, Comentarios, Referencias y Observaciones

1. Testimonio de uno de los clientes en los que he participado en el despliegue de SAFe -Innovación en Claro para beneficio de sus clientes (clic aquí), los videos juntos los puedes ver aquí.
2. Agradecimientos a mi amigo Lucho Salazar por su revisión y feedback en este articulo

Más de un millón de mejoras en el año en Toyota

Hola a todos

Con frecuencia citamos cosas por que las hemos escuchado de personas que son relevantes para nosotros y que son referentes.

Hace un tiempo escuché y constantemente compartía algo que varios referentes decían:

 "En Toyota se hacen más de un millón de mejoras en el año con su proceso de mejora continua o Kaizen"

Decidí averiguar la referencia a esa cita y un agilista, Hugo Suaréz me proporcionó la referencia exacta,

Kaizen, la clave de la cultura Japonesa por Masaaki Imai

y la Cita exactamente reza:

"Una de las características de los trabajadores japoneses es que usan tanto el cerebro como las manos. Nuestros trabajadores proporcionan 1.5 millones de sugerencias al año y el 95% de ellas se ponen en uso práctico. Existe un interés casi tangible por el mejoramiento en el aire de Toyota" 

Eiji Toyoda, Presidente del Consejo de la Toyota Motor.

Gracias Hugo por la referencia y esta es una invitación a no detenerse, quiero invitarlos a:

no caer en la tentación de realizar mejora continua por que lo dice el proceso, el framework, el marco, la metodología, o la norma, esta aproximación es una mala interpretación del método de Toyota y se aleja radicalmente del propósito del Kaizen, hay que hacer mejora continua por que es la única forma de hacernos inalcanzables.

Gracias a mis amigos y referentes que han compartido información que es verídica y comprobable, suena obvio, pero es importante saber a que líderes seguir en el mundo empresarial y de la agilidad.

Saludos ágiles


Jorge Abad

Una idea sobre cultura, propósito, principios, valores y procesos

Una conclusión a partir de tantas lecturas y observaciones:

"Los procesos no alcanzan a legislar sobre todo lo que ocurre en una organización y en ausencia de procesos: los valores, principios y cultura de la organización guiarán a lo colaboradores ante cualquier situación, incluso sobre cualquier proceso definido previamente.

Una buena cultura, principios y valores te guiarán al éxito, similar en caso contrario."

Una versión de Casca-Agile(TM) o Casca-Scrum: tener "Sprint de desarrollo y luego Sprint de pruebas"

Hola a todos

Hace unos años en Ciudad de México dictando un entrenamiento de Scrum y Principios Ágiles, en el momento de hablar de malas prácticas, uno de los asistentes (y amigo mío Ulises Soriano), bautizaba como:

Casca-Agile (TM)

cuando se tomaban cosas del mundo ágil y del de cascada, pero con el pésimo resultado de que no se obtenía ni la "predictibilidad" añorada de cascada, ni la adaptabilidad de Scrum.

Esté termino lo he seguido usando desde ese entonces, y luego de tener la oportunidad de compartir con tantas organizaciones a nivel Latinoamérica he observado que hay una versión de Casca-Agile común a muchas empresas que no quieren adoptar la agilidad por completo: y es que contratan a un proveedor para que haga Scrum en el desarrollo del software y otro proveedor para que haga Scrum en las pruebas, olvidando lo que tanto se enuncia el marco Scrum en dos apartes:

"El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento."(1)

"Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;"(1)

Esa versión de Casca-Agile o Casca-Scrum, termina viéndose así:

Añadiendo al menos 3 sprints (pueden ser más) entre el desarrollo de la historia de usuario y el lograr la "certificación"por parte de pruebas

Las desventajas que esto genera

• Largos tiempo de entrega del incremento (al menos tres sprints más)
• La imposibilidad de revisar el incremento completo cuando se termina cada sprint de desarrollo por parte del PO.
• Bajo involucramiento del PO
• La Definición de Terminado o "Definition of Done" toma mucho tiempo para que sea completamente alcanzada por ambos equipos
• la responsabilidad sobre el producto construido no existe.
• Gestion de ANS (acuerdos de niveles de servicio) que no agregan valor y desfiguran el marco de Scrum.
• El equipo de testing no esta sintiendo la construcción incremental del producto y por lo tanto no se sienten responsables del la buena construcción del mismo
• Esto no es Scrum y se aleja de la agilidad pues no cumple ni con la definción de Scrum, ni con los valores y principios del manifiesto ágil (2)
• A esto muchos se atreven a llamarlo Scrum, sabiendo que no lo es, o lo llaman "Scrum pero" (o ScrumBut (3)), y si no les funciona le echan la culpa a Scrum.

Las ventajas

• Le pienso y le pienso y no lo encuentro, puede que saboreen un poco las mieles del desarrollo iterativo e incremental, pero deja mucho que desear.

Solución a este antipatrón

La "falsa sensación de seguridad" de tener dos contratos, uno para el proveedor de desarrollo y otro para el proveedor de pruebas, se resuelve sentándolos juntos en una sola mesa y siendo ambos responsables de la calidad del producto entregado, cada sprint.

Cerrando

Bien parafrasean muchos a Jeff Sutherland,

"el peor enemigo de Scrum, es un mal Scrum" 

o mejor como él lo dice:

Referemcia(4)

Hasta acá este compartir, bienvenidos los comentarios y experiencias.

Saludos ágiles
Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. La Guía Oficial de Scrum - https://scrumguides.org/
2. Manifiesto por el Desarrollo Ágil de Software -https://agilemanifesto.org/iso/es/manifesto.html
3. Una excelente definición de ScrumBut - https://www.scrum.org/resources/what-scrumbut
4. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
5. Si deseas ver más disfunciones de Scrum y de Ágil, haz clic aquí. http://www.lecciones-aprendidas.info/2019/04/malos-olores-en-transformaciones-agiles.html

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded from Jorge Hernán Abad Londoño

DevOps sin Gestión por Valor También es Desperdicio

Podemos tener el mejor Pipeline de DevOps, pero si no existe: Priorización de Portafolio  Priorización de Product Backlog y validación de hipótesis a nivel de iniciativas y épicas. Seguiremos generando desperdicio y perdiendo costo de oportunidad.

We could have the best DevOps Pipeline, but if it does not exist: Portfolio Prioritization   Product Backlog Prioritization  and hypotheses validation at level of initiatives and epics.. We will continue generating waste and losing opportunity cost.

---

Podemos tener el mejor Pipeline de DevOps, pero si no existe:
- Priorización de Portafolio
- Priorización de Product backlog
- y validación de hipotesis a nivel de iniciativas y épicas.

Seguimos generando desperdicio, y perdiendo costo de oportunidad.

— Jorge Hernán Abad L. (@jorge_abad) May 15, 2019

---

We could have the best DevOps Pipeline, but if it does not exist:
- Prioritization of Portfolio
- Prioritization of Product Backlog
- and hypotheses validation at level of initiatives and epics.
We will continue generating waste and losing opportunity cost. #Agile #DevOps

— Jorge Hernán Abad L. (@jorge_abad) May 15, 2019

---

Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática

Hola a todos

En el pasado ScrumDay en Perú 2019, mi estimado compañero y amigo Lucho Salazar tuvo la oportunidad de presentar un poco sobre nuestra experiencia y visión sobre las historias de usuario en la charla: "Historias de usuario: todo lo que querías saber y no te atreviste a preguntar", la cual resumía algunos de los aspectos plasmados en el Libro "Historias de Usuario: Una Visión Pragmática" que publicamos en el pasado Ágiles 2018 en México. En esta presentación se toco uno de los temas que hemos observado que más genera polémica y es los diferentes modos de representación, todos creemos que el

"yo como usuario 

deseo esta funcionalidad 

para este beneficio"

es el estándar y no, no lo es, es solo una propuesta de formato hecha por Mike Cohn, en últimas lo que recomiendan muchos expertos, autores, al igual que nosotros es:

"cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."(1)

Dentro de estos modos de representación Lucho y yo hemos identificado cinco modos de hacerlo, los cuales pueden ser usados de acuerdo al a madurez del Equipo y del Product Owner y del contexto en que se encuentren. A continuación presentamos un ejemplo desarrollado en el libro, y que sirve como base para esta explicación:

---

---

---

---

---

---

---

Aprovecho esta oportunidad para invitarlos a compartir su conocimiento y experiencias, de esa manera todos creceremos más.


Como siempre, bienvenida la retroalimentación.

Saludos Ágiles

Jorge Abad y Lucho Salazar

Notas, Aclaraciones, Comentarios y Referencias

1. La representación de Historias de Usuario no exime de cumplir las 3 Cs, el criterio Invest y muchas prácticas recomendadas en el libro y los post de Lucho y míos sobre este tópico:
• http://www.lecciones-aprendidas.info/search/label/Historias%20de%20Usuario
• http://www.gazafatonarioit.com/search/label/historias%20de%20usuario

Propuesta de preguntas para la reunión de Scrum de Scrums (Scrum of Scrums)

Hola a todos

A continuación les presentamos unas recomendaciones para una buena reunión de Scrum de Scrums (Scrum of Scrums), o de sincronización de varios equipos ágiles que están trabajando con un mismo Product Backlog o Iniciativa.

Este post fue redactado conjuntamente con mis compañeros:

• Augusto Miní
• Lucho Salazar
• Ricardo Cruz

Ahora sí al grano:


Frecuencia

• Al menos una vez a la semana, 
• Deseable diariamente.

Timebox

• 15 a 30 Minutos

Preguntas

• ¿Existieron problemas en la integración del código y en las pruebas integrales del producto el día anterior?
• ¿Qué impedimentos tienen que debamos gestionar a nivel de equipos? *
• ¿Qué dependencias o riesgos tienen o estan próximos a activarse?
• ¿que información consideran que debe ser compartida con todos los equipos?
• ¿Creen que van a bloquear a alguien?
• ¿Alguna mejora encontrada que deba ser compartida con todos los equipos?
• ¿Alguna ayuda adicional que requieran?
• ¿Pueden ofrecer ayuda?

*Nota: los impedimentos, bloqueos y riesgos que se presenten a este nivel corresponden al programa entero, no deben ser presentados los que corresponden al equipo y al ámbito del Scrum master.

Recomendaciones
Estas preguntas deben tener la misma dinámica del daily:

• Solo se expone lo que se está preguntando.
• El facilitador debe generar este foco 
• Luego, en una reunión inmediatamente después (o Meet After) de este Daily de Scrum de Scrums, se resolverán los elementos factibles a resolver
• Se sugiere que los elementos que no puedan ser resueltos se plasmen en un kanban impedimentos y riesgos del programa, con responsable y/o responsables asignados.

Saludos ágiles
Jorge Abad

Referencias, Notas, Aclaraciónes y Comentarios

1) Scrum de Scrums en SAFe  - https://www.scaledagileframework.com/program-increment/

2) Scrum de Scrums en Nexus - https://www.scrum.org/resources/nexus-guide 

• ¿El trabajo del día anterior fue integrado exitosamente? Si no fue así, ¿por qué no? 
• ¿Cuáles nuevas dependencias han sido identificadas? 
• ¿Qué información necesita compartirse entre los equipos del Nexus? 

3) Scrum de Scrums en Scrum at Scale - Scrum@Scale - https://www.scrumatscale.com/scrum-at-scale-guide-read-online/

• What impediments does my team have that will prevent them from accomplishing their Sprint Goal (or impact the upcoming release)?
• Is my team doing anything that will prevent another team from accomplishing their Sprint Goal (or impact their upcoming release)?
• Have we discovered any new dependencies between the teams or discovered a way to resolve an existing dependency?
• What improvements have we discovered that can be leveraged across teams?

Malos Olores en Transformaciones Ágiles - Bad Smells in Agile Transformations - Scrumday Perú 2019

Bad smells in agile transformations comunitaria - v20190427 from Jorge Hernán Abad Londoño