Frase: Excelencia a todo nivel

 

Frase: Anyone who keeps learning stays young - Cualquiera que siga aprendiendo permanece joven

He pensado que quizá te guste esta cita de "How Google Works", de Eric Schmidt, Jonathan Rosenberg .

"Henry Ford said that “anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. The greatest thing in life is to keep your mind young.”"

--

"Henry Ford dijo “cualquiera que deja de aprender es viejo, ya sea a los veinte u ochenta años. Cualquiera que siga aprendiendo permanece joven. Lo mejor de la vida es mantener la mente joven.”"

Empieza a leer este libro gratis: https://a.co/dV6TFIK

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

Leido y Recomendado: Seis mitos del desarrollo de productos

Six Myths of Product Development /Seis mitos del desarrollo de productos

por 

• Stefan Thomke
 y 
• Donald Reinertsen (clic aquí)

 

New Minibook: Some Ideas for Agile Team’s Retrospectives

More than two years ago, after sharing a meetup on Retrospectives in Mexico City, I observed that were retrospectives, so useful in Agile frameworks, was not being conducted in a way that would generate the desired impact, which is: ACHIEVING THE IMPROVEMENT OF TEAM PERFORMANCE.

Due to the above, the idea of ​​this minibook entered my backlog of pending to build, and today I am finally sharing it with the Agile community and with all those who want to take their work teams to a mindset of continuous improvement.

Some Important Notes from the Mini-Book

The illustrations were made by my wife Diana Apráez, the launch flyer was designed by my daughter Mariana, translation by Dhiraj Bellara - @BellaraDhiraj, additionally I asked colleagues and friends of the Latin American Agile Community to collaborate with me with their reviews, prologues, advices and revisions, thanks again: Diana, Nadia, Lucho, Carlos Palacio, Carlos Quiroga, Carlos Serna, Wbeimar, Juan Andrés, Jaime, Augusto, Alma, Roberto, Daniel and Leonardo for all your contributions.

For the English edition, Ben Linders -https://www.benlinders.com/- did me the honor of writing a Foreword.

I share it below.

Foreword by Ben Linders

Retrospectives are not a new thing. They became widely known through the agile manifesto, the Scrum Guide, and by books like Project Retrospectives by Norm Kerth and Agile Retrospectives by Esther Derby and Diana Larsen. The practice of reflecting to learn and improve is much older. I was doing it already in the past century, by assisting people to form a shared picture of what's happening to learn and improve. 

The main thing that we can learn from agile is that retrospecting is a team activity. It's up to the team to find out, acknowledge, and take action. The retrospective facilitator is there to assist the team, to provide the environment, and foster a culture where people feel safe to speak up. Having said that, facilitating is not an easy thing to do.

Many people still seem to struggle when facilitating retrospectives. Expectations are often high, which makes it even harder. Jorge's book brings together many useful practices and suggestions that can help you to facilitate retrospectives that help teams to become a better version of themselves. Use the book to experiment in your retrospectives, and see what works for you. Don't worry if something goes wrong, remember the Prime Directive and use it to learn from things that didn't work. Occasionally you may want to retrospect your retrospectives too. 

Wishing you a wonderful journey of learning and improving!

- Ben Linders

----

Thanks a lot Ben for this foreword!

Thanks a lot Dhiraj for the translation!

www.amazon.com/-/es/dp/B08R6YVSCJ

Agile greetings / Saludos ágiles

Jorge Abad

Kit de Inicio de Scrum - Scrum Starter Kit

Tomado de (1)

Hola a todos

Comúnmente veo Equipos Scrum y Scrum Masters enfrentados a problemas que ya fueron resueltos en los patrones de Scrum, publicados en : http://scrumbook.org/  o en sus fases tempranas en https://sites.google.com/a/scrumplop.org/published-patterns/home

Hoy quiero compartirles la traducción de la imagen del inicio, la cual encontré en el sitio de ScrumInc(1) de Jeff Sutherland - Cocreador del Marco de Scrum -. 

1.  ¿Cómo iniciar? Equipos estables (Stable Teams)
• y pequeños de apróximadamente 5 personas (Small Teams)
2. ¿Cómo identificar exitósamente el sprint backlog para un sprint? El clima de ayer (Yesteday's Weather) (referencia al clima de ayer en el blog de Lucho Salazar) 
3. ¿Cómo lograr que las cosas queden hechas (Done)? Primero las primeras cosas (First Things First) - No encontré la referencia, al parecer esta Deprecated, sugiero revisar esta High Value First.
4. ¿Cómo enfrentar las interrupciones durante el sprint? ( Illigitimus non interruptus )
5. ¿Qué hacer cuando te estas quedando atrás un sprint? Procedimiento de Emergencia de Scrum (Scrum Emergency Procedure)
6. ¿Cómo te aseguras estar libre de defectos al final del sprint? (Daily Clean Code)
7. ¿Cómo asegurar la mejora continua? (Scrumming The Scrum)
8. ¿Cómo logras que los equipo se divierta? Métrica de la Felicidad (Happines Metric) (Referencia en este blog a la métrica de la felicidad)
9. ¿Cómo logras la hiperproductividad? (Teams that Finish Early Accelerate Faster) 

Saludos Ágiles,

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. https://www.scruminc.com/interrupt-pattern/ 

Entrevista de Tribu Ágil sobre el Libro: Algunas Ideas Sobre Retrospectivas para Equipos Ágiles

Hola a todos 

Les comparto esta amena entrevista que me realizaron Cristhian Arias y Gino Ravelo del equipo de Tribu Ágil - https://www.tribuagil.com/, sobre el minilibro "Algunas Ideas Sobre Retrospectivas para Equipos Ágiles", espero la disfruten tanto como yo.

Próximamente el minilibro en inglés.

 ¡¡¡Gracias Tribu por este regalo!!! 

Saludos Ágiles

Cuídense mucho y cuiden a sus familias del COVID-19 en estas fiestas.

¡Feliz Navidad, Feliz Año y Próspero 2021 para todos!

Lanzamiento del Libro: Algunas Ideas Sobre Retrospectivas para Equipos Ágiles

Desde hace más de dos años de compartir un meetup sobre Retrospectivas en Ciudad de México, observaba que esta práctica tan útil en los marcos ágiles, no estaba siendo conducida de forma que generara el impacto buscado, el cual es: LOGRAR LA MEJORA DEL DESEMPEÑO DEL EQUIPO.

Debido a lo anterior, la idea de este minilibro entró en mi backlog de pendientes a construir, y hoy por fin estoy compartiendo con la comunidad ágil y con todos aquellos que quieran llevar sus equipos de trabajo a un mindset de mejora continua.

Algunas notas importantes del minilibro

Las ilustraciones fueron elaboradas por mi esposa Diana Apráez, el flyer de lanzamiento fue diseñado por mi hija Mariana, adicionalmente pedí a compañeros y amigos de la Comunidad Ágil Latinoamericana que me colaboraran con sus reseñas, prólogos, consejos y revisiones, nuevamente gracias: Diana, Nadia, Lucho, Carlos Palacio, Carlos Quiroga, Carlos Serna, Wbeimar, Juan Andrés, Jaime, Augusto, Alma, Roberto, Daniel y Leonardo por todos sus aportes.

Disfrútenlo,

A continuación el link en Amazon:

https://www.amazon.com/-/es/dp/B08PP3BZ6B/

Saludos ágiles,

Jorge Abad

Frase: El Product Owner es el CEO del Producto

 

Agilidad Empresarial y Agilidad Operativa

 

"No se puede pensar en Agilidad Empresarial sin tener Agilidad Operativa, pero de nada sirve tener Agilidad Operativa si el resto de la organización no es Ágil." - Jorge Abad

De qué hablamos cuando hablamos de historias de usuario (Presentación)

Tweet: La Agilidad no se Demuestra con Radares, se Evidencia con Resultados de Negocio

La agilidad no se demuestra con radares, los radares muestran brechas, la agilidad se evidencia con resultados de negocio- Jorge Abadhttps://t.co/HbKogXtxKe#Agile #BusinessAgility #EnterpriseAgility #Agility pic.twitter.com/n6BliRfsyg

— Jorge Hernán Abad L. (@jorge_abad) October 27, 2020

La Necesidad de la Innovación Radical del Liderazgo

Recuerdo mucho una frase que de niño repetían en mi familia:

"Las cosas se parecen a su dueño"

y un patrón que todos hemos visto, es como las organizaciones, las gerencias y los equipos de trabajo, se parecen a quienes los lideran, en últimas, es una tendencia normal y común que los líderes busquen personas de confianza que en últimas tomen decisiones similares a las de ellos o como son ellos.

Lo cierto, es que en este acompañar a organizaciones y grandes áreas en su proceso hacia la agilidad, he observado que el principal obstáculo se encuentra en el liderazgo, pues adoptar marcos y prácticas, aunque es complejo (ver Cynefin(1)), es relativamente fácil, versus el esfuerzo que hay que hacer con los líderes para que no destruyan lo que se está movilizando en la organización, que es un nuevo mindset, que nos permite reaccionar rápido al cambio mientas al mismo tiempo vamos generando valor.

 Es común encontrarse en nuestras organizaciones: directivos que no se hablan entre sí, que se sabotean mutuamente, donde la explotación de los empleados internos y de los proveedores es la regla, donde es común exigir resultados sin proporcionar los suficientes recursos para lograrlos, en las que existe una mentalidad fija y orientada a solo cumplir, con un excesivo control sobre las personas y equipos (ej.: lo que no les permite avanzar debido a estar haciendo excesivos informes que nadie lee), con incapacidad para generar espacios de seguridad sicológica donde se pueda fallar sin temor, donde la innovación es frustrada por la falta de presupuesto o de mindset adecuado, donde no saben o desconocen cómo aplicar las prácticas esenciales de gestión asociadas a Lean, y otras series de disfunciones como las que expone Kofman(2):

• Arrogancia ontológica: “mi verdad es la única”
• Culpa incondicional: “no fue mi culpa, fue de…”, “el comité fue el que decidió”
• Comunicación Manipuladora: ocultar datos, engañar, doble discurso
• Egoísmo esencial: “solo mi bienestar”
• Negociación narcisista: un juego político gobernado por: “vencer al adversario, mostrar “quien manda”
• Coordinación Negligente: promesas sin intención de ser cumplidas, pedidos inefectivos,

que terminan haciéndonos vivir en organizaciones enfermas, donde el ambiente de colaboración, transparencia, hiperproductividad que promueve la Agilidad, es sofocado por el estilo de gestión del siglo pasado que se resiste a morir. Si, debemos reformular el liderazgo, es necesaria una transición hacia entornos de abundancia que tanto leemos en los libros de gerencia, revistas de gestión y financieras; donde se adopten de forma consistente las prácticas que promovieron Deming, Taichii Onho, Drucker, Senge, Blanchard entre otros; si esto hubiese sido así, no estaríamos viendo con ojos de deseo a Google, NuBank, LinkedIn, Toyota, Netflix, Amazon, etc. Como dato curioso, cualquiera que se documente en libros sobre Amazon, pronto verá reflejado los 14 principios de Toyota(3), el Lean Mindset y lo que promovía Onho. Debemos entonces, reformular una INNOVACIÓN RADICAL EN EL LIDERAZGO, o estos gigantes, o cualquier pequeño que lo empiece hacer bien nos quitaran el mercado y desaparecerá nuestra organización.

Hace poco compartía con alguien de una empresa importante: “este estilo de liderazgo disfuncional del siglo pasado está destinado a desaparecer, ya sea porque este estilo destruirá tu empresa y otra rápido los superará, o porque este gerente/director/vicepresidente/presidente aprende una nueva forma de hacer las cosas o en definitiva es reemplazado; pero cada vez más, las personas, organizaciones y clientes toleran menos esta forma de gestión”

 

Necesitamos lideres con:

• Mentes Abiertas a posibilidades, dispuestas a aprender, empoderar y retar
• Que estén en una lucha constante por maximizar la colaboración en la organización, eliminando cualquier fuente de fricción, y generando fluencia
• En el que la transparencia sea radicalmente brutal y no se castigue al mensajero de las malas noticias, toda información sea vista como fuente de aprendizaje y de reacción al entorno.
• Que este en una lucha incondicional contra los 8 desperdicios de lean
• Su compromiso con la mejora continua, la calidad, la reducción del time to market y la generación de valor sean validados frecuentemente con datos y hechos
• Que rete el statu quo y esté abierto a recibir e intentar opciones diversas
• Que sepa priorizar por valor y gestione de forma eficiente la capacidad finita que tiene
• Que tengan visión a largo plazo
• Que sean capaces de hacer de la innovación una capacidad de la empresa
• Que admita estar equivocado y aprender
• Que lidere e inspire con el ejemplo
• Que trate a las personas como personas y no como un "recurso" que debe explotarse al 100%, orientando al logro y que retando a los equipos y colaboradores sin maltratarlos
• Que comprenda, que la responsabilidad del liderazgo le fue conferida para generar bienestar y abundancia
• Que exija hacia el resto de sus colaboradores un estilo de gerencia ejemplar como el que el promueve (3)
• Que tengan las virtudes que promueve Kofman: responsabilidad incondicional, integridad esencial, humildad ontológica, comunicación auténtica, negociación constructiva, coordinación impecable y maestría emocional

Yo estoy en ese viaje de la INNOVACIÓN RADICAL DEL LIDERAZGO ¿y tú?

 

Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Cynefin - https://en.wikipedia.org/wiki/Cynefin_framework
2. La Empresa Consciente.Fred Kofman. https://www.amazon.com/-/es/Fredy-Kofman-ebook/dp/B009RWDG3A
3. Toyota Way - https://www.amazon.com/-/es/Toyota-Way-Jeffrey-Liker/dp/0071392319
4. Antipatrón: Solo liderar la primera línea y no gestionar la red - http://www.lecciones-aprendidas.info/2019/08/antipatron-solo-liderar-la-primera-linea-y-no-gestionar-la-red.html
5. Una propuesta de Definición: Gerente de Proyectos Ágil - http://www.lecciones-aprendidas.info/2016/06/una-propuesta-de-definicion-gerente-de.html

Dos poderosas razones por las cuales la productividad en equipos Scrum depende más del Product Owner que del Equipo de Desarrollo

Hola a todos

Muchos equipos ágiles y organizaciones siguen viendo la productividad como:

• cantidad de historias por sprint
• puntos por sprint
• horas por sprint

y parte de este malentendido que arrastramos en la construcción de productos viene del enfoque basado en manufactura, donde eres más productivo entre más unidades por fracción de tiempo seas capaz de construir.

Considerando que en Scrum tienes Product Owner (PO), Equipo de Desarrollo y Scrum Master (SM), correctos y competentes, quisiera compartirte dos razones por las que considero que en un PO es la clave de la productividad de todo el Equipo Scrum, apartando la idea que esta es responsabilidad del Equipo de Desarrollo, veamos:

Por el Enfoque en el Valor

En el Mundo del Desarrollo Ágil, es decir, de Creación de Productos de Software, hacer más por unidad de tiempo no implica que estés generando más valor por unidad de tiempo, es posible que estés generando una buena cantidad desperdicio a muy buen ritmo, y ninguno de tus usuarios estén usando la solución creada o el producto construido generando el retorno de la inversión esperado.

En el Mundo Ágil, Productividad es construir el producto correcto

Y como muchos agilistas y textos dicen:

Es mejor poca velocidad en la dirección correcta, que mucha velocidad en la dirección incorrecta

En el primer escenario te estarás acercando a tu objetivo y en el segundo escenario cada vez te alejarás más, por más rápido que vayas.

Ahora, dentro de un equipo Scrum, el rol responsable de determinar "el qué" es el PO, por lo tanto, él es el encargado de definir que cualquier cosa que se construya sea de altísimo valor y cumpla con las expectativas de la comunidad de usuarios y de los interesados, indistintamente si se construye o no a alto ritmo.

Por el Tamaño en los Ítems de Backlog (Historias de Usuario)

Ahora, partamos de la base que tenemos un grupo de profesionales del mundo del desarrollo de software, un equipo multidisciplinario, con buenas prácticas de desarrollo de software, y un PO, que prioriza constantemente su producto orientado al valor.

¿el generar rápidamente resultados de valor de forma incremental dependerá del Equipo de Desarrollo?

En esencia, ¡NO! la respuesta depende más de del tamaño de los ítems que van a construir, 

Veamos,

• si los ítems o historias de usuario son muy grandes les tomará mucho esfuerzo transformarlas en incrementos de valor, muchas veces hasta varios sprints, generando inconformidad, pues "ese equipo trabaja y trabaja y nada que entrega". Un ejemplo de esto son historias de tamaño superior a 10 días-persona para alcanzar la definition of done.
• un tamaño óptimo fluirá apropiadamente a través del equipo de desarrollo, ejemplo: historias de usuario de 2 a 3 días-persona para alcanzar la definition of done (esto es fruto de la experiencia, me encantaría que lo validaras). En DevOps esto se llama trabajar en Lotes Pequeños o Small-Batches. (Visita este ejemplo si quieres ver un tamaño de historia de usuario razonable -clic aquí-)
• un ítem de backlog demasiado pequeño implicará que el equipo de desarrollo será altamente eficiente construyendo piezas de valor muy pequeñas con alto esfuerzo de manipulación (imagínate escribir una historia de usuario por cada campo de un formulario o de un reporte, desgastante, ¿No cierto?)

Esto es representado en la siguiente gráfica de Donald Reinersten

En el siguiente video, se puede visualizar cómo tener un lote grande - de 10 ítems - (podría asimilarse a una historia de usuario con muchas funcionalidades) es más lento de transportar que un lote pequeño - de 1 ítem - (podría a asimilarse a una historia de usuario, pequeña y de tamaño óptimo)

Al reducir el tamaño de los lotes, una empresa mejoró la eficiencia de las pruebas de sus productos en un 220% y redujo los defectos en un 33%.(2)

Unos Consejos 

A continuación, unos consejos para cerrar:

• La priorización por valor y la construcción de un producto que genere valor es la clave del enfoque ágil. Como lo he compartido antes: 
• "Ágil es sobre gestión de valor y no gestión de alcance"
• "El alcance es un medio para generar valor"
• un buen tamaño de historia de usuario permitirá la fluencia del equipo y entregar funcionalidades de forma continua 
• mi experiencia me ha demostrado que un buen tamaño es de 2 a 3 días-persona en alcanzar la Definition of  Done, sugiero lo experimentes y lo compartas en la zona de comentarios.
• la división, refinamiento o "splitting" de historias de usuario es una excelente práctica requerida ya que permite a los equipos alcanzar buena velocidad en la construcción del producto (1)
• Un buen sprint backlog debe contar aproximadamente con 6 a 10 historias de tamaño similar (1)

Unas Preguntas que Invitan a la Acción

• Como PO
• ¿sabes cuál es el producto correcto?
• ¿sabes cuándo estás construyendo el producto incorrecto? ¿tienes poder para corregir el camino?
• ¿sabes hacer división o refinamiento de historias de usuario?
• ¿logras que las historias de usuario queden de tamaño pequeño para el sprint planning de modo que al equipo le tome 2 a 3 dias-persona lograr la definition of done?
• Como SM
• ¿sabes guiar a tu PO en los aspectos mencionados anteriormente?

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario (clic aquí)
2. Six Myths of Product Development by Stefan Thomke and Donald Reinertsen. https://hbr.org/2012/05/six-myths-of-product-development

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

Cómo Estimar la Capacidad (Velocidad) de tu Equipo Scrum en el Primer Sprint