Retrospectivas - Coffee Talks by CertiProf con Jorge Abad - Video

Cita: Nuestro trabajo no es fabricar productos, sino mejorar el proceso de cómo los fabricamos

 

Referencias

• 2 Second Lean Book - https://paulakers.net/books/2-second-lean

Mis notas sobre la charla "El Corazón de la Agilidad" de Alistair Cockburn

Hola a todos

Hace poco mi gran amigo y líder técnico Daniel Ramirez, publicó las notas de la sesión que asistimos sobre el Corazon de la Agilidad de Alistair Cockburn - en Pragma el pasado mes de noviembre de 2019 -  https://contactosagiles.co/aoc-colombia-2019/el-corazon-de-la-agilidad/ -, yo también dejar un pequeño registro de ciertas frases contundentes que nos compartío Alistair en esta excelente sesión:

---

El corazón de la agilidad se basa en:

• colaboración
• entrega
• reflexión
• mejora

---

Combinando estas palabras se obtiene

• colabora para entregar
• entrega para reflexionar
• reflexiona para mejorar
• mejora la colaboración
• colabora para mejorar
• colaboramos para tener mejores ideas
• entrega para aprender
• la mejora reflexiva (es la inspección y adaptación de scrum)
• pausa para reflexionar (obvio no es una combinación)
• mejora para cambiar el mundo (obvio no es una combinación)
• mejora el sistema de entrega

---

Los tres estados del aprendizaje

• Shu - seguir la técnica
• Ha - agregar técnicas diferentes, romper la regla
• Ri-  dejar el dojo

---

Concepto clave Kokoro:

• esencia o corazón de algo
• simplificación radical de conceptos

---

Al hacer una transformación en una organización se debe buscar:

• no intentar cambiar la cultura
• aumentar la confianza
• reducir el miedo
• mejorar la interacción
• mejorar el sistema de entrega
• mejorar la conversación entre las personas

---

Respecto a la gerencia de proyectos y a los errores

• una empresa es una fábrica de ideas
• una idea es precursora de una decisión
• las decisiones son las molécula de lo que hacemos y entregamos al mundo
• cada producto tiene mas de 100.000 decisiones
• cada decisión es una posibilidad de error
• El "ARTE" de la gerencia de proyectos se basa hoy en día en DESCUBRIR LOS ERRORES LO MÁS TEMPRANO POSIBLE
• debido a lo anterior, entregamos lo antes posible para obtener feedback y evitar avanzar en la dirección equivocada

---

Preguntas para mejorar un equipo, un área, una organización:

Qué hacemos para: - Mejorar nuestra colaboración - Mejorar nuestra reflexión -Mejorar nuestra mejora

---

Notas y frases varias:

• si mi mundo es de contratación tradicional, es decir, alcance tiempo y costo fijo, sugiere hacer contratos de tres meses para poder adaptarnos dentro de esas restricciones
• Valor: el cliente sabe lo que es valor
• Una empresa será más ágil entre más NATURAL le podas dar MALAS NOTICIAS AL JEFE
• Debemos mejorar la conversación entre las personas
• el corazón de la agilidad es un recordatorio, no un proceso
• "Show me the feedback loops"
• Una métrica importante: ¿cuántas veces por dia o semana se interrumpe el trabajo del desarrollador?
• "Todo lo que se diga puede ser malinterpretado o malutilizado y no se puede escoger cual de ellos dos sucederá"
• "El corazón de la agilidad está en descubrir los errores y dar las malas noticias"
• SAFe que es nivel shu
• La resistencia al cambio es normal
• Cambia poco a poco

---

Otras imágenes de su pasada por Medellín

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272

"Nuestro trabajo en la Agilidad es dar las malas noticias temprano, simplemente porque es menos costoso"

---- 

"Agilidad es encontrar errores más rápido, y si no se los podes contar a tu jefe y virar, ¿para qué haces Agilidad?

---- 

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272

Tomado de: https://twitter.com/pablitux/status/1198710728707973121

---

Hasta acá este compartir

Video de la charla: http://www.lecciones-aprendidas.info/2022/09/video-corazon-de-la-agilidad-alistair.html


Saludos ágiles

Jorge Abad

De Colección: ¿Y tus retrospectivas cuándo van a ser de tipo Élite?

Tomado de (1)

Hola a todos

Uno de los informes que más ha tomado fuerza dentro del mundo Ágil y de DevOps es el elaborado por DORA (DevOps Research and Assessment): "Accelerate: State of DevOps", en la versión de 2018 "Accelerate: State of DevOpsStrategies for a New Economy 2018"(1)(clic aquí), en su capítulo "Influencing culture through learning" se encuentra este interesante texto

"We found that learning reviews help contribute to a climate for learning and also impact organizational culture. It is important to note that this is true when teams conduct them to learn from their mistakes and failures and then turn these into opportunities to improve how they work. In particular, teams that leverage findings from retrospectives to implement changes to tooling, processes, or procedures see the strongest impacts.

Our analysis found that elite performers are 1.5 times more likely to consistently hold retrospectives and use them to improve their work. When we asked respondents about their most recent retrospective, we see common themes around outages, failures, performance, and deployment."

Traducido

"Descubrimos que las revisiones de aprendizaje ayudan a contribuir a un clima para el aprendizaje y también impactan la cultura organizacional. Es importante tener en cuenta que esto es cierto cuando los equipos los conducen para aprender de sus errores y fracasos y luego los convierten en oportunidades para mejorar su funcionamiento. En particular, los equipos que aprovechan los hallazgos de las retrospectivas para implementar cambios en las herramientas, procesos o procedimientos ven los impactos más
 fuertes.

Nuestro análisis encontró que los Jugadores de Élite tienen 1.5 veces más probabilidades de tener retrospectivas consistentemente y usarlas para mejorar su trabajo. Cuando preguntamos a los encuestados acerca de su retrospectiva más reciente, vemos temas comunes sobre interrupciones, fallas, rendimiento y despliegue."

Luego comparten esta nube de temas que se discuten en los equipos élite en el mundo

Tomado de (1)

El listado de palabras en orden alfabético las encuentras al final del post(3).

Invitación

Una de las recomendaciones e invitaciones que hago a los Scrum Masters, Facilitadores, Líderes Ágiles y Equipos de Desarrollo que tienen cierta madurez haciendo Scrum o cualquier otro marco es:

"tarde o temprano tus retrospectivas tienen que hablar del tema técnico, o ¿vas a seguir perfeccionando la comunicación y el proceso en el sprint 20 y siguientes?, es urgente que veas el elefante en el cuarto si quieres llevar a tu equipo al alto desempeño"

No estoy afirmando que: "no sea necesario mejorar el proceso y el trabajo en equipo", si hay que mejorarlos se hace, pero el tema técnico es un tema obligatorio a tocar en las retrospectivas, y más si deseas alcanzar alto desempeño.

Scrum Master y Equipo evitando hablar del tema técnico

Basado en la sugerencia anterior he escrito y compartido post similares en el pasado:

• Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo (clic aquí)
• Presentación: Los puntos ciegos del Scrum Master (clic aquí)

Quedan entonces dos preguntas

• ¿de qué tema hablaron en la última retrospectiva de tu equipo?

• ¿y tus retrospectivas cuándo van a ser de tipo Élite?

Hasta acá este compartir.

Bienvenido el feedback

Saludos ágiles
Jorge Abad

Notas, Referencias, Aclaraciones y Comentarios

1. Accelerate: State of DevOps. Strategies for a New Economy 2018 - https://inthecloud.withgoogle.com/state-of-devops-18/dl-cd.html 
2. Accelerate: State of DevOps 2019- https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
3. El listado de palabras de la nube en orden alfabético es el siguiente:
   

able access analysis api app application architecture automated automation availability aws bad behavior breach broken bug bugs build business capacity cases cause caused certificate change changes client cloud cluster code collaboration communication communications config configuration container cpu crash critical customer customers data database deadlines defect defects degradation delivery dependencies deployed deployment

deployments design development devops disaster disruption dns documentation done dont downtime due efficiency email environment environments error errors external failed failing failure failures feature features feedback firewall functional functionality gaps hardware high human implementation improve improvement improvements incident incidents incomplete incorrect infrastructure integration issue issues kafka know knowledge

lack last learning lessons load loss major management manual many migration mismatch missed missing mistakes monitoring mortems needed network networking new none nothing one operational outage outages party patching performance planning poor post postmortems power problem problems procedures process processes prod product production project projects push quality recovery regression

regular related release releases requirements resource retrospective retrospectives review reviews rework root scope security server servers service services slow software sprint sql stability steps storage support system systems tasks team teams technical test testing tests time tool tools unexpected unplanned updates upgrade upgrades use user value vendor version went work working wrong

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

Tipos de Salida de una Retrospectiva

Hola a todos

Hace un tiempo leí un gran post de  Damian Buonamico - Retrospectivas Ágiles: No sólo Accionables - que referencio frecuentemente en mis entrenamientos de Scrum, en el Damian explica que de toda retrospectiva hay como resultado

• Tareas (o acciones)
• Acuerdos de equipo 

En esa misma taxonomía yo quisiera añadir, como muchos ya lo han expresado un tercer elemento que no pueden perder de vista los equipos ágiles,

• Los experimentos

Basado en lo anterior, entremos pues en  las definiciones:

Las tareas: son acciones que tienen inicio y fin, y un resultado claramente definido, ejemplos

• Migrar de servidor la base de datos pues su memoria se esta copando
• Actualizar la versión del framework
• Mover el tablero de ubicación
• Crear un tablero kanban para mejoras

Las tareas dentro del framework de Cynefin se encontrarian en el terreno de lo Obvio (1)

Los acuerdos: son conductas, políticas, actividades o procesos que un equipo decide realizar frente a diferentes circunstancias, ejemplos:

• De ahora en adelante después del planning los PO y los testers se reunirán a identificar cual va a ser la estrategia de pruebas del sprint.
• Si alguien va a salir temprano por alguna razón laboral o no, deberá pedirle autorización al equipo y garantizar que el equipo queda enterado sobre los pendientes, acciones a realizar y la persona queda localizable para solucionar alguna duda.

Los acuerdos dentro del framework de Cynefin se encontrarian en el terreno de lo Obvio (1)

Los experimentos:  Aunque podrían ser tareas, su resultado no es predecible y  puede ser apropiado, inapropiado, o indiferente para el equipo.

Es recomendable que para todo experimento se tenga:

• Responsable
• Fecha o cuando se ejecutará
• Resultados esperados
• Resultados obtenidos

Algunos ejemplos de experimentos pueden ser:

• Probar pomodoro como técnica para gestión del tiempo del equipo
• Determinar si el uso de un determinado framework acelera o reduce la velocidad de desarrollo
• Realizar pair programming y validar si la tecnica es adoptada por el equipo o no.

Los experimentos dentro del framework de Cynefin se encontrarian en el terreno de lo Complejo (1).

Unas últimas sugerencias

• Es importante recalcar que por lo genera toda mejora se da en el plano de la personas, procesos o herramientas (2)
• Y aunque algunas mejoras sean tareas o acuerdos, es bueno redactarlas a nivel de experimentos para validar si su uso fue fructífero o no

Este es la taxonomía que hasta el momento he identificado, bienvenido el feedback.


Saludos ágiles y un exitoso 2018

Jorge Abad

Notas, Referencias, Comentarios, Aclaraciones

1. Hablemos de la Complejidad, la Gestión de Proyectos y Cynefin - clic aquí para ver- 
2. Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo  -clic aquí para ver-.

Presentación: Los puntos ciegos del Scrum Master

Los puntos ciegos del Scrum Master - Ágiles 2017 - Chile from Jorge Hernán Abad Londoño

Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo

Hola a todos:

Hace poco en una sesión de acompañamiento a Scrum Master, alguien me preguntó

¿Hacia dónde seguir mejorando el equipo, pues creo que no podemos mejorar más?

Ante esta pregunta, comencé a explicar el Modelo Operativo de Generación de Valor (1) el cual se basa en:

• Personas
• Procesos y
• Herramientas

Por lo tanto, si el Scrum Master se centra solo en personas y procesos "rápidamente" (tal vez en 10 sprints, tal vez muchos más, tal vez menos ) el equipo logrará sinergia y alcanzará la maestría en el manejo de Scrum, sus ceremonias, priorización del backlog, etc.,  y caerán en una "zona cómoda" en la cual la pregunta realizada tiene todo el sentido.

Bajo este contexto la frase de Ken Schwaber - cocreador de Scrum -  toma todo el sentido:

“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”( no dudo que la hubiera querido terminar con otra palabra)

Es necesario entonces, que como Scrum Masters y Coaches adicionemos a los procesos de mejora del equipo las herramientas (2) -o prácticas técnicas- y lograr que los equipos adquieran la maestría en ellas, aun más que sean sanamente insatisfechos y estén siempre buscando una mejor manera de hacer las cosas. De esta forma se genera valor hacia el interior y exterior del equipo estando en constante crecimiento.

Cerrando

A continuación quiero compartirles una pequeño listado de prácticas técnicas con las que pueden y deben retar a sus equipos como Coaches Agiles que son de ellos, la lista en esta en continuo crecimiento, este es el pequeño listado que encontré a la fecha:

Herramientas (Prácticas ágiles) 

Zona 1: Personas y Herramientas

• Inspección o revision por pares

Zona 2: Procesos y Herramientas

• Pruebas unitarias
• Test Driven Development (TDD)
• Aceptance Driven Development (ATDD)
• Refactoring

Zona 3: Personas, Procesos y Herramientas

• Pair Programming
• Mob Programming

Zona 4: Solo Herramientas

• Integración Continua
• Despliegue Continuo
• Revisión de código estática
• Pruebas funcionales Automatizadas
• Principios SOLID de POO (Programación orientada a objetos)
• Clean Code
• Automatizar lo automatizable
• etc, etc, etc.

La reflexión del día, desde "Extreme Programming Explained" : "la labor de un coach agil es hacer su equipo AUN mejor de lo que es"@KentBeck

— Agustin Villena (@agustinvillena) February 16, 2017

El #ScrumMaster es el #AgileCoach de su equipo.

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

Para terminar les comparto esta frase que constantemente me inquieta "los pacientes se enferman de lo que el médico sabe (3)", por lo tanto si como Scrum master o Coach no estas en constante aprendizaje de estas tres áreas no podrás ayudar apropiadamente a tu equipo


Bienvenido el feedback


Saludos ágiles
Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Operating model - https://en.wikipedia.org/wiki/Operating_model
2. El tablero Kanban, la Gestión Visual, etc también son herramientas, el objetivo del post es hacer visible el punto de las prácticas técnicas ágiles.
3. "los pacientes se enferman de lo que el médico sabe" - clic aquí para ver post relacionado

[Tip Scrum]: Slack o el Tiempo para Afilar el Hacha en Scrum

Hola a todos

Comencemos con una historia para ilustrar el concepto

"Dos hombres determinan hacer una competencia en la cual deben lograr derribar un árbol en el menor tiempo posible. Ambos se lanzan a la obra, llenos de energía y convencidos de que el premio pronto estará en sus manos.

Al blandir sus hachas, vuelan las astillas y los espectadores miran con asombro como el corte en ambos árboles se va profundizando con cada hachazo.

De repente uno de los dos competidores se detiene. El público queda sorprendido al observar que saca una pequeña lima de su bolsillo y comienza a afilar su hacha con toda calma.

Su oponente está feliz. Sigue golpeando con aún mayor fuerza su árbol y muy pronto el corte que está haciendo llega a ser tan grande que su victoria parece ser evidente.

Hasta el momento en el cual el hombre que afiló su hacha vuelve al trabajo. Un, dos y tres. Con solo un par de golpes acertados su árbol comienza a crujir y, ante la sorpresa de todos los espectadores, se derrumba a los pies del hombre sabio, quien supo lo importante que era contar con una herramienta en óptimas condiciones."(1)




Ahora sí...

Entre mis compañeros coaches con los cuales comparto actualmente, es muy común un término que ellos acuñan como "afilar el hacha", yo lo conocía como Slack ( referido en el post  Seis (6) estrategias de lograr mayor velocidad de los equipos en Scrum - clic aquí- )  y es un tiempo que se separa durante o entre sprints para que los equipos o las personas afilen el hacha y mejoren su forma de trabajo.

Dentro de las formas de seleccionar este tiempo están técnicas como:

• dejar un tiempo pequeño entre sprints de 1 a 2 días 
• 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
• El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
• Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
• ver más en Cutting Slack in Scrum

Hasta acá este pequeño pero poderoso compartir.

Preguntas poderosas para ti y tu equipo

• ¿hace cuánto no afilas el hacha en tu equipo?
• ¿qué te lo impide?
• ¿qué es necesario hacer para lograr afilar el hacha en tu equipo con frecuencia?
• yendo un poco más allá, ¿en tu empresa, en tu relación de pareja, en tu vida hace cuanto no afilas el hacha?

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Tomado de : http://www.grandespymes.com.ar/2011/04/17/el-concepto-de-afilar-el-hacha-para-lograr-ser-mas-efectivo/

No esperar hasta la retrospectiva para mejorar

Hola a todos

El corazón de Ágil como lo expone Alistair Cockbourn (clic aquí) es:

• Colaboración
• Entrega temprana y continua de valor
• Adaptación
• y Mejora

Esto debe ser vivido por todo equipo que se identifique como ágil.

Hoy quiero centrarme justo en la mejora, pues identificamos que esta por lo general se da en la retrospectiva cuando el equipo decide que experimentos y mejoras realizar al siguiente ciclo en todos o cualquiera de los siguientes aspectos:

• Personas e interacciones
• Procesos
• Herramientas

o cualquiera de sus variaciones como

• Calidad (corresponde a procesos)
• Felicidad (corresponde a personas)
• Tecnología (corresponde a herramientas)

Volviendo al tema que nos interesa, muchas veces durante el sprint identificamos mejoras (cualquiera dentro del equipo puede hacerlo - todos somos responsables de hacer las cosas mejor - ) y resulta que nos cuestionamos si esperar hasta la retrospectiva para la mejora o podemos implantarla ya.

La respuesta es muy simple

• Si la mejora es fácil de implantar y son obvios sus beneficios, la implementamos (¿que nos impide hacerlo, sabiendo que nos beneficiará?)
• si la mejora es compleja de implantar, lo decidimos en la retrospectiva

Bueno hasta acá esta pequeña reflexión.

Saludos Ágiles

Jorge Abad