#RespuestasAgiles: ¿Qué es la mentalidad Lean-Agile?

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.

Cómo Lograr el Cambio Lean-Agile en Grandes Corporaciones

Hola a todos,

Movilizar organizaciones de gran tamaño, es decir, con más de 500 personas (y hasta donde lo he vivido con más de 500.000), hacia una cultura lean-agile de innovación representa un desafío significativo que requiere de múltiples frentes de acción, enfoque sistémico y tiempo para consolidar el cambio. A menudo, para explicar este proceso, utilizo la metáfora de perder peso y mejorar el estado físico para obtener una mejor salud; lo cual implica acciones constantes, persistentes para lograr la meta; y mucha disciplina para que el cambio sea perdurable.

La clave para lograr una mejor salud y perder peso (como muchos lo hemos vivido), es cambiar hábitos, realizar chequeos frecuentes con el médico y acompañarse de un buen conjunto métricas que nos permitan medir nuestro progreso. De manera similar, el cambio organizacional requiere de chequeos constantes, la adopción de nuevos hábitos y la implementación de buenas métricas para evaluar el progreso y determinar si se está avanzando en la dirección. En la siguiente tabla se comparte la similitud más detallada que se observa de ambas perspectivas:

Esfuerzo para bajar de peso y tener buena salud	Cambio organizacional requerido para generar una cultura organizacional lean-agile
Definir metas claras y específicas	Establecer objetivos y KPIs medibles
Crear un plan de alimentación saludable	Crear un plan de acción para la adopción de prácticas lean-agile en la organización
Ejercitarse regularmente	Implementar procesos ágiles y colaborativos en el trabajo en equipo
Controlar la ingesta de calorías	Fomentar la transparencia y el trabajo en equipo en todos los niveles de la organización, Limitar el WIP; evitar hacer proyectos o inciativas que impliquen desperdicio, es decir, gestión lean del portafolio de iniciativas.
Monitorizar el progreso	Establecer procesos de seguimiento y evaluación frecuentes para medir el progreso y la mejora
Mantener una actitud positiva y motivada	Fomentar una cultura de innovación y mejora continua
Aprender a cocinar comidas saludables	Proporcionar capacitación y entrenamiento para el uso de metodologías lean-agile a todos los niveles de liderazgo
Dormir lo suficiente	Fomentar un equilibrio entre trabajo y vida personal, cuidar que no se presente el burnout o desgaste profesional, y proporcionar espacios para la mejora o afilar el hacha (1)
Reducir el consumo de alcohol	Fomentar una comunicación abierta y honesta en la organización
Buscar apoyo y motivación	Fomentar el trabajo en equipo y la colaboración entre los empleados

Retos del cambio

Pero no todo es color de rosa. En las grandes organizaciones se sufre mucho para generar cualquier cambio y generar una nueva versión de cultura. Las razones son una y otra vez esbozadas por especialistas, estudios, consultoras (2)(3)(4)(5)(6):

1. Temor a lo desconocido o preferencia por lo conocido y al statu quo (4)
2. Miedo al fracaso 
3. Amenaza a las habilidades y competencias existentes (6)
4. Cultura basada en silos o cultura inflexible, aún más, la empresa es tan grande que el área, sección, división, sede o región tiene una subcultura dominante.
5. Miedo e incomprensión del cambio (falta de información) (4)(6)
6. Amenaza a la posición y a los propios intereses 
7. Las personas creen que tienen un plan mejor (4)(6)
8. Poca claridad sobre el propósito y los beneficios del cambio.
9. Resistencia de los mandos medios al cambio

Pero no todo está perdido, a pesar de la existencia de fuerzas que puedan actuar en contra del cambio, es posible lograrlo mediante diversas estrategias. Algunas de estas incluyen la adopción de enfoques livianos como el Lean Change Management o métodos estructurados como los 8 pasos de Kotter. (10). 

Santo Grial del Cambio

Sin embargo, mi intención con este artículo no es proporcionar un resumen de disfunciones y estrategias, pues hoy en día esta información se puede generar fácilmente con Bing o con la ayuda de ChatGPT. Más bien, deseo compartir mi experiencia y lo que, en mi opinión, representa el "Santo Grial del cambio para grandes corporaciones" de forma que se logré avanzar de forma relativamente uniforme en diferentes culturas, geografías y áreas:

Primer elemento: Cambio top-down

Cambio de arriba hacia abajo, aunque apoyo y promuevo generar cambios y hacer experimentos a nivel de áreas y equipos de trabajo, he observado que para que un cambio sea permanente en grandes corporaciones se requiere de un enfoque top-down, de lo contrario fácilmente desaparecerá, debido a que no hace parte del standard organizacional.

"Ningún cambio permanece en un entorno corporativo si no existe un enfoque top-down"

Es crucial que la decisión corporativa de cambio provenga del comité ejecutivo y que la poderosa coalición mencionada por Kotter esté compuesta por los C-level o la capa directiva. Por consiguiente, es esencial que este equipo directivo esté involucrado y comprometido con el cambio, viviendo y promoviendo los nuevos valores y formas de tomar decisiones que desean para la organización. Para lograr esto, es recomendable aplicar el modelo de las 4D del cambio cultural de Fred Kofman, propuesto en su modelo de Conscious Business Coaching:

• La cultura se Define
• La cultura se Demuestra
• La cultura se Demanda
• La cultura se Difunde

En otras palabras, el equipo de liderazgo comprende los conceptos de agilidad y lean, trabajan juntos como un equipo ágil y fomentan la agilidad en toda la organización. Además, saben cómo propagar estos valores en sus respectivas áreas y equipos. Y como probablemente ya lo estás pensando, los miembros de este equipo de liderazgo son los primeros en ser identificados como agentes de cambio en la organización y, por lo tanto, son los primeros en recibir entrenamiento sobre este tema.

Para cerrar este primer elemento, quisiera citar una frase de un gran amigo y agile coach, con la cual resueno mucho:

“Cambia la forma en que se toman las decisiones y cambiarás la organización y la cultura”. -Wbeimar Andrés Vásquez Ramírez (11)

y como se infiere, la mejor manera de intervenir la forma que se toman las decisiones, es hacerlo desde la capa directiva.

Segundo elemento: Un índice cuidadosamente construído que permita evidenciar el cambio

Cuando hablo de un índice (completamente distinto a un kpi:key performance indicator)(13), pues similar como para la buena salud requerimos tener valores adecuados en:

• Ritmo cardiaco
• Presión Arterial
• Temperatura corporal
• Nivel de colesterol
• Nivel de glucemia
• Saturación de oxígeno
• Índice de masa corporal (IMC)

para una organización que quiere ser Lean-Agile, debe monitorear al menos frecuentemente:

• Time to market
• Satisfacción del cliente
• Satisfacción de los empleados
• Frecuencia de entrega
• Densidad de defectos
• Grado de innovación
• ROI
• Entendimiento de Lean-Agile en la organización

Por lo tanto, la clave estará en generar un índice que incluya los anteriores elementos como variables (o los que la organización considere relevantes para su definición de empresa Lean-Agile exitosa), convirtiéndose en un polinomio cuidadosamente entrelazado que permita determinar en qué estado se encuentra la organización y si se está logrando la meta o no. Para el éxito del uso de este índice se debe cumplir adicionalmente que:

1. este índice servirá para medir a todo nivel de liderazgo tanto vertical y horizontalmente
2. los sistemas de medición permitan recolectar y presentar la información en tiempo real o lo más cercano al mismo
3. todos tengan acceso al estado del índice y sepan cómo se encuentra su área, su vertical y el valor de toda la organización en general
4. se establezcan metas bimestrales o trimestrales iguales a ser alcanzadas por todos en la organización
5. todos comprendan cómo se calcula y cómo obtienen mejores resultados

En TCS, empresa en la que trabajo, se cuenta con un índice llamado AgilityDebt (TM) (9) que cumple lo anterior, generando una fuerte alineación a nivel de liderazgo y resolviendo problemas sistémicos en esta gran corporación (12). De igual forma, se ha experimentado este enfoque con otros grandes clientes generando resultados similares.

¿Por qué Santo Grial del Cambio?

Existen dos razones poderosas, adicional al verlo funcionar en mi día a día, por las cuales considero que lo anterior funciona en entornos de alta complejidad sistémica y grandes corporaciones:

1. Compromiso y entendimiento de la alta dirección: el cual es clave en cualquier proceso de cambio, adicional, las 4D de la cultura terminan impregnando toda la organización, cumpliendo la máxima de Gandhi "se el cambio que quieres ver en el mundo"
2. Un buen índice generará un buen comportamiento corporativo: Debido a que se cumple la máxima del management inferida de Deming "Como me midas me comporto" (7); y al medir el desempeño de los líderes con esta métrica, suavizará muchos elementos friccionantes enumerados al inicio del artículo.

Cerrando y una advertencia

Para cerrar, quisiera insistir en otra frase del management compartida por Deming:

"Las personas con objetivos y trabajos que dependen de cumplir estos objetivos seguramente los alcanzarán, aunque tengan que destruir a la empresa para ello" - W Edwards Deming

Construir una BUEN ÍNDICE es clave para el éxito en organizaciones grandes y complejas; de forma equivalente, un mal índice destruiría valor y generaría problemas organizacionales.

Es importante que quienes promueven este tipo de métricas organizacionales vigilen si se está generando un comportamiento virtuoso de la organización o sí se está incurriendo en comportamientos desgastantes y autodestructivos. 

Quisiera cerrar evocando al Señor de los Anillos, como me lo sugirió mi gran amigo Rodrigo Burgos al hablar sobre este tema del índice clave:

"Una métrica para coordinarnos entre todos, una métrica para gestionar el cambio, una métrica para ayudarnos y hacernos una empresa más Lean-Agile, permitiéndonos responder mejor al cambio y seguir teniendo éxito"

Bienvenidos tus comentarios.

Saludos Ágiles

Jorge Abad.

Notas, Aclaraciones y Referencias

1. [Tip Scrum]: 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
2. Resistencia al cambio, el eterno desafío - https://www.forbes.com.mx/red-forbes-resistencia-al-cambio-el-eterno-desafio/
3. Managing Resistance to Change Overview - https://www.prosci.com/resources/articles/managing-resistance-to-change
4. Ten Reasons People Resist Change - https://hbr.org/2012/09/ten-reasons-people-resist-chang
5. Understanding Why People Resist Change - https://www.prosci.com/blog/understanding-why-people-resist-change
6. Teaching guide: Kotter and Schlesinger's reasons for resistance to change - https://www.aqa.org.uk/resources/business/as-and-a-level/business-7131-7132/teach/teaching-guide-kotter-and-schlesingers-reasons-for-resistance-to-change
7. Una Conclusión: Cómo me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
8. Frase: Que sucede cuando nuestro trabajo depende del logro de objetivos - http://www.lecciones-aprendidas.info/2019/11/people-with-targets-and-jobs-dependent.html
9. Living agile, the TCS way - https://www.tcs.com/who-we-are/tcs-way/article/tcs-agile-transformation-story-approach-methodology
10. Los 8 pasos de Kotter, o como algunos lo ven, la lista de verificación constante del cambio de Kotter está compuesta por:
• Crear un sentido de urgencia.
• Formar una coalición poderosa.
• Crear una visión que respalde el cambio. 
• Comunicar la visión. 
• Eliminar obstáculos. 
• Lograr victorias en el corto plazo.
• Consolida tus triunfos e incentiva más cambios.
• Anclar los cambios en la cultura corporativa.
11. Frase Cambio Cultural y Cambio Organizacional - http://www.lecciones-aprendidas.info/2023/03/frase-cambio-cultural.html
12. En el siguiente enlace puedes ver el detalle de estrategia de cambio que se llevó a cabo en la organización - http://www.lecciones-aprendidas.info/2021/10/video-moviendo-tcs-500000-personas-la.html
13. Un índice es una medida estadística que resume el comportamiento de un conjunto de datos o variables. Un kpi (key performance indicator) es un indicador clave de desempeño que mide el grado de cumplimiento de un objetivo o meta. La diferencia entre índice y kpi es que el primero es más general y puede aplicarse a diferentes contextos, mientras que el segundo es más específico y está vinculado a una estrategia o plan de acción. Un ejemplo de índice es el índice de precios al consumidor (IPC), que refleja la variación de los precios de una canasta de bienes y servicios. Un ejemplo de kpi es la tasa de conversión, que mide el porcentaje de visitantes que realizan una acción deseada en un sitio web.

La Excusa SOX

Constantemente en procesos de Transformación Agile-DevOps me encuentro con lo que he llamado: “La Excusa SOX*”, es decir, me objetan alivianar los procesos diciendo: - “el proceso no puede ser más liviano porque SOX no lo permite”, a lo que respondo:

“Si tu freno para tener procesos más livianos (LEAN-Agile-DevOps) son todos los formatos de SOX ¿Cómo hacen en AMAZON, NETFLIX, etc., para salir a producción CIENTOS de veces al día, sabiendo que son empresas mucho más reguladas, tienen SOX y están en la bolsa de Nueva York?”

Siempre concluyo que el problema no es la regulación, sino la mentalidad en áreas de riesgos y procesos al implementarla; y su falta de mejora continua buscando simplificar y automatizar cada vez más el proceso. 

*SOX: Ley Sarbanes-Oxley - https://es.wikipedia.org/wiki/Ley_Sarbanes-Oxley

El peligroso espejismo de la "Metodología Híbrida" en el mundo del software

Hola a todos

Hace poco tuve tres momentos en donde la metodología o enfoque híbridos de trabajo me los he topado y considero que es valioso escribir y aclarar sobre ellos:

Primer Momento: hablando a cerca del Lean Business Agility Model (LBAM) con el PMI Antioquia, me preguntaban mi opinión sobre el modelo híbrido, en esencia mi respuesta fue:

"Si lo que se está pensando es llevar prácticas de lo tradicional al mundo ágil, esto NO es exitoso, lo contrario sí puede serlo"

Segundo Momento: en varios clientes para los cuales trabajo me están comenzando a decir: "No, no somos ágiles, tenemos una metodología híbrida" y cuando voy a ver, están haciendo proyectos a alcance, tiempo y costo fijo por sprints, sobre lo cual hablaré más adelante.

Tercer Momento: en el reporte de Certiprof Anual - clic aquí -, el cual recomiendo ampliamente pues la mayoría de quienes lo respondemos somos latinos, y cuenta con interesantes hallazgos para nuestra cultura y región; Lucho Salazar y yo opinábamos sobre la aproximación híbrida en la ejecución de proyectos:

CertiProf Agile Adoption Report 2022

"Muchas organizaciones en su acercamiento a la hacia la agilidad han adoptado marcos híbridos, es decir, combinan prácticas ágiles y tradicionales; lo cual es ilustrado en la gráfica. Aunque este enfoque no es la mejor práctica, es un inicio que invita a seguir cambiando, pero si se continua allí puede constituirse en un riesgo a largo plazo, debido a que quienes abrazan la agilidad completamente logran aumentar entre tres a cuatro veces su productividad, tomando una ventaja creciente sobre las híbridas" - Jorge H. Abad L.

---

“Cada día un mayor número de organizaciones están trabajando con un enfoque Agile y Lean. El hecho de que la mitad del estudio los participantes respondieron que usar un enfoque híbrido es natural, dado que la mayoría de las empresas se encuentran actualmente en un proceso de cambiar de las prácticas tradicionales de gestión y ejecución a los basados ​​en el pensamiento ágil. Este es un proceso lento que puede llevar años. Las organizaciones no pueden y no debe comprometerse con un gran cambio o un cambio de "todo o nada", porque primero deben aprender a lidiar con los impactos del cambio y es mejor empezar poco a poco, con una o dos iniciativas. A partir de ahí, a medida que aprenden de las reacciones del entorno, pueden agregar nuevos equipos y áreas de la empresa al proceso. El hecho de que una de cada tres empresas ya esté utilizando un enfoque Agile es consistente con el trabajo que se ha estado haciendo desde la década pasada. Estas empresas han recorrido un largo camino para entender, internalizar, practicar y promover una cultura de colaboración y innovación, pilares esenciales de las organizaciones exitosas de hoy”. - Lucho Salazar

Pero vamos por partes, entendamos el por qué del título de este artículo.

¿Qué es una metodología híbrida?

Inspirado en la "Figure 2-7. Development Approaches del PMBoK 7.0

Un enfoque híbrido, está definido por: "Un enfoque de desarrollo híbrido es una combinación de enfoques adaptativos y predictivos. Esto significa que se utilizan algunos elementos de un enfoque predictivo y otros de un enfoque adaptativo. Este enfoque de desarrollo es útil cuando existe incertidumbre o riesgo en torno a los requisitos. Híbrido también es útil cuando los entregables se pueden modularizar, o cuando hay entregables que pueden ser desarrollados por diferentes equipos de proyecto. Un enfoque híbrido es más adaptativo que un enfoque predictivo, pero menos que un enfoque puramente adaptativo." (1).

Por lo tanto, no es un enfoque donde nos estamos preguntando y validando constantemente "si lo que se está construyendo o entregando es la solución correcta", como ocurre en el mundo del desarrollo de software, pero tampoco se tiene completa certidumbre sobre el resultado final, un ejemplo podría ser el despliegue de un nuevo proceso organizacional, que implique construcción de instalaciones, capacitaciones, desarrollo de software (este software se debe desarrollar con una aproximación ágil) y construcción de máquinas; son varios frentes que se pueden modularizar para entregar valor de forma incremental.

Alguien dirá: ¿Pero en el desarrollo de una solución de software sabemos que módulos vamos a tener? Posiblemente sí, pero el enfoque ágil (adaptativo) te garantiza que no construyas software de desperdicio, y la constante repriorización y refinamiento del backlog, sumado al despliegue continuo de la solución (que te permite su validación) puede significar que se halló valor mucho antes implicando que los supuestos iniciales quedaron obsoletos, pero logrando economias mayores 60% debido a su enfoque basado en Pareto (2).

¿Por qué es un espejismo peligroso en el mundo del desarrollo de software?

Por las siguientes razones:

• Es una zona cómoda: he observado que se denomina híbrido a trabajar en cascada en grandes corporaciones, de forma que ya no es necesario tener al usuario con el equipo, ni es requerido que validen las soluciones. es decir,

el mismo desperdicio de siempre,

requerimientos al inicio, esfuerzo del proveedor, controles de cambio y quejas del cliente porque no entregaron lo que se pidió. Por lo tanto,

 Híbrido es el nombre de la nueva cascada corporativa

Observo que son organizaciones que no aprendieron a trabajar de forma ágil, no saben como hacer ahorros con este enfoque (aún siguen diciendo que ágil es costoso, lo cual es falso), pero para no verse muy anticuadas llamando a su metodología tradicional o cascada, le llaman híbrida, la cual es un desperdicio de tiempo, dinero, y oportunidad de generar valor por donde quiera que se le mire.

• Están poniendo reglas de cascada a proyectos ágiles:  he visto que se llama metodología híbrida al ponerle al desarrollo ágil las reglas de cascada, es decir, alcance, tiempo y costo fijo, pero eso sí, hecho en sprints, pero sin retrospectivas porque no es necesario aprender más ¡Plop! - recomiendo leer la referencia (3)-.

• Se está perdiendo oportunidad de generar y atrapar más valor: las organizaciones al casarse con este modelo híbrido (insisto no veo problema con que sea algo temporal, lo que veo peligroso es que de allí no se evolucione), están perdiendo oportunidad de capturar valor y de generarlo a sus clientes y más temprano que tarde, organizaciones que realmente si ejecuten ágil de forma disciplinada les tomarán una ventaja exponencial, debido a que la agilidad bien practicada cuadruplica la generación de valor y la eficiencia de los equipos.

¿Cómo evitar el espejismo?

Hay varias estrategias que pueden ayudar en evitar el espejismo:

• Comprender en que consiste la mentalidad lean-agile (3).
• Comprometerse a ejecutar los proyectos ágiles (y por ende de desarrollo de software) con las reglas de ágil, de forma que se generen ahorros y altos impactos.
• Si se tiene un proyecto tradicional y quiere volverlo híbrido, identifique posibles módulos, formas de generar valor temprano y retroalimentación valiosa en caso de que aplique; de manera que logre adaptaciones en caso de ser posible.
• No lleve prácticas tradicionales al mundo ágil, es decir, planeación predictiva para el mundo del software, pues estas no van a servir.

Para cerrar, algunas ideas ágiles para el mundo tradicional

Como se ha argumentado en el artículo, llevar prácticas tradicionales al mundo ágil es desperdicio y fricción, pero existen prácticas ágiles que pueden mejorar el mundo tradicional, a continuación, algunas ideas:

• tener dailys de sincronización del equipo de trabajo
• hacer retrospectivas o sesiones de mejora con cadencia de al menos de una vez al mes.
• usar backlogs y priorizarlos constantemente si la naturaleza del proyecto lo permite.
• preguntar y preguntarse constantemente ¿si lo que se hace está generando valor? y corregir en caso de que no.
• Identificar mínimos productos viables y liberarlos incrementalmente: 
• Ejemplo 1: Una casa de campo de forma incremental y adaptativa (pues no se posee todo el dinero), un posible plan de releases puede ser:
• Release 1 o MVP (PMV - Producto mínimo viable): La cocina, el baño, y una habitación para dormir.
• Release 2: otro cuarto
• Release 3: la sala
• Release 4: la piscina
• Release 5, etc, etc.
• Ejemplo 2: Una unidad residencial de 12 torres
• Release 1: torre 1 y 2 
• Release 2: torres 2 y 3
• Release 3: la piscina y el salon social
• Release 4: no se realizó debido a cambios económicos del entorno.

 

Hasta acá este compartir.

Bienvenidos tus comentarios

Saludos ágiles

Jorge Abad.

Referencias, aclaraciones, notas y comentarios

1. A Guide to the Project Management Body of Knowledge PMBOK® GUIDE. Seventh Edition
2. La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum? (clic aquí)
3. ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? (o ¿Por qué no puedes contratar en alcance, tiempo y costo fíjo un proyecto ágil?) 
4. Esto lo explico ampliamente en el libro: Nuevas Aguas, Nuevos Navíos, Nuevos Navegantes: Business Agility con notas sobre Transformación Digital (clic)

La Agilidad ha Muerto, ¡Larga Vida a la Agilidad!

Hola a todos.

Ya han pasado los primeros años de lanzamiento de la Agilidad donde:

• la gente no creía en scrum
• no se sabía que había un método Kanban
• las empresas no creían que estuviésemos en tiempos disruptivos y altamente cambiantes
• se exigía predictibilidad en proyectos de software (solo para cuestionarte: ¿aun lo exiges?)
• en las bolsas de empleo no sabían que era un Agile Coach, un Scrum Master, un Product Owner o un ingeniero DevOps
• Los cursos de Scrum Master eran costosísimos

Lindos e inocentes años, no lo niego, tenían la magia del descubrimiento y la novedad.

Hoy la agilidad para muchas empresas ha muerto, pasó por su abismo de desilusión, según el Ciclo de Sobreexpectación de Gartner (1), y es cuando vemos que fracasaron en sus iniciativas de transformación por muchas razones, una de tantas, creyeron que solo era un cambio de procesos y no de mentalidad; llegando al caso de odiar la palabra Ágil o Agilidad; lo anterior es cierto, lo he vivido varias veces, me dicen: "necesitan agilidad pero no les puedes mencionar esa palabra", ni siquiera les gusta decir que sus proyectos son ágiles,  prefieren llamarlos híbridos o que continúan en cascada.

Ciclo de sobreexpectación de Gartner(1)

A otras organizaciones, las encontramos ya sea descendiendo al abismo de desilusión o subiendo en la rampa de consolidación, debido a su ágil mediocre con prácticas como:

• equipos ágiles de 3 personas con 7 proyectos
• equipos ágiles de una sola persona, con varios proyectos también
• Scrum Master con 5 equipos y 10 proyectos
• Product Owners desaparecidos de sus iniciativas
• Product Owners con 5 proyectos
• proyectos ágiles con alcance, tiempo y costo fijo (2) 
• que critican las implementaciones BY THE BOOK (3)
• usan OKRs, a diestra y siniestra, sin un verdadero cambio interno.
• creen que un Scrum Master es un gestor de muchos proyectos
• son expertas en SAFe, LeSS, modelo Spotify, de tribus, pero que arrastran la deuda técnica iteración tras iteración, y exigen una "predictibilidad ágil" que ni cuidan, ni cultivan
• gerentes que sobresaturan el WIP (work in progress) de sus áreas de trabajo y las acusan de lentas
• empresas que no transforman su mentalidad y creen que es hacer lo mismo de siempre, pero con otro nombre.
• personas que asisten a cursos de Scrum + PO + OKr + Workshop de Jira por 50 dólares, por un total de 24 horas.

Estamos en un momento donde hay mucho conocimiento y poca implementación disciplinada, similar a como se encuentran hoy en día en manufactura los que promueven Lean; pues Lean tuvo su boom hace más de 30 años, pero actualmente, muchos se quedan en las prácticas y solo consiguen un 20% a 30% de mejora, pero quienes realmente lo aplican con toda la rigurosidad, amor, filosofía, paciencia alcanzan impactos del 200% al 300% en la productividad; misma promesa que la Agilidad cumple con creces en el mundo del software y el empresarial.

La meseta de la productividad está a la espera de quienes quieran pasar de un "Hacer Ágil" de solo prácticas, un ágil mediocre o un ágil de nombre, a un ágil de mejora continua y alto desempeño, en el que se embarcan quienes quieren vivir un proceso de transformación coherente, consistente, gradual, donde se impacten cultura, formas de trabajo, procesos, tecnología a nivel estratégico, táctico y operativo.

Quisiera terminar como empecé:

La Agilidad ha muerto, ¡larga vida a la Agilidad!

o mejor,

La Agilidad ha muerto, ¡larga vida a la verdadera Agilidad!

Saludos ágiles,

Jorge Abad.

Referencias

1. Ciclo de sobreexpectación (Gartner hype cycle) - https://es.wikipedia.org/wiki/Ciclo_de_sobreexpectaci%C3%B3n
2. ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? http://www.lecciones-aprendidas.info/2018/11/por-que-no-contratar-en-cascada-un.html
3. Diatriba: "by the book" una frase que me produce escozor - http://www.lecciones-aprendidas.info/2020/01/diatriba-by-book-una-frase-que-me-produce-escozor.html

Presentación y Video: Introducción a Lean para Managers

Introducción a lean para managers from Jorge Hernán Abad Londoño

Presentación : Lean para Managers

Lean para managers - Por Jorge H. Abad L. from Jorge Hernán Abad Londoño

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" 

Mi viaje como Agile Coach

Hola a todos,

Hace poco cuando compartía con un equipo de Scrum Masters, hablando sobre prácticas y métodos revisábamos la famosa imagen (1) en la cual se presentan los valores, principios, prácticas y frameworks,

Imagen adaptada de Ahamed Sidky

y que si la giras un poco, vas a ver los elementos visibles e invisibles de la cultura,

aquellos que consisten en "Hacer" y "Ser", y en nuestro contexto "Hacer Ágil" y "Ser Ágil".

En donde, todo viaje de transformación parte desde los elementos visibles hacia los invisibles, transformándonos de afuera hacia adentro,

o ¿Quién cambia por arte de magia? La verdad, desde mi punto de vista y experiencia, no creo en los cambios repentinos, creo en los procesos, todo cambio requiere un esfuerzo, un delta que me permita pasar de un estado A a un estado B, y parte de algo afuera que te lleva a mover cosas adentro.

Pero bueno, el punto acá es como ha sido mi jornada de cambio, recuerdo mucho a mis inicios en el mundo ágil me reencontré con un gran estudiante que tuve en la clase de Taller de Ingeniería de Software en Eafit, Jorge Luis Valderrama, recuerdo que estaba por Colombia, pues vivía en Londres, y en varias charlas suyas y conversaciones a la que asistí, hablaba siempre desde el Manifiesto Ágil - http://agilemanifesto.org/-, y recitaba sin titubear sus valores y principios, y ante cualquier duda buscaba que principios promovía o violaba aquello sobre lo que era cuestionado. Debido a esto, me animé a imprimir y pegar en frente mío, en mi escritorio de oficina los valores y principios del manifiesto ágil, y ante cualquier duda me remitía al manifiesto ágil, frase que repite constantemente mi gran amigo Juan Andrés Ochoa:

"Ante una duda en cómo actuar, remítase al Manifiesto Ágil" -Juan Andrés Ochoa

 

De esa manera, emprendí mi viaje desde los principios y valores, luego aprendí en orden Scrum, Nexus, el Modelo Spotify, Kanban, SAFe, LeSS, Scrum at Scale, Discipline Agile. No fue fácil esa jornada, recuerdo que me tomó al menos 6 meses dejar el micromanagement y hacer gestión de horas, para comenzar a confiar en los puntos de historia.

Y en ese viaje de ida, siempre la mentalidad ágil me ha acompañado, permitiéndome ser crítico y ver valor en prácticas tradicionales y flexibilizar mi mente y prácticas en procesos de transición organizacional que acompaño (les recomiendo leer Empático mas no Complaciente). Pero al toparme con SAFe y Kanban, observé que me faltaba algo, y era Lean (o el Modelo de Producción de Toyota escrito en términos occidentales). Comprendí que en mi jornada había olvidado las bases del mindset ágil, y comencé mi recorrido de regreso, centrándome en dos preguntas fundamentales: 

¿qué es el mindset ágil?

 ¿y qué rayos es lean?

En ese viaje de regreso, he tenido bastantes libros, charlas y conversaciones como compañeros, y recomiendo revisar detalladamente:

• El corazón de la agilidad, promovido por Alistair Cockburn (2)
• La Agilidad Moderna, promovido por Joshua Kerievsky (3)
• Lean (4)

 

El Corazón de la Agilidad (2)

Agilidad Moderna (3)

A este punto de la historia, he logrado sintetizar lo que es para mí el mindset Lean-Agile, la clave que desencadena la productividad, la felicidad y alto desempeño:

• Flujo
• Entrega de Valor
• Reflexión (Inspección y Adaptación)
• Colaboración
• Mejora Continua
• Eliminación de desperdicios

Pilares de la mentalidad Lean-Agile. Elaboración propia.

Al tuétano, al núcleo de este asunto que me apasiona y por el cual llegaste hasta este punto del artículo, lo comparto constantemente, lo considero fundamental, para poder desenvolverse en este mundo disruptivo y exigente; mis entrenamientos y conversaciones tienen un énfasis en el mindset lean-agile y cómo este funciona independiente del framework, marco, metodología o proceso y con esta perspectiva acompaño a equipos y organizaciones en su jornada de transformación.

Sé que no hay que dejar de hacer una cosa sin descuidar la otra, es decir, avanzar en el conocimiento de nuevas aproximaciones y marcos, pues hace parte de "estamos descubriendo formas mejores de"(5),  sin dejar el corazón, el corazón te permite moverte con propósito y libertad entre las diferentes interpretaciones, implementaciones o, más aún, desarrollar tu propia versión de la agilidad y de lean.

Yo no sé cómo será tu viaje, te he compartido el mío, con seguridad en tantos ires y venires nos terminaremos encontrando. Solo te quiero hacer tres preguntas:

¿En dónde estás en tu viaje hacia la agilidad, como Scrum Master, como Agile Coach, o como líder en tu organización?

¿Qué tanto conoces y dominas Lean?

¿Ves útil o inútiles artículos sobre mindset o atraen más los marcos complejos e hiperconectados con flechas?

Hasta acá este compartir, bienvenidos sus comentarios.

Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Imagen de Ahamed Sidky
2. Corazón de la Agilidad - https://heartofagile.com/
3. Agilidad Moderna (Modern Agile) - https://modernagile.org/
4. Lecturas recomendadas sobre lean
• Esto es Lean - https://www.amazon.com/-/es/Niklas-Modig-ebook/dp/B019E91600
• 2 second Lean - https://paulakers.net/books/2-second-lean
• Las claves del éxito de Toyota: 14 principios de gestión del fabricante más grande del mundo - https://www.amazon.com/-/es/Jeffrey-K-Liker-ebook/dp/B07XLFGTQB
5. Agile Manifesto - http://agilemanifesto.org/iso/es/manifesto.html

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

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