Poca aplicación de Lean en el mundo Corporativo. Post Linkedin.

¿Será que Agile está en Crisis? (el caso del extremo #WIP)

Cómo realizar una reunión de sincronización (o daily) en un equipo que usa el método kanban

Imagen generada con Copilot de Bing

Hola a todos, 

A continuación les comparto como sugiero se realice una reunión de sincronización en un equipo que sigue el método kanban.

1. Preparación:

•  Antes de la reunión, todos los miembros del equipo deben revisar el tablero Kanban para tener una comprensión clara del estado actual de los tickets y cualquier problema o bloqueo que pueda surgir.

2. Inicio de la reunión:

• El Flow Master, Scrum Master, facilitador o un miembro designado del equipo da inicio a la reunión, asegurándose de que todos estén presentes y preparados para participar.

3. Breve introducción:

• Se da una breve introducción para recordar el propósito de la reunión, la cual es: sincronizar al equipo, identificar bloqueos, ver cuáles son elementos más próximos a cerrarse (y enfocarse en llos) y planificar el trabajo del día.

A continuación cada miembro del equipo cuenta su avance, progresos y bloqueos.

3.1 Informe del trabajo realizado desde la última reunión:

• Cada miembro del equipo comparte brevemente el trabajo que ha completado desde la última reunión. Esto incluye los tickets que han avanzado en el tablero Kanban y cualquier otro logro relevante. Comenzando siempre por los Urgentes, luego con los de fecha fija, luego con los normales y terminando con los "intangibles" o de arquitectura. Este orden se conservará en este y los tres pasos subsiguientes.

3.2 Informe del trabajo a cerrar el día de hoy:

• Los miembros del equipo comparten los tickets que serán cerrados el día de hoy. Se sugiere que el flow master ponga una marca a estos ítems, de forma que pueda identificarlos al día siguiente y ayude a que los miembros del equipo se enfoquen en los que tienen mayor prioridad por temas de urgencia y fecha.

3.3 Actualización del tablero Kanban (opcional, pues puede haberse hecho antes):

• Mientras los miembros del equipo informan sobre su trabajo, se actualiza el tablero Kanban en tiempo real. Se mueven las tarjetas de tickets a través de las columnas según su progreso actual. 

3.4. Identificación de bloqueos o problemas:

• Los miembros del equipo informan sobre cualquier bloqueo, petición de ayuda o problema que estén experimentando. Estos pueden ser obstáculos que impiden avanzar en un ticket o cualquier otro impedimento que esté afectando el progreso del equipo. Se debe dar prioridad a los elementos que estén viajando en el carril de urgentes y luego los de fecha fija.

3.5 Finaliza el estado de cada miembro del equipo, y el daily. 

• Los miembros del equipo contaron sus progresos, metas, bloqueos y peticiones de ayuda; y se cierra el reporte de estado.

Comienza la planificación del día de trabajo.

4. Identificación de los ítemes críticos a cerrar:

• El flow master de acuerdo con la información proporcionada en la sesión, la urgencia y las fechas, ayuda al equipo a identificar los elementos prioritarios a cerrar o avanzar en una dirección determnada el día en curso. Esta conversación se puede omitir en la medida que el equipo va alcanzando madurez y entiende la forma en que se da foco en el flujo de trabajo.

5. Discusión y resolución de bloqueos:

• Se discuten los bloqueos identificados, las peticiones de ayuda y se busca una solución. Los miembros del equipo pueden realizar sugerencias, ofertas de ayuda o recursos para superar los bloqueos de manera colaborativa. Estos bloqueos, el flow master los pririzará en función de las fechas y comentará su avance el día siguiente en la medida que persistan.

6. Planificación del trabajo del día:

• Basándose en el estado actual del tablero Kanban y en las discusiones sobre bloqueos, el equipo planifica el trabajo para el día. Esto puede implicar priorizar tickets, poner foco en elementos a cerrar, asignar tareas específicas a los miembros del equipo o ajustar el enfoque según las necesidades y compromisos.

7. Cierre de la reunión:

• Se finaliza la reunión agradeciendo la participación de todos y recordando cualquier acción acordada durante la reunión. 

8. Acciones de seguimiento:

• Si se han identificado acciones o soluciones durante la reunión, se asignan responsables y se establecen plazos para su seguimiento.

Al seguir estos pasos, el equipo puede mantenerse alineado, identificar y abordar rápidamente los problemas y avanzar de manera efectiva en el trabajo del día a día utilizando el método Kanban.

Si tienes mejoras o has identificado otras formas de hacerlo, te invito a que lo compartas en los comentarios.

Saludos ágiles,

Jorge Abad

Leído y Recomendado: To Build a Top Performing Team, Ask for 85% Effort / Para formar un equipo de alto rendimiento, pida un 85% de esfuerzo

 Excelente Artículo: To Build a Top Performing Team, Ask for 85% Effort - https://hbr.org/2023/06/to-build-a-top-performing-team-ask-for-85-effort

---

A continuación el resumen realizado por Bard - https://g.co/bard/share/614d8956a19c:

Resumen del artículo "Para crear un equipo de alto rendimiento, pida un 85% de esfuerzo"

El artículo "Para crear un equipo de alto rendimiento, pida un 85% de esfuerzo" de Ben Horowitz, publicado en la revista Harvard Business Review en junio de 2023, sostiene que la clave para crear un equipo de alto rendimiento es pedir a los miembros del equipo que se esfuercen al 85%.

Horowitz argumenta que pedir a los miembros del equipo que se esfuercen al 100% todo el tiempo es contraproducente. Esto se debe a que el agotamiento y el estrés que resultan de operar al máximo nivel pueden conducir a errores, decisiones pobres y, en última instancia, a un rendimiento inferior.

En cambio, Horowitz sostiene que pedir a los miembros del equipo que se esfuercen al 85% permite a los individuos y al equipo en su conjunto rendir de manera óptima a largo plazo. Esto se debe a que deja espacio para la creatividad, el aprendizaje y la recuperación.

Horowitz ofrece varios consejos para ayudar a los líderes a implementar la regla del 85% en sus equipos:

• Establezca expectativas claras. Los miembros del equipo deben saber qué se espera de ellos en términos de rendimiento y esfuerzo.
• Cree un entorno de confianza y apoyo. Los miembros del equipo deben sentirse cómodos para admitir cuando necesitan ayuda o descanso.
• Facilite el aprendizaje y el crecimiento. Los miembros del equipo deben tener oportunidades para aprender y desarrollarse en sus roles.
• Horowitz concluye que la regla del 85% es una forma efectiva de crear equipos de alto rendimiento que sean productivos, innovadores y sostenibles.

Algunos ejemplos de cómo implementar la regla del 85%:

• En lugar de exigir que los miembros del equipo trabajen horas extras, ofrezca flexibilidad para que trabajen desde casa o en horarios flexibles.
• En lugar de esperar la perfección, acepte que habrá errores.
• En lugar de centrarse en la cantidad de trabajo realizado, concentre su atención en la calidad del trabajo.

La regla del 85% es un enfoque simple pero poderoso para crear equipos de alto rendimiento. Al pedir a los miembros del equipo que se esfuercen al 85%, los líderes pueden ayudar a sus equipos a rendir de manera óptima a largo plazo.

---

Muy relacionado con este que escribí hace un tiempo: Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización -  http://www.lecciones-aprendidas.info/2020/12/de-coleccion-exigir-el-100-de-ocupacion.html

Saludos ágiles,

Jorge Abad.

Diagrama Explicativo del Método Kanban

 

Manual para Remar en Arequipe (Dulce de Leche) o Cómo ser Agile Coach (o Scrum Master) en Entornos Adversos a la Agilidad

 

Hombre remando en Arequipe -Creada con DALL-E (1)

Hola a todos,

Con frecuencia al hablar con Agile Coaches y Scrum Masters les digo que muchas veces nos encontramos en una organización en la que estamos 

¡Remando en arequipe! (2)

 o 

¡Remando en dulce de leche! (2)

haciendo referencia a que no es fácil el entorno en el que nos encontramos, y buscando generar cambios. Lo cierto, es que no es una buena noticia, pero ¡Para eso estamos!¡Para eso nos contrataron! Si fuera sencillo no estaríamos allí. para ayudar a las personas, equipos y organizaciones a reformular sus paradigmas y a encontrar formas mejores de interactuar y generar valor.

La resistencia al cambio es natural, no nos gusta cambiar, preferimos la inercia del estado en el que nos encontremos, la zona de confort o el statu quo; y si se quiere generar un cambio habrá que vencer dos fuerzas:

• hacer un Δ (delta) de esfuerzo para cambiar de estado, es decir, salir de la zona de confort y
• vencer el miedo a la incertidumbre de si ese nuevo estado es mejor que el actual o no.

Adicionalmente, está apareciendo otra fuerza para aquellos que estamos trabajando con la agilidad:

• ya hemos estado ahí y no nos gustó (3)

Esta última se puede leer como: no supimos cómo avanzar o no nos acompañaron bien. Todo lo anterior se puede ver ilustrado en el siguiente análisis de campo de fuerzas de Kurt Lewin:

Cómo entonces generar el cambio

No hay una fórmula secreta para lograrlo, al leer sobre gestión del cambio y experimentar muchos modelos, voy a compartirte algunas estrategias que han servido:

1. Identifica si existe alguna métrica, indicador, OKR, KPI, evaluación de desempeño en la que se puede incluir el propósito que quieres lograr. Es una de las más efectivas pues, hay una máxima de la gestión "Cómo me midas me comporto" (4) y esto ayudará en el propósito buscado. Bajo esta premisa, encuentra una buena métrica que ayude a generar los comportamientos adecuados, lo contrario, es peligroso.
2. Usa el Método Kanban (5), pues este tiene un lema: "EMPIEZA CON LO QUE HACES AHORA" (el cual es cierto) y poco a poco introduce el método - te sugiero revisar con calma la referencia (5) en la zona de recursos y la 6)-.
• 
  
  
  
  
3. Aplica Agilidad Orgánica o Scrum Orgánico, es decir, invita a hacer retrospectivas máximo cada mes y ve introduciendo prácticas que el equipo vaya necesitando - ver referencia (7)-.
4. Use el lenguaje tradicional para fuera del equipo, pero al interior use la agilidad - ver referencia (8) - 
• 
  
  
  
  
5. Logra que tu proyecto reporte resultados a quienes te contrataron, de forma que puedas informar avance, impedimentos o riesgos según se vayan presentando.
6. Un último consejo, ponte en los zapatos de ellos, se Empático mas no Complaciente(9), y pregúntate:
• ¿Por qué actúan de esa manera? ¿Qué les impide ayudar?
• ¿Cómo son medidos?
• ¿Qué sucede si acontece el cambio con los cargos de ellos?
• ¿Tienen el conocimiento necesario?
• ¿Cómo puedo ayudar desde mi experiencia aumentar el grado de consciencia respecto a la agilidad?
• entre muchas otras.
7. Declarar experimentos y buscar como implementarlos en la organización por tiempo corto. Lean Change Management es una buena opción para hacerlo:
• 
  
  
  
  
• 
  
  
  
  

Lo cierto, es que no hay una sola estrategia para motivar el cambio o generarlo. Es valioso que como agente de cambio estés monitoreando el entorno, tomando métricas, comparando versus líneas base e identificando efectivamente si la organización desea avanzar hacia la dirección deseada, en caso de que sí, persevera, en caso de que por un tiempo prudente (y ese solo lo sabes tu) observas que efectivamente no desea el cambio, entonces busca otra oportunidad en otra organización o equipo., 

Saludos ágiles,

Jorge Abad.

Referencias 

1. Imagen creada en DALL-E https://labs.openai.com/s/MFYbemXGsB7HnPDnQfuZSZvD
2. En Colombia el dulce de leche es conocido como arequipe.
3. La Agilidad ha Muerto, ¡Larga Vida a la Agilidad!  http://www.lecciones-aprendidas.info/2022/05/la-agilidad-ha-muerto-larga-vida-a-la-agilidad.html
4. Cómo me midas me comporto:  http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
5. Método Kanban - https://kanban.university/
6. Infográfico del método kanban:
• En español: https://kanban.university/wp-content/uploads/2021/05/Kanban-Method-Infographic-Rosie_Spanish_PRINT.pdf
• En inglés: https://kanban.university/wp-content/uploads/2021/05/Kanban-Method-Infographic-Rosie-2048x1448.png
7. Unas notas sobre Scrum Orgánico / Agilidad Orgánica - http://www.lecciones-aprendidas.info/2015/08/scrum-organico.html
8. Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales - http://www.lecciones-aprendidas.info/2019/09/como-evitar-la-ingenuidad-agil.html
9. Reflexión: Empático mas no complaciente - http://www.lecciones-aprendidas.info/2020/03/reflexion-empatico-mas-no-complaciente.html

RespuestasAgiles: ¿Qué es la LEY DE LITTLE y por qué es importante para las GERENCIAS DE TI y PMOs?

100% de CPU es lento en nuestras máquinas, ahora llévalo a un 100% de ocupación tuyo de forma constante

Todos reconocemos y experimentamos que el 100% de CPU constate en nuestra máquina la relentiza y la hace ineficiente; me impacta es que no podamos reconocerlo en nosotros mismos y en nuestros colaboradores, y los/nos terminemos quemando.

Te invito a leer este artículo, donde está el sustento científico de esta "ineficiencia" en los humanos y una sugerencia para solucionarlo: "Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización" 

Video: Obtención y Explicación de la Gráfica de Flujo Acumulativo

A continuación encontrarás la Hoja de Cálculo empleada durante el ejemplo, puedes descargarla para tu uso.

Video Conferencia: Exigir el 100% de ocupación de las personas está destruyendo la eficiencia de tu equipo y organización

En el siguiente enlace puedes encontrar el artículo relacionado con toda la explicación al detalle - http://www.lecciones-aprendidas.info/2020/12/de-coleccion-exigir-el-100-de-ocupacion.html

Algunos ciclos en gestión de proyectos, gestión de productos, gestión de equipos en el mundo del software, por John Cutler

 ¿Por qué ese equipo siempre parece asumir demasiado trabajo?

 (Why does that team seem to always take on too much work? )

---

¿Por qué ese recurso compartido parece estar perpetuamente falto de personal?

(Why does that shared resource seem to be perpetually under-staffed?)

---

¿Por qué el equipo sigue empezando a planificar grandes lotes?

      (Why does the team keep slipping into planning big batches?)

---

¿Por qué una óptica miope se concentra en aumentar la velocidad, finalmente daña la calidad?

(Why does a myopic focus on increasing velocity eventually hurt quality?)

---

¿Por qué las historias del equipo nunca son "suficientemente buenas"?

(Why are the team’s stories never “good enough” ?)

---

¿Por qué mi equipo me oculta cosas?

(Why does my team hide things from me?)

---

Bueno ... viste lo que pasó cuando tratamos de asignarles un problema, ¿verdad?

(Well…you saw what happened when we tried to just hand them a problem, right?)

---

BONO (que envuelve muchas de estas)

{BONUS (that wraps up lots of these)}

---

Este es el tweet original

Some common loops #proddev #systems

1/7 Why does that team seem to always take on too much work? pic.twitter.com/AAbaTXzsQk

— John Cutler (@johncutlefish) November 22, 2019

De Colección: Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización

 

Hola a todos,

Con frecuencia me encuentro dentro de las organizaciones ya sean clientes o proveedores, expresiones en los gestores del personal, tales como:

"La ocupación de las personas debe ser del 100%, para eso se les paga"

o esta otra

"Exíjanles el 120% para que den el 100%"

Luego de esto, se activa el liderazgo egipcio, los látigos, las zanahorias, la microgestión, las acusaciones de distracción, el estrés, la sensación de esclavismo, el inflar las tareas para poder tener espacios para descansar, el ambiente se vuelve tóxico, y cualquier sentido de pertenencia se convierte en desvinculación y ganas de renunciar.

Como te puedes dar cuenta esto termina degradando el sistema, en vez de mejorarlo. El objetivo de este artículo es llevarte a que comprendas que:

"Una persona o un equipo con una asignación del 70% al 80% es mucho más productivo y eficiente que uno con una ocupación del 100%"

Debido a que las personas y equipos tienen espacios para:

• la mejora continua individual
• la mejora continua grupal
• para aceptar la variabilidad
• hacer con mejor concentración las tareas
• mejora colaborativa
• eliminar desperdicios
• innovar
• agregarle valor a lo que hacen

Si lo deseas puedes terminar acá de leer, pues lo que sigue es una larga justificación del por qué de esta afirmación, así que comencemos:

No podemos tratar a las personas como máquinas

En esta parte no voy a apelar a la evidencia científica sino a la experiencia personal, actualmente estamos en el 2020, el año en que estalló la pandemia del COVID-19 y muchos de nosotros nos hemos movido al trabajo virtual, adicional al impacto de esto en nuestras vidas,

• ¿no han sentido lo pesado de tener una agenda completa 100% todos los días, por varias semanas?
• ¿al final de día no terminan sintiéndose exhaustos y quemados?
• ¿no les ha hecho falta espacios para café y conversar e interactuar con sus compañeros? ¿tener conversaciones interesantes y conversaciones triviales?

al menos yo sí, llevándome al punto que he tenido que insertar en mi agenda espacios para descansar, pararme, tomarme un café, y estos descansos han permitido que refresque mis ideas, que tenga más fluencia y mejor concentración, que trabajar 100% todos los días.

Ahora, no niego que hay días de sobrecarga y se asumen, pero un ritmo sobrecargado de forma constante termina yendo en contra de las personas y de los equipos.

Dice Sun Tzu en el Arte de la Guerra:

"Las armas son instrumentos de mala suerte; emplearlas por mucho tiempo producirá calamidades. Como se ha dicho: "Los que a hierro matan, a hierro mueren." Cuando tus tropas están desanimadas, tu espada embotada, agotadas tus fuerzas y tus suministros son escasos, hasta los tuyos se aprovecharán de tu debilidad para sublevarse. Entonces, aunque tengas consejeros sabios, al final no podrás hacer que las cosas salgan bien."

Te recomiendo estos dos artículos:

• Ritmo Sostenible sobre Ritmo Insostenible - (clic aquí)
• Recomendaciones sobre el sobreesfuerzo del equipo en un proyecto - (clic aquí)

En el trabajo de conocimiento nuestra aproximación es diferente

En el mundo de la fabricación de objetos físicos, las tareas son repetitivas, las actividades son razonablemente predecibles y los elementos que se crean pueden estar en un solo lugar a la vez. En el desarrollo de productos, muchas tareas son únicas, los requisitos del proyecto cambian constantemente y el resultado, gracias, en parte, al uso generalizado de diseño y simulación avanzados asistidos por computadora y a la incorporación de software en productos físicos, es información que puede residir en varios lugares al mismo tiempo, o que puede ser construida de forma eficiente o ineficiente, generando alta variación en las tareas, las estimaciones y los compromisos. Creer que un grupo de ingenieros de software expertos garantizará el cumplimiento de un cronograma detallado de varios cientos de filas y meses de planeación es cada vez más irreal, los enfoques ágiles permiten validar rápidamente los resultados obtenidos y navegar exitosamente en estos escenarios de incertidumbre. Pero para que esto se lleve a cabo de forma exitosa es necesario que tanto gestores, gerentes de área, gerentes de proyectos directores, líderes, agile coaches, scrum masters, product owners y product managers, comprendan el pensamiento lean-agile, para que cultiven y permitan que funcionen muchas prácticas que van en contrasentido de la gestión tradicional, sin esto, cualquier esfuerzo de cambio será en vano.

100% de la utilización es un desastre económico

Es normal pensar que los proyectos toman más tiempo cuando las personas no están trabajando el 100% de su capacidad, y, por lo tanto, una organización de desarrollo ocupada será más rápida y eficiente que una que no sea tan buena en utilizar a su gente, pero en el mundo Lean y en la práctica eso no es cierto, cuando la ocupación o utilización del tiempo de las personas se aproxima al 100% la eficiencia, la calidad y la velocidad disminuyen (2), existen varias razones:

No se considera la variabilidad de procesos de trabajadores de conocimiento

Los trabajadores de conocimiento no hacen tareas estandarizadas, en un mundo estandarizado un cambio del 7% en el trabajo generará un 7% más en completarlo, algo que no ocurren procesos de TI. En general existen tres fuentes de variación (3) en los procesos:

• Recursos: 
• Ejemplos: unas máquinas son lentas y otras rápidas, los expertos realizan las tareas más eficientemente que los novatos.
• Unidades de flujo (o elementos que fluyen): 
• Ejemplos: en una fábrica de autos personalizados los vehículos tendrán diferentes características. 
• Factores externos
• Ejemplos: los pacientes en una sala de urgencias no llegan de forma fluida, a un equipo comercial la solicitud de propuestas no es un flujo constante.

En el mundo de TI donde a pesar de usar la misma estrategia de construcción de software puede cambiar:

• la persona que los realiza (incluso la misma persona en distinto tiempo)
• el estado de ánimo de la persona
• disponibilidades tanto de personas, áreas, recursos (servidores, comunicaciones, componentes)
• los requerimientos
• insumos
• la calidad de la documentación
• resultados esperados
• dependencias
• transacciones
• complejidad técnica
• supuestos y premisas
• entre otros

se constituyen en fuentes de variación del proceso, y estas fuentes de variación generan un tiempo de flujo diferente según el porcentaje de utilización de los recursos, tal como lo formuló Sir John Kingman, el cual desarrolló la fórmula de teoría de colas que relaciona la variación, eficiencia de recursos y tiempo de travesía (16). Ver gráfica a continuación:

Relación entre variación, eficiencia de recursos y tiempo de travesía - Gráfica de Sir John Kingman (3)

Por lo tanto:

• entre más cercanos estemos al 100% de utilización del tiempo de las personas más tiempo tomará la travesía del proceso
• ampliar la utilización del 90 % al 95 % aumenta el tiempo de travesía en un nivel mayor, que el de aumentar la utilización del 80 % al 85 % (3)
• agregar un 5% más de trabajo puede llevar un 100% más de tiempo (2)
• cuando el tiempo de travesía aumenta, el flujo (la cantidad de ítems, requerimientos, tickets por unidad de tiempo) disminuye

Es importante anotar que, para TI aplica más la curva fucsia que la gris.

Por lo tanto:

"Cuanto mayor sea la utilización de tu equipo, más largo será el tiempo de travesía, es decir, si tienen un ciclo fijo de trabajo, menos cosas lograrán terminar"

 ----- 

"Cuanto mayor sea la variación en el proceso, más largo será el tiempo de travesía (3)"

Relación el Tiempo de Ciclo, la Utilización y el Tamaño de los Lotes

"Reduzca el tamaño de lote para: reducir la variabilidad e incrementar la predictibilidad"

Es por eso que en Scrum se insiste

• que las historias de usuario sean pequeñas (http://www.lecciones-aprendidas.info/2017/05/En-serio-historias-pequenas.html) (esto también aplica para DevOps)
• se tenga un sprint backlog que contenga de 6 a 10 historias de usuario de similar tamaño
• se estima usando Fibonacci en el planning póker para amortiguar un poco la variabilidad de las historias de usuario
• se sugiere planear con el 70% al 85% de la capacidad del equipo
• Durante décadas, 3M ha programado desarrolladores de productos al 85% de su capacidad (2)
• Y Google es famoso por su “20% de tiempo” (que permite a los ingenieros trabajar un día a la semana en lo que quieran, una práctica que significa que hay capacidad adicional disponible si un proyecto se retrasa) (2)
• Ericcson planea sus equipos de producto al 70% (7)
• El marco SAFe (https://www.scaledagileframework.com/) incluye un sprint de innovación y planeación (https://www.scaledagileframework.com/innovation-and-planning-iteration/ )
• El Slack es un tiempo que permite a los equipos mejorar, te sugiero leer el siguiente artículo: Slack o el Tiempo para Afilar el Hacha en Scrum - http://www.lecciones-aprendidas.info/2016/10/slack-o-el-tiempo-para-afilar-el-hacha.html

Tomado de: Scrum y XP desde las trincheras por Henrik Kniberg (4).

Tomado de: Scrum y XP desde las trincheras por Henrik Kniberg (4).

"Operar un proceso de desarrollo de productos cerca de su plena utilización es un desastre económico" ― Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development

--

 "100% de utilización conduce a la no predictibilidad" ― Donald G. Reinertsen

Principle Q6 & Fig 3-6 illustrate this point. Think of queueing function as transforming a change in loading into a change in queue size (& thus cycle time). Operating at high utilization amplifies variability. Manufacturers have known this for a long time, developers not so much

— Donald Reinertsen (@DReinertsen) August 16, 2018

No permite la atención de imprevistos

El tener un equipo o personas al 100% de su capacidad y con compromisos en ciclos cortos, no permite aceptar la atención a imprevistos, pues cualquier imprevisto afectará el compromiso. En entregas largas la aceptación de imprevistos es tomada más como un favor, pues no se visualiza el impacto del tiempo de desenfoque, pero ya hemos aprendido que las entregas largas no son exitosas en el mundo del software, es por eso que enfoques como Scrum o XP son exitosos hoy en día. Por lo tanto, una estrategia usada por equipos scrum para aceptar los imprevistos es usar el patrón: Illegitimus Non Interruptus (clic aquí), el cual consiste en reservar de la capacidad del equipo un porcentaje para atención de imprevistos en caso de que estos se presenten.

Tomado de (6)

Inhibe la colaboración y la innovación

Frases que nos decimos o nos dicen como:

• "Te ayudaría, pero ahora no tengo tiempo"
• "Esto se podría mejorar de esta manera, pero no tengo tiempo"
• "Cuando tenga tiempo te voy a enseñar a ___________"

Con seguridad lo haríamos, pero estar 100% enfocados no permite ir más alla; es un enfoque del 100% en la tarea encomendada, que ahoga espacios de interacción y mejora que emergen al poder colaborar o al tener una carga menor de trabajo. La mejora y la innovación no ocurren fuera del horario laboral (de 6 pm a 10 pm), tal vez, vengan ideas fuera de este horario, pero la implementación requiere de tiempo laboral.

Tomado de (7)

Tomado de (10)

Una experiencia observable en talleres (y en la realidad)

En talleres donde se ejemplifica como es el mundo Lean y Kanban, se realizan varias iteraciones con equipos constituidos entre 5 y 8 personas, en los cuales construimos hamburguesas ficticias, o pizzas, o retratos o cualquier proceso organizacional, se realizan varias iteraciones del proceso con diferentes porcentajes de utilización y limitando el WIP, una y otra vez demostramos que la utilización cercana o igual al 100% genera desperdicio.

Tomado de (11)

Tomado de (11)

Para este ejemplo tener utilizaciones del 98% produjo: 

• 7 hamburguesas, 
• -1170 unidades de valor y 
• 7 defectos, 

mientras que con utilizaciones del 74% se lograron:

• 15 hamburguesas,
• 1340 unidades de valor y
• 0 defectos

Una y otra vez, concluimos que como gestores nuestro trabajo es maximizar el flujo de valor, no la utilización del recurso tiempo de las personas. Y esto se debe a la paradoja explicada en "Esto es Lean" (3), en la cual muestra que en el flujo de procesos esté en uno de los siguientes cuatro estados:

1. Baja eficiencia de flujo y baja utilización: desperdiciolandia
2. Alta eficiencia de utilización y baja flujo: islas eficientes
3. Alto flujo y baja utilización: océano eficiente
4. Alta eficiencia y alta utilización: el estado perfecto

Tomado de (3)

Lo cierto es que la perfección no va a ser posible alcanzarla debido a:

Tomado de (3)

variaciones en

• lo que es solicitado
• las variaciones en el proceso de lo que es solicitado
• cuándo es solicitado
• y la cantidad solicitada

Por lo que siempre estaremos rondando lo que se llama "Frontera de la Eficiencia"

Para llegar a esa frontera, tanto la literatura como la experiencia nos recomiendan

1. Identificar si estas en el estado de Islas Eficientes o Desperdiciolandia (por lo general estas allí)
2. buscar primero la eficiencia de flujo
3. y luego la eficiencia de utilización 

Tomado de (3)

Para esto debes de valerte de:

• Gestión visual del trabajo
• Crear ambientes de colaboración
• Tener una cultura de experimentación y aprendizaje (Toyota Kata (12) puede ser una gran herramienta en este escenario)
• Visión Sistémica
• Una cultura con seguridad sicológica en la que no exista temor a fallar
• Una obsesión por la mejora continua (Kaizen)

Adaptado de (11)

Te invito a ver el siguiente video imperdible de Henrik Kniberg @HenrikKniberg, donde podrás ver el paradigma Lean, en donde se prioriza la generación de valor sobre la "utilización de los recursos" (pongo paréntesis pues constantemente los gestores denominan a sus colaboradores como "recursos", término que termina más destruyendo que ayudando, ver referencia (13)).

El perfil "T" ayuda a lo anterior

Imagina que tu trabajo fuera solo operativo y te dedicaras a hacer lo mismo en una hamburguesería: picar tomates, si picas tomates y estas al 100% dedicado a esa tarea (podemos decir que estas siendo 100% eficiente en tu tarea), pero solo el 60% de los tomates que picas son usados y el resto se echan a la basura pues no hubo hamburguesas a ser consumidas (solo el 60% de tu trabajo agregó valor). Similar a esto ocurre en un equipo donde todos son especialistas: los desarrolladores no pueden estar 100% desarrollando, los tester 100% probando o haciendo casos de prueba, y de igual forma con frontend, backend, automatización, etc., se generará desperdicio, y el flujo de valor estará limitado a la capacidad más pequeña, en el caso de la imagen inferior, en el "Caso 1" corresponderá al especialista 2.

Explicación de mayor flujo de valor con Perfil "T"

Pero si en vez de tener especialistas, existen generalistas (o perfiles T -ver más en (15)-) que son más expertos en unas áreas y en otras tienen suficiente conocimiento y experiencia para apoyar de forma valiosa, el flujo se aumenta, pues todos van a ayudar a los generalistas 2 y 4, como se observa en el "Caso 2" de la imagen superior.

Nota: La práctica de Pair Programming de XP (17), ayuda en la distribución de conocimiento y en asegurar la calidad de lo que se construye.

 

Cerrando 

Muchas de las prácticas de Lean parecen un contrasentido, pero al aplicarlas permiten a las organizaciones, a los equipos y a las personas alcanzar estados de alto desempeño, generación de valor con menor esfuerzo, por lo tanto, cierro este largo artículo con una serie de recomendaciones:

• Tu trabajo como gestor no es micromanejar a las personas o equipos para que estén al 100% ocupados, tu trabajo es poner un objetivo, proveer los recursos para lograrlo, limitar el WIP, y maximizar el flujo.
• Prioriza la eficiencia de flujo
• Prioriza el aprendizaje continuo
• Luego prioriza la utilización del recurso tiempo
• Toma métricas y sigue experimentando
• No satures a las personas o a los equipos de trabajo
• Planea por debajo del 100% de la utilización crea un ambiente de innovación, colaboración y que permite aceptar la variabilidad
• Te sugiero realizar una asignación de una persona o equipo del 70% al 80% para lograr altos índices de generación de valor y fluencia
• Si va a existir sobreesfuerzo que sea por corto tiempo y acordado con el equipo (14) 
• Reduzca el tamaño de lote o elementos del backlog 
• para:reducir la variabilidad e
• incrementar la predictibilidad

ahora que comprendes como maximizar el flujo, la pregunta es:

¿En qué cosas de valor vas a poner a trabajar a tus equipos de desarrollo de productos?

Saludos ágiles

Jorge Abad


(de este artículo se realizó una conferencia, la cual puedes consultar aquí: http://www.lecciones-aprendidas.info/2021/02/de-coleccion-exigir-el-100-de-ocupacion-video-conferencia.html )


-

Notas, Referencias, Aclaraciones, Comentarios, Observaciones y Agradecimientos

1. Agradecimientos a mi compañero y amigo Roberto Moraga, Daniel Ramírez y a Adrián Hurtado por sus comentarios y sugerencias
2. Six Myths of Product Development by Stefan Thomke and Donald Reinertsen https://hbr.org/2012/05/six-myths-of-product-development
3. Esto es lean: Resolviendo la paradoja de eficiencia - https://www.amazon.com/-/es/Niklas-Modig-ebook/dp/B019E91600
4. Scrum y XP desde las trincheras por Henrik Knibnerg. (http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf )
5. Illegitimus Non Interruptus (clic aquí)
6. Interrupt Pattern (clic aquí) 
7. Flow Thinking @ Ericsson 3G - https://es.slideshare.net/erikschon/flow-thinking-ericsson-3g 
8. La cita original decía "operating a product development process near full utilization is an economic disaster"
9. La cita original decía: 100% utilization drives unpredictability - https://www.scaledagileframework.com/innovation-and-planning-iteration/
10. 2 Second Lean Book - https://paulakers.net/books/2-second-lean
11. Fuente Roberto Moraga @RMoraga
12. Excelente presentación sobre Toyota Kata de Hiroshi Hiromoto (@hhiroshi) (clic aquí)
13. Diatriba: El tema recurrente de llamar "RECURSOS" a las personas que trabajan en un proyecto (clic aquí)
14. Recomendaciones sobre el sobreesfuerzo del equipo en un proyecto - (clic aquí)
15. T-shaped skills (clic aquí)
16. Fórmula de Kingman - https://es.wikipedia.org/wiki/F%C3%B3rmula_de_Kingman
17. Programación en pareja o en pares- https://es.wikipedia.org/wiki/Programaci%C3%B3n_en_pareja

Varios proyectos a la vez generará más retraso en la generación de valor. Limita el WIP.

Hola a todos

Muchas veces tenemos la sensación de que debemos satisfacer las necesidades de todas las áreas o personas que nos piden tareas, requerimientos o proyectos, esto sucede a nivel:

• individual
• de equipo
• de áreas de construcción o ejecución de proyectos y productos de software,

con la sensación de que debemos atenderlos a todos, ya sea para no generar quejas, o por evitar problemas políticos, pero esto en vez de ayudarnos generará:

• pérdida de foco
• grandes esfuerzos de gestión y pérdida de energía, pues debes estar pendiente de varias cosas a la vez
• retrasos en la entrega, que a su vez generará:
• más inconformidad en las áreas que esperan resultados
• pérdida de valor de las funcionalidades construidas y la necesidad de introducir cambios
• sobrecostos por los cambios introducidos
• pérdida de dinero debido a la no generación oportuna de valor
• poca flexibilidad para reaccionar a los cambios, debido a que debes resolver muchas cosas a la vez y habrá demoras resolviendo un problema puntual.

Por eso, si lideras un equipo, un área de ejecución o aún de forma individual, te sugiero que:

• tengas foco
• hagas una o pocas cosas a la vez
• Limita el Work In Progres (WIP) o trabajo en progreso
• Aprende a decir ¡No!

Sino, tu propias ganas de satisfacer a todos, distruirá tu propósito de generar valor, cayendo en el adagio popular 

"El que mucho abarca, poco aprieta"

Saludos ágiles

Jorge Abad

Conozcamos Flowban de manos de su creador. Una herramienta para aprender Kanban

 Hola a todos

El pasado 26 de Agosto. Mauro Strione, Agile Coach de Argentina, Instructor Kanban, radicado en Chile, nos compartió Flowban, la herramienta que desarrllo en Angular para enseñar Kanban.

En la sesión tuvimos un breve repaso principios kanban, como se usa la herramienta y en paralelo ejecutamos tres simulaciones

A continaución el video de la sesión:

http://flowban.herokuapp.com/ desarrollada por @MauroStrione

¿Por qué Amazon no usa un marco de escalado y por qué puede que tú sí lo necesites?

---

¿Por qué amazon no usa un marco de escalado y por qué puede que tú sí lo necesites? from Jorge Hernán Abad Londoño

Agilizando Equipos de Operaciones - El Daily

Hola a todos


Cuando he trabajando con equipos de soporte para volverlos ágiles, es decir, aumentar su colaboración, entrega de valor, reflexión y mejora continua; por lo general mantengo dos reuniones que han resultado de valor:

• La sicronización diaria o daily y
• La retrospectiva

Hoy quiero compartirles algunas preguntas que nos han sido de valor:

• ¿Qué fue lo más importante que hice ayer?
• ¿Qué es lo más importante que voy a hacer hoy?
• ¿Qué impedimentos hay o identifico?
• ¿Cuál es mi porcentaje de ocupación el día de hoy?
• Necesito ayuda con...
• Ofrezco ayuda con...

Las primeras dos preguntas están pensadas en que sean cortas, pues los equipos de soporte u operaciones hacen muchas tareas repetitivas, dar información sobre ellas no agrega mucho valor y aburre a todos, respecto al ofrecer y pedir ayuda ha dado como resultado colaboración entre las personas que están presentes y un mejor espíritu de equipo.

Hasta acá este corto compartir.

Saludos Ágiles

Jorge Abad

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/