Priorizar vs. Ordenar el Backlog: Más Allá de la Semántica

Imagen generada por DALL-E

Hola a todos,

Durante mucho tiempo, en mis entrenamientos de Scrum, solía decir que el Product Backlog se "prioriza". Sin embargo, al analizar con más detenimiento la Guía Scrum 2020, noté que el término correcto es "ordenar". Aunque podría parecer una diferencia semántica, en realidad, tiene profundas implicaciones en la manera en que gestionamos el trabajo del equipo. Ordenar no es simplemente priorizar; es entender el contexto, los diferentes tipos de trabajo y las necesidades estratégicas del negocio para decidir el orden en el que se abordarán los ítems.

¿Qué Significa Ordenar un Backlog?

Ordenar implica más que asignar niveles de importancia o urgencia. Es un proceso que requiere una comprensión holística de todos los elementos que componen el backlog y sus interrelaciones. Veamos en qué se diferencia ordenar de priorizar:

1. Ordenar: Organizar ítems en función de múltiples criterios como riesgo, valor, complejidad, dependencias y necesidad estratégica. Requiere un entendimiento profundo del entorno y de cómo cada ítem contribuye al objetivo general del producto.
2. Priorizar: Asignar un nivel de importancia o urgencia a cada tarea. Este enfoque puede ser útil, pero se queda corto cuando hay múltiples dimensiones a considerar.

Un Ejemplo Cotidiano

Supongamos que tienes las siguientes tareas en un día ocupado:

1. Preparar un informe para una reunión importante.
2. Responder correos electrónicos pendientes.
3. Llevar a cabo una tarea de investigación para un proyecto a largo plazo.
4. Hacer una llamada de seguimiento a un cliente insatisfecho.
5. Organizar tu escritorio y archivar documentos.

Si decides priorizar, podrías hacer lo siguiente:

1. Preparar un informe para una reunión importante.
2. Hacer una llamada de seguimiento a un cliente insatisfecho.
3. Responder correos electrónicos pendientes.
4. Llevar a cabo una tarea de investigación para un proyecto a largo plazo.
5. Organizar tu escritorio y archivar documentos.

Aquí, has ordenado las tareas basándote únicamente en la importancia y urgencia. Pero, ¿qué pasa si hay dependencias o restricciones de tiempo? ¿Y si la llamada con el cliente solo puede hacerse a cierta hora? La prioridad cambia.

Si decides ordenar, podrías hacerlo así:

1. Preparar un informe para una reunión importante.
2. Hacer una llamada de seguimiento a un cliente insatisfecho a la hora acordada.
3. Organizar tu escritorio mientras esperas la hora de la llamada.
4. Responder correos electrónicos mientras esperas respuesta del informe.
5. Llevar a cabo la investigación cuando tengas tiempo concentrado disponible.

Aquí, has tenido en cuenta no solo la importancia, sino también la disponibilidad de tiempo, las dependencias y el contexto.

Ordenar el Backlog: Un Ejercicio Complejo

Llevemos esto al mundo de Scrum. Imaginemos un backlog con los siguientes ítems:

1. Corregir un bug crítico que afecta a muchos usuarios.
2. Implementar una nueva funcionalidad solicitada por un cliente clave.
3. Actualizar la documentación técnica del proyecto.
4. Realizar pruebas de carga en el sistema.
5. Mejorar la interfaz de usuario en la pantalla de inicio.

Priorizar el Backlog:

1. Corregir un bug crítico (Alta prioridad por impacto).
2. Implementar nueva funcionalidad (Importante para la satisfacción del cliente).
3. Realizar pruebas de carga (Esencial para la estabilidad).
4. Mejorar interfaz (Mejora la experiencia, no urgente).
5. Actualizar documentación (Baja prioridad).

En este caso, hemos asignado prioridades basadas en urgencia e impacto. Pero, ¿qué pasa si el equipo necesita mejorar la documentación antes de implementar la nueva funcionalidad para evitar errores? La prioridad cambia.

Ordenar el Backlog:

1. Corregir un bug crítico.
2. Actualizar la documentación técnica (necesario para implementar correctamente la nueva funcionalidad).
3. Implementar nueva funcionalidad.
4. Realizar pruebas de carga después de la nueva funcionalidad.
5. Mejorar la interfaz de usuario.

En este ejemplo, hemos considerado no solo la importancia, sino también las dependencias y el contexto. Esto es lo que realmente significa ordenar un backlog.

¿Por Qué es Importante Comprender la Diferencia?

Cuando el Product Owner ordena el backlog, no se limita a clasificar ítems por prioridad, sino que considera factores como:

• Dependencias Técnicas y Funcionales: Un ítem podría ser más prioritario, pero si no se cumplen ciertas condiciones previas, no puede abordarse.
• Riesgos: Un ítem con menor prioridad podría tener un riesgo elevado que lo convierta en un foco de atención temprano.
• Impacto Estratégico: Hay ítems que, aunque no parezcan urgentes, son esenciales para el crecimiento del negocio a largo plazo.

Por lo tanto, existen varios criterios que puedes utilizar para ordenar los ítems del backlog. La elección de los criterios dependerá de los objetivos, contexto y momentos específicos. Aquí algunos de los más comunes:

• Urgencia: Priorizar según plazos o fechas límite.
• Importancia: Relevancia de la tarea para los objetivos a largo plazo.
• Impacto: Qué tan significativa es la tarea en los resultados finales.
• Complejidad: Ordenar tareas más simples antes para liberar recursos.
• Riesgo: Considerar tareas que podrían tener consecuencias negativas significativas si no se completan a tiempo.
• Dependencia: Priorizar tareas que desbloquearán o permitirán el progreso en otras.
• Retorno de Inversión (ROI): Evaluar qué tareas ofrecen mayor retorno de inversión en tiempo, esfuerzo o recursos.
• Valor percibido: Dar prioridad a las tareas que se consideran más valiosas desde una perspectiva personal o de equipo
• Recursos disponibles: Considerar los recursos, como tiempo y presupuesto, disponibles para cada tarea. Priorizar tareas que se pueden completar con los recursos disponibles.
• Capacidad personal: Considerar tu propia capacidad y disponibilidad para realizar las tareas. Priorizar tareas según tu habilidad y disponibilidad en un momento dado.

La combinación y ordenamiento de estos criterios o la elección de uno sobre otro dependerá de la naturaleza específica de las tareas y metas; y por lo tanto, se pueden ajustar y personalizar estos criterios según tus necesidades y circunstancias particulares.

Pasos para un Ordenamiento Efectivo del Backlog

Para realizar correctamente el ordenamiento del Product Backlog en Scrum, es fundamental seguir una secuencia estructurada que tenga en cuenta varios factores y criterios. Aquí te presento una secuencia de pasos recomendada:

1. Definir el Contexto y Objetivos del Producto

• Antes de ordenar, asegúrate de tener claros los objetivos del producto, la visión y la estrategia general. Esto te ayudará a tomar decisiones alineadas con el valor esperado del producto.

2. Identificar los Criterios de Ordenamiento

• Define los criterios que usarás para ordenar el backlog. Estos pueden incluir:
  • Valor de negocio: ¿Qué tanto contribuye el ítem al valor del producto?
  • Riesgo y complejidad: ¿Cuáles son los riesgos asociados al ítem? ¿Es un ítem técnicamente complejo?
  • Dependencias: ¿Existen dependencias con otros ítems o equipos?
  • Urgencia o necesidad regulatoria: ¿Existen fechas límite o requerimientos regulatorios?

3. Evaluar y Categorizar los Ítems del Backlog

• Revisa cada ítem del backlog y asígnale una categoría basada en los criterios definidos. Por ejemplo, puedes clasificar los ítems como:
  • Bugs: Problemas críticos que afectan la experiencia del usuario.
  • Deuda técnica: Elementos que necesitan ser resueltos para mejorar la calidad del código.
  • Funcionalidades nuevas: Mejoras o nuevas capacidades del producto.
  • Requerimientos regulatorios: Obligaciones legales o normativas.

4. Considerar las Dependencias

• Asegúrate de que los ítems con dependencias necesarias se ordenen de manera que no bloqueen el trabajo posterior. Esto es crucial para mantener el flujo de trabajo.

5. Asignar una Puntuación de Valor

• Usa técnicas como el valor ponderado (Weighted Shortest Job First - WSJF o la relacion Valor/Duración) para asignar un puntaje a cada ítem basado en su valor relativo, el esfuerzo requerido y el impacto en la entrega del producto.

6. Organizar el Backlog en Función del Contexto

• Con los criterios y puntajes, organiza el backlog considerando el contexto actual del proyecto. Esto puede implicar mover hacia arriba ciertos ítems que, aunque no tienen el mayor valor, desbloquean otros ítems críticos.

7. Revisar y Ajustar Regularmente

• El Product Backlog no es estático. Revisa y ajusta el orden regularmente en las reuniones de refinamiento del backlog, o cada vez que cambien las condiciones del proyecto o del mercado.

8. Comunicar el Ordenamiento al Equipo

• Es fundamental que el equipo de desarrollo y los stakeholders entiendan el orden del backlog y las razones detrás de él. Esto mejora la transparencia y alinea a todos en cuanto a las prioridades del producto.

9. Validar con el Equipo

• Antes de finalizar, valida el orden del backlog con el equipo de desarrollo. Pueden surgir consideraciones técnicas o de implementación que afecten la viabilidad del orden propuesto.

10. Monitorear el Impacto y Adaptar

• Observa cómo el ordenamiento del backlog afecta el desempeño del equipo y la entrega de valor. Ajusta el orden si es necesario para asegurar que se maximiza el valor entregado al cliente.

Este enfoque permite que el Product Owner tome decisiones informadas y estratégicas al ordenar el backlog, asegurando que el equipo trabaje en lo que realmente aporta valor y minimizando el desperdicio de tiempo y recursos.

Conclusiones

1. No Todo Puede Ser Priorizado Igual: Un solo criterio de priorización no es suficiente, existen muchos criterios. Es necesario un enfoque integral para gestionar el backlog de manera efectiva.
2. El Product Owner Debe Comprender el Contexto: Ordenar el backlog implica entender el entorno, las necesidades del negocio, las dependencias y riesgos de cada ítem.
3. Evangelización sobre Ordenamiento: Tanto el equipo Scrum como la organización deben entender esta diferencia. El Scrum Master juega un papel crucial en facilitar esta comprensión hacia todos los que están impactados con el ordenamiento del Product Backlog.
4. Aplicabilidad a Portafolios Empresariales: A nivel de portafolio, no todos los proyectos se gestionan con los mismos criterios. Algunos son estratégicos, otros operativos; ordenar significa encontrar un equilibrio que maximice el valor global (esto será material para otro artículo).

Cerrando, ordenar un backlog no es una tarea sencilla, pero es crucial para que el equipo pueda entregar el máximo valor posible. No se trata solo de qué hacer primero, sino de entender por qué y cómo hacerlo en el contexto adecuado.

Saludos ágiles,

Jorge Abad.

4 Frases para incrementar nuestra inteligencia emocional

El liderazgo no es solo mostrar la dirección del cambio, sino tener u na conexión genuina y sincera con las personas, para esto la inteligencia emocional y la empatía juegan un rol importante.

En un artículo publicado recientemente en el períodico El Tiempo de Colombia titulado: "Si usa una de estas 4 frases tiene más inteligencia emocional que la mayoría", presentaba que Matt Abrahams, profesor de la Universidad de Stanford y experto en comunicación, compartió cuáles son las frases que suelen caracterizar a una persona con mayor inteligencia emocional:

• Lo que te oigo decir es...
• Déjame hacer esto bien.
• ¿Cómo te hizo sentir eso?
• ¿Qué pudo haberte llevado a eso?

Las anteriores preguntas "dejan ver que hay una preocupación hacia los sentimientos personales, pero también hacia los de los otros."


Saludos ágiles,


Jorge Abad.

#RespuestasÁgiles: ¿Cuál es el futuro del Rol de #ScrumMaster y #AgileCoach?

---

Podcast: ¿Generan o no valor? He ahí el dilema de algunos Scrum Masters y Agile Coaches

Diatriba: ¿Generan o no valor? He ahí el dilema de algunos Scrum Masters y Agile Coaches

Hola a todos, 

La agilidad se ha convertido en un elemento fundamental en el mundo empresarial, y los Scrum Masters y Coaches desempeñan un papel crucial en su adopción y éxito. Sin embargo, existe un dilema importante que enfrentan estos profesionales en su búsqueda de transformar equipos y organizaciones hacia la agilidad: ¿Realmente están generando valor? En este artículo, exploraremos en detalle este dilema y analizaremos cómo la entrega temprana y continua de software con valor (primer principio del manifiesto ágil (1)) se convierte en el principio fundamental que debe guiar sus acciones.

El Dilema de la Entrega de Valor

En el contexto empresarial actual, las organizaciones buscan constantemente formas de innovar, mejorar la satisfacción del cliente, reducir riesgos y aumentar sus ingresos. Aquí es donde entran en juego los Scrum Masters y Coaches, cuyo papel es vital para impulsar la agilidad y lograr estos objetivos. Sin embargo, surge una pregunta fundamental: ¿están realmente generando valor en sus equipos y organizaciones? Mucho se dedican a acompañar a sus equipos y a su ecosistema, verificando si hacen o no bien las prácticas ágiles: el daily, la retrospectiva, el Scrum of Scrums; pero olvidan el responder a la necesidad del contexto empresaríal, la razón clave por la cual fueron contratados y fue para cumplir a cabalidad el manifiesto ágil con sus principios en los cuales la palabra software en total aparece cuatro veces:

• Valor 2: Software funcionando sobre documentación extensiva (2).
• Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor (1).
• Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible (1).
• Principio 7: El software funcionando es la medida principal de progreso (1).

Y me pregunto ¿Cuándo rayos olvidamos lo esencial?¿Que parte de todo lo anteior no ha sido clara?  Mi afirmación, como lo digo en muchos espacios, no incluye negación, amo los equipos que se divierten, pero amo más los equipos que se divierten y entregan software valor, los primeros son candidatos a ser reemplazados, los segundos son indispensables.

La Agilidad más allá de las Metodologías

La agilidad no se trata simplemente de adoptar una metodología o marco de trabajo ágil, como Scrum, Kanban. LeSS, DAD  o SAFe. Si bien estos marcos proporcionan un conjunto de prácticas valiosas, el objetivo principal de la agilidad va más allá. Se trata de proporcionar resultados tangibles que es la entrega de software con calidad y uno de los problemas más comunes es la percepción errónea de que el trabajo de Scrum Masters y Coaches se limita a la facilitación de reuniones, la creación de diapositivas, creación de "awareness" (lo decimos en inglés por que suena cool). Si bien estas actividades son importantes, no deberían ser el enfoque principal. La verdadera esencia de su papel es garantizar que los equipos estén entregando software, software de calidad y de valor.

No en vano, en mi organización, amigos empresarios y líderes de transformación me preguntan:

¿Jorge, no tenes o conoces a un(a) Scrum Master / Agile Caoch, bien bueno(a), orientado al delivery que me recomendés?

La frecuencia con la que me encuentro con esta situación es asombrosa (y suena ilógico que explícitamente lo digan ¿No creen? Pues ese es uno de los objetivos claves del rol). Los individuos que no priorizan el "delivery", lamentablemente, suelen no ser de gran utilidad. Sin un software funcional, de calidad y valioso, se convierten en un lastre costoso que impide que un equipo igualmente costoso logre un impacto significativo. Además, estos líderes bien intencionados tienden a centrarse en la organización de eventos que, desafortunadamente, no conducen a mejoras en el desempeño, ni a nivel de equipo ni organizacional.

El Rol de los Scrum Masters y Agile Coaches en la Entrega de Valor

Los Scrum Masters tienen la responsabilidad de transformar a los equipos en equipos de alto desempeño, ese es su principal entregable. Esto significa mucho más que solo estar presente en las retrospectivas o crear visualizaciones de burndown. Implica medir y demostrar cómo el equipo está generando valor, reduciendo riesgos y mejorando el rendimiento de la organización en su conjunto.

Los Agile Coaches, por otro lado, deben crear un ecosistema de alto rendimiento en toda la organización. Esto no se trata solo de conversaciones con los equipos. Implica medir el impacto de las prácticas ágiles en la organización y dejar un legado de mejora continua. 

La agilidad debe generar dinero

es un imperativo inaplazable, donde el concepto de dinero o 'valor' abarca desde la mejora en el tiempo de comercialización (time to market), la reducción de costos y el aumento de ingresos hasta la satisfacción del cliente y la reducción de quejas (con la aspiración de que estas últimas desaparezcan), junto con una mayor participación en el mercado. Todo esto, se traduce en la creación de valor sólido para la organización, sin dejar de lado la importancia de cuidar a las personas, tanto a los equipos internos como a los externos, a todas las partes interesadas y, por supuesto, a los propios clientes.

Asumir esta responsabilidad se convierte en un deber fundamental, algo que destaco constantemente a quienes tengo el privilegio de acompañar. Quiero invitarte, mientras lees este artículo, a que reflexiones sobre tu papel. No puedes simplemente esperar que las cosas sucedan; eres un agente de cambio y tu función principal es dejar a los equipos y a su ecosistema en un estado mucho mejor del que encontraste. La única manera de saberlo es a través de la medición, ya que como bien se dice,

"Lo que no se mide no se mejora"

- atribuida a Lord Kelvin, otros la atribuyen  Peter Drucker.

La Importancia de las Métricas en la Agilidad

La clave para superar este dilema radica en el uso adecuado de las métricas. Las métricas ágiles deben ir más allá de la simple medición de la velocidad de entrega. Deben abordar aspectos como la satisfacción del cliente, la calidad del software, la reducción de la deuda técnica y la mejora continua.

Las métricas efectivas permiten a los Scrum Masters y Agile Coaches demostrar cómo su trabajo está contribuyendo al éxito de la organización. Esto no solo proporciona una base para la toma de decisiones informadas, sino que también ayuda a ganar la confianza de las partes interesadas y líderes empresariales.

Algunas métricas sugeridas para Scrum Masters pueden ser:

• Say/Do del equipo (mide lo que se entrega versus lo que se comprometió, ejemplo, en el planning el equipo se compromete con 20 puntos y entrega 16, el Say/Do= 80%)
• Deuda técnica
• NPS (net promote score) del equipo
• NPS del Product Owner
• % de alineación o logro de los objetivos organizacionales que son impactados por el equipo (OKRs o KPIs si es del caso).

Algunas métricas sugeridas para Agile Coaches pueden ser:

• Say/Do del ecosistema de equipos acompañado
• Deuda técnica promedio del ecosistema de equipos acompañado
• NPS del ecosistema de equipos acompañado
• NPS de los Product Owners o Product Managers acompañados
• Impacto en la métricas de negocio del ecosistema de equipos (OKRs o KPIs según el caso)

El Compromiso con el Cambio y la Mejora Continua

Para resolver el dilema de la entrega de valor en la agilidad, los Scrum Masters y Agile Coaches deben comprometerse a hacer una diferencia real. Esto implica no solo seguir un marco ágil, sino centrarse en generar un impacto significativo en la organización. Deben trabajar incansablemente para mejorar la satisfacción del cliente, reducir riesgos, aumentar los ingresos y mantener a los equipos en la búsqueda constante de la excelencia, en lograr ese primer principio para satisfacer al cliente: la entrega tempra y continua de software de calidad y de valor.

Conclusión

La agilidad no se trata solo de seguir procesos y prácticas, sino de crear un cambio significativo en las organizaciones. Los Scrum Masters y Coaches juegan un papel vital en este viaje, y su éxito depende de su capacidad para entregar software de valor y demostrar su impacto. Al abrazar esta responsabilidad y medir constantemente su contribución, pueden ayudar a sus equipos y organizaciones a alcanzar el alto desempeño y la verdadera agilidad, de lo contrario son reemplazables o inútiles para lo que fueron contratados.

En última instancia, la agilidad se trata de generar impacto, y los Scrum Masters y Agile Coaches tienen el poder de hacerlo. La entrega temprana y continua de software con valor es el núcleo de su misión, y al abrazar este principio, pueden llevar a sus equipos y organizaciones hacia un futuro más ágil y exitoso.

Saludos Ágiles, 

Jorge Abad.

Referencias

1. Principios del Manifiesto Ágil.
2. Manifiesto Ágil.
3. Recomiendo ver el vide asociado a este artículo: #RespuestasAgiles ¿Generan o no valor? He ahí el dilema con algunos #AgileCoaches y #ScrumMasters

Cómo TCS Latam logró mejorar su desempeño por medio de su métrica AgilityDebt (TM)

 Si eres #AgileCoach o eres parte de un #CoE de #Agilidad te recomiendo ampliamente este artículo.

En este se habla como Tata Consultancy Services mejora su desempeño empleando el índice AgilityDebt (tm), y como se ha conducido la mejora en Tata Consultancy Services LATAM y aunque he dado puntadas en dos posts:

• Video: Moviendo TCS (500.000 personas) a la Agilidad
• Cómo Lograr el Cambio Lean-Agile en Grandes Corporaciones

El nivel de detalle compartido por Roberto Moraga Diaz da una visión completa que puede ayudar a las organizaciones a mejorar de forma significativa su desempeño.

https://www.linkedin.com/feed/update/urn:li:activity:7057039282464534528/

El litmus test de la agilidad: Cómo identificar rápidamente si un equipo o muchos son ágiles o no

Hola a todos

La agilidad es un término muy utilizado en la industria del software, y se refiere a la capacidad de los equipos de responder a los cambios de manera rápida y efectiva. Un equipo ágil es aquel que es capaz de adaptarse a las necesidades cambiantes del negocio y del mercado, entregando software de calidad de forma constante y mejorando continuamente.

Pero ¿Cómo saber si un equipo o muchos equipos (que trabajan con un mismo Product Backlog) son ágiles o no, de una forma rápida y sencilla?  A continuación, te comparto esta evaluación rápida de agilidad, Esta evaluación consta de cuatro preguntas que te permitirán saber rápidamente si un equipo o una tribu es ágil o no:

1. ¿Están entregando software funcionando, probado y de valor al menos una vez al mes?
2. ¿Está el equipo entregando lo que el negocio más necesita?
3. ¿Está el equipo mejorando al menos una vez al mes?
4. ¿Tiene el equipo bienestar? ¿Está el equipo bien y se están divirtiendo?

Estas cuatro preguntas las he llamado "Litmus Test de la Agilidad" o el "LitmusTestAgile", haciendo referencia al Litmus Test que se hace para determinar rápidamente si una solución es básica o ácida haciendo uso del papel tornasol (recuerdos que quedan del colegio).

Pero volviendo.

Si puedes responder "Sí" a estas cuatro preguntas, el equipo o todos los equipos que están trabajando con el mismo Product Backlog, entonces es muy probable que tengas un equipo o una tribu ágil, que asu manera, tal vez usando un marco de trabajo o no, están logrando poner en práctica la agilidad en su más pura expresión. Estas preguntas están abstraídas  de los cuatro valores y los doce principios del Manifiesto Ágil, por lo que si las cumples, estás cumpliendo también con los principios de la agilidad. Además, su fuente más importante es el Checklist de Scrum de Henrik Kniberg que tradujo Lucho Salazar en su famosísimo blog, bajo el título "Lista de Chequeo Scrum".

¿Están entregando software funcionando, probado y de valor al menos una vez al mes?

Esta pregunta busca identificar si el equipo debe ser capaz de entregar software que el cliente pueda utilizar, y que tenga un impacto positivo en el negocio. Además, es importante que se entregue con frecuencia, al menos una vez al mes, con preferencia a tiempos más cortos.

"Si un equipo o una tribu es capaz de entregar software funcionando, probado y de valor al menos una vez al mes, sin dudar es ágil y está avanzando en la dirección correcta."

¿Está el equipo entregando lo que el negocio más necesita?

Esta segunda pregunta está relacionada con la alineación del equipo con las necesidades del negocio. El equipo debe estar entregando lo que el negocio más necesita, y esto se debe validar constantemente. No importa cuantos stakeholders tiene, pero si logra entregar lo que el negocio pide, ese equipo está generando impacto hacia el mercado.

¿Está el equipo mejorando al menos una vez al mes?

Esta pregunta se refiere a la mejora continua del equipo. Es importante que el equipo esté mejorando continuamente, tanto en sus procesos, interaciones como en su capacidad técnica. Si mejora una vez al mes, estará mejorando al año 12 veces, pero si mejora en ciclos de dos semanas, serán en consecuencia 24 mejoras, mucho mejor ¿No cierto? Lo cierto, es que la mejora debe ser un ejercicio constante de un equipo ágil que no debe dar espera a que se llegue una fecha específica para hacerla.

"Lo cierto, es que la mejora debe ser un ejercicio constante de un equipo ágil que no debe dar espera a que se llegue una fecha específica para hacerla"

¿Tiene el equipo bienestar? ¿Está el equipo bien y se están divirtiendo?

Esta cuarta pregunta se centra en el bienestar del equipo. El equipo debe estar bien y disfrutando su trabajo. Si el equipo está entregando software funcional, probado y de valor, está alineado con las necesidades del negocio y está mejorando continuamente, es muy probable que esté bien y disfrutando su trabajo, pero, aun así, es necesario preguntar, es requerido validar si hay seguridad sicológica y un ambiente en el que surja tanto la creatividad como el alcanzar retos juntos, en donde no se esté maltratando o desgastando a las personas, simplemente, algo así no es sostenible.

Cerrando

Si quieres saber si tu equipo o tribu que hace software es ágil o no, puedes utilizar el Litmus Test de la Agilidad. Si respondes "sí" a las cuatro preguntas, entonces es muy probable que tengas un equipo o tribu ágil que está entregando software funcional, probado y de valor, está alineado con las necesidades del negocio, está mejorando continuamente y está disfrutando su trabajo. Adicionalmente, puedes llevar estas preguntas a las áreas de negocio cambiando la palabra software por los entregables de valor que allí se generan, de forma que rápidamente sabrás si esa área o equipo requiere ayuda o está generando impacto esperado para la organización.

Saludos Ágiles,

Jorge Abad.

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

 

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

Hola a todos,

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

¡Remando en arequipe! (2)

 o 

¡Remando en dulce de leche! (2)

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

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

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

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

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

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

Cómo entonces generar el cambio

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

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

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

Saludos ágiles,

Jorge Abad.

Referencias 

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

Cómo evaluar a un Líder de Transformación Ágil y Un Agile Coach

Hola a todos

Hace poco un amigo me preguntó ¿Qué métricas usaría evaluar a un Líder de Transformación Ágil? o ¿Cómo le evaluaría? A continuación, les comparto mi respuesta.

En mi criterio se deben evaluar tres dimensiones:

• Mejora de la agilidad de los equipos a cargo
• Madurez ágil.: ¿Qué tanto han madurado los equipos ágiles a cargo respecto al último periodo? Para esta métrica se requiere un modelo de madurez instaurado en la organización para evaluación de la agilidad de equipos ágiles, y como se puede observar la idea es que es líder mejore la agilidad de esos equipos, es decir, su madurez en términos de uso de principios, marcos ágiles, prácticas ágiles de desarrollo y DevOps.
• Número de releases: Incremento del número de releases respecto al último periodo. Esta métrica tiene como propósito determinar si el líder ha incrementado la cantidad de salidas a producción, lo que implica, que hay  uso de conceptos de Mínimo Producto Viable, y salidas a producción incrementales. Otra métrica posible a adicionar de este mismo tipo sobre la cual el líder tiene influencia directa es el Time to Market, medido desde que nace la inciativa hasta el primer release.
• Resultados de Negocio
• Satisfacción del cliente: ¿Qué tanto ha mejorado la satisfacción del cliente desde el último periodo?, El propósito de esta métrica es hacer al líder responsable de lograr que se mueva esta importante métrica de negocio, de forma que se haga cargo de que los releases a producción sean de valor y se esté evaluando constantemente la satisfacción del cliente, ya sea con métricas directas como el NPS o encuestas, o indirectas derivadas del uso del sistema, tales como recomendación de las soluciones hacia otros usuarios, incremento de intalaciones, aumento de uso de las plataformas, tiempo de uso la solución más altos, entre otras.
• Agente de Cambio
• Calidad de sus interacciones: Evaluación 360 de las personas con las que interactúa. El propósito de esta métrica es identificar cómo es la relación con su entorno y cómo ejerce su liderazgo de agente de cambio. 

Notas Finales

• El peso de cada medida lo decidirá el contexto, yo recomiendo el mismo para las tres dimensiones.
• Este tipo de evaluaciones también servirían para un Agile Coach
• Estas dimensiones son las que usamos para evaluar Agile Coaches y Líderes de Transformación en mi entorno y nos han dado buenos resultados, es decir, hablo de ellas con conocimiento de causa.

Bienvenidos sus comentarios.

Saludos ágiles

Jorge Abad

Algunas ideas sobre cultura

La cultura de una organización se conoce por la forma en que trata a sus proveedores.

Los valores y los principios son el mantra que se debe repetir a todo nivel dentro de la organización.

Cuando los procesos no están legislando sobre un determinado aspecto, los principios y valores lo harán.

Los líderes deben reforzar constantemente el conocimiento, difusión, y uso de los valores y principios de la organización.

Las organizaciones que maltratan, discriminan, o segregan a sus proveedores poseen culturas tóxicas.

Para elevar el estándar cultural de una organización el líder debe empoderar a los demás para exigir el cumplimiento de los principios y valores.

La cultura dentro de una organización o grupo de trabajo es la promovida y exhibida por los líderes.

La mejor forma de liderar una cultura es hacerlo con el ejemplo.

El líder debe incentivar y promover todo comportamiento que vaya en pro de la cultura, principios y valores de la organizaición.

El líder debe desestimular todo comportamiento que vaya en contra de la cultura, principios y valores de la organización.

Los procesos reales, es decir, como realmente la organización interactúa para generar valor, son el fiel reflejo de la cultura, principios y valores que tiene la organización, sin importar si estos han sido o no declarados, o si fueron o no documentados de forma correcta o incorrecta. La forma como interactuamos gobierna sobre lo que esta escrito o declarado. .

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

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

Los líderes promueven la cultura dentro de una organización, ya sea de forma consciente o inconsciente. Corolario 1: Las personas a cargo del líder generalmente copiarán los comportamientos del líder independientemente de lo que diga o hace, pues imitar su comportamiento los "llevará a ser como él/ella y a tener su mismo poder", similar como los hijos copian a sus padres (consciente o incosncientemente).

Referencias

1. Las referencias de este post se basan en muchas experiencias, lecturas y conversaciones, no es mi intención no dar crédito, es más el compartir comportamientos observados para que todos hagamos uso de ellos. Si alguien conoce la cita explícita, no dude en compartirmela, con gusto actualizaré el artículo.
2. 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

Dos razones del cambio

“We generally change ourselves for one of two reasons: inspiration or desperation.”

― Jim Rohn

"Generalmente cambiamos por una de estas dos razones: inspiración o desesperación"

― Jim Rohn

 ----

#DeColección

“We generally change ourselves for one of two reasons: inspiration or desperation.”
― Jim Rohn

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

Tu Equipo Ágil no comienza siendo Ágil. Unas poderosas tres razones.

Muchas veces pensamos que por el hecho de poner a personas juntas, pedirles que le pongan un nombre al equipo, asignarles un backlog, automáticamente se convierten en un equipo (1), y no solo eso, creemos que al primer sprint el equipo va tener la velocidad (ej: 50 puntos por sprint)  que planearon - http://www.lecciones-aprendidas.info/2017/12/un-cuarto-metodo-para-estimar-la-velocidad.html -  y que con esa velocidad podremos terminar en una fecha determinada el primer release ( ej: si el primer release se estima en 350 puntos, lo tendremos en 7 sprints).

La verdad, esto es lejano de la realidad, los equipos toman un tiempo en crearse y madurarse - tal vez  8 sprints, más o menos, y esto dependerá de muchos factores - y alcanzar un buen desempeño, en este post compartiré las razones por las cuales esto se presenta y algunas recomendaciones para ayudarte en este proceso.

1. La Curva de Tuckman

Este modelo muestra las diferentes etapas por las cuales pasa un equipo (2),  ella muestra el esfuerzo que toma lograr el mismo estado de desempeño inicial en el cual se formo el equipo. Solo imaginémonos haciendo parte de un equipo de fútbol, rugby, baloncesto, voleibol, musical - en fin cualquier equipo - y el esfuerzo que nos toma acoplarnos, las veces que debemos jugar / tocar  juntos para sentirnos cómodos los unos con los otros.

2. La Curva del Cambio o Curva "J" (fuentes: Elisabeth Kübler-Ross, Albretch, David Viney y otros)

Ver fuente (3)

Ver fuente (4)

Ver fuente (5) - Un excelente post- 

Las causas por las cuales se transita esta curva son muchas, pues cuando llegamos a un nuevo proyecto se vienen cambios como:

• El nuevo proyecto (obviamente)
• Conocer una nueva tecnolología
• Conocer a mis compañeros
• Conocerme interactuando con mis compañeros
• Conocer un nuevo negocio
• Conocer una nueva metodología
• Conocer una nueva empresa y sus reglas
• Conocer los nuevos sistemas
• Conocer la forma de interactuar en esa organización.

Lo que nos demandará inevitablemente avanzar por esta "J" del cambio y desempeño.

y por último (aunque no sé si sea la última causa, puede que existan más)

3. La Zona de Reducción de Riesgos en TI  de Cockburn

Esta curva ya la habíamos discutido en otro post anterior - ¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)? clic aquí - y observábamos que cuando un equipo supera la zona de adquisición de conocimiento la generación de valor fluye a ritmo constante, por lo tanto, aunque los equipos conozcan:

• la metodología, 
• el lenguaje de programación 
• y la tecnología que están manejando, 

existe el conocimiento que no poseen y que directamente implica un esfuerzo como:

• nuevas reglas de negocio
• los sistemas con los que interactuarán
• la interacción para la empresa en la que estan comenzando a trabajar (suponiendo que son proveedores, aun si son internos pero todos son nuevos)

Y es en consecuencia, natural que exista una fricción inicial para alcanzar rendimiento y puedan jugar bien como equipo scrum o como un equipo ágil.

Ahora, habrá mucha más fricción si:

• la tecnología es nueva
• es primera vez que trabajan como equipo
• es primera vez que interactúan usando la metodología o framework de trabajo

Unas Cuantas Conclusiones

1. Es inevitable pasar por la zona de baja productividad
2. En mi experiencia, he observado que los equipos logran llegar a la Fase Normalización de Tuckman aproximadamente  entre 4 y 8 sprints - sprints de duración de dos semanas-, antes no. Si alguien tiene mejores datos al respecto agradecería mucho los compartiera. 
3. El periodo de 4 a 8 sprints podría ser más largo pero he observado que los ciclos continuos de feedback aceleran el proceso de maduración, permitiendo avanzar rápidamente en la curva J - ver este post donde afirmo que Scrum es un modelo de Auto-Coaching de equipos http://www.lecciones-aprendidas.info/2018/08/scrum-como-modelo-de-auto-coaching.html -.
4. Se requiere de un buen liderazgo situacional del Scrum Master para que este periodo sea cubierto de forma exitosa. - ver este post Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización http://www.lecciones-aprendidas.info/2015/11/como-ensenando-montar-en-bicicleta-como.html -
5. La verdadera velocidad o capacidad del equipo debe considerarse después del ciclo de estabilización, o sea, después del quinto o noveno sprint según el caso.
6. Recordemos que el Product Owner,  el Scrum Master y el Equipo de Desarrollo, son un equipo por lo tanto, todos están padeciendo los efectos de este inicio y acople.
7. Luego de estabilizada la velocidad o capacidad del equipo, la forma de incrementarla poco a poco es:
• promoviendo la excelencia técnica
• no escribiendo código basura, apestoso o "crappy code"
• removiendo la deuda técnica y haciendo refactors estratégicos
• aplicando las prácticas ágiles de desarrollo (pair programming, tdd, propiedad colectiva del código, etc)
• implementando las mejoras identificadas en las retrospectivas
• tener retrospectivas exitosas que le permitan al equipo avanzar en la dirección correcta - ver post http://www.lecciones-aprendidas.info/2017/02/scrum-master-como-continuar-la-mejora.html
• trabajar la felicidad del equipo

Cerrando, Qué recomiendo

1. No es una buena estrategia estar armando y desarmando equipos, se pierden estos procesos de acople, un principio importante a aplicar llevarle proyectos a los equipos en vez de armar equipos para los proyectos, es muchísimo más productivo para todos.
2. Recomiendo que al menos la mitad más uno de los integrantes del equipo sean entre Semi-senior y senior, esto acelera los procesos de formación de equipo y reduce considerablemente la creación de código basura debido a inexperiencia de los Juniors, pues los desarrolladores maduros le hacen mentoring a los nuevos - esto es de bastante importancia en equipos que desarrollan software - 
3. Hacer consciente a las organizaciones que comienzan con scrum, o con cualquier marco ágil,  que sus equipos agiles no van a ser "super- ágiles" y "super productivos" por el simple echo de que los pongamos juntos, con un tablero lleno de post-it, Jira u otro software instalado, un Product Owner y un Scrum Master,  es cierto van a ser mejores que en cascada o tradicional, pero es un hecho las primeras velocidades son lentas, y se requiere de acompañamiento incrementarlas.
4. Se recomienda hacer las proyecciones de cuando se va a entregar el producto luego de la fase de estabilización, antes no tiene sentido hacer proyección alguna, 
5. Liderazgo situacional es clave en este tipo de procesos. Sugiero se revise esta colección de post Tips para Comenzar con un Equipo Scrum - http://www.lecciones-aprendidas.info/search/label/comenzando%20con%20scrum proporciona herramientas útiles en el proceso de maduración y estabilización de tu equipo.

Hasta acá este compartir. Bienvenido el feedback.

Saludos Ágiles

Jorge Abad.

Notas, Comentarios, Observaciones y Referencias

1. Les recomiendo este artículo de Martín Alaimo - http://www.martinalaimo.com/es/blog/hacia-un-equipo-real - y la serie de "Hacia un Equipos Real" - http://www.martinalaimo.com/es/blog/tag/equipos-reales-.
2. Explicación de la curva de Tuckman en este post:  Equipos Estables por sobre Pool de Recursos - http://www.martinalaimo.com/es/blog/equipos-estables
3. Curva de Cambio - http://activaconocimiento.es/curva-de-cambio/
4. Las fases que vivimos ante un cambio -https://elpais.com/elpais/2013/12/16/laboratorio_de_felicidad/1387150998_138715.html
5. Falsos Positivos (agárrense que vienen curvas) https://wynwin.wordpress.com/2013/05/10/falsos-positivos/

Scrum Como Modelo de Auto-Coaching para los Equipos

Hola a todos

Hace unos días en una reunión de Ágiles Ecuador - en la que tuve la oportunidad de ser el facilitador de la Sesión de Migas de Pan(1)-, alguien sugería al cierre de la misma que para ser Scrum Master era necesario hacer un coach profesional como primer paso, y después de debatir un poco, decantábamos que no, que no era necesario, pues tanto un Scrum Master, un Agile Coach de Equipos o un Agile Coach Empresarial tienen más de mentor, de experto, de maestro, de líder, de entrenador de equipos, que alguien que a través de preguntas quiere acompañar a un individuo en su viaje de un estado a otro en su vida (y reconozco que este es un punto que aun no se termina de desarrollar en la comunidad ágil).

Pero también en esa discusión observábamos que un equipo que hace Scrum, tiene un ciclo de mejora continua que esta cuestionando constantemente tres ejes:

• La organización
• El equipo
• La persona que hace parte del equipo Scrum

Cíclicamente un equipo que hace Scrum, se enfrenta a su verdad - gústele o no - pues al principio en el Planning hacen una compromiso de lo que creen que van a construir y al final en la Review están mostrando lo que lograron a los Stakeholders y luego se van a la Retrospectiva con su resultado a filosofar que pueden hacer distinto para ser más exitosos el siguiente ciclo. Este ejercicio de:

• hacer una apuesta basados en su capacidad
• ver el resultado
• mostrar el resultado
• enfrentarse al feedback de sus stakeholders
• indagar por que se obtuvo el resultado
• proponer que mejorar internamente para ser más exitosos la próxima vez
• proponer que mejorar externamente para ser más exitosos la próxima vez

Termina cambiando a las personas, equipos y organizaciones.


Esta dinámica genera un circulo virtuoso transformador, pues:

• te va haciendo responsable de tus compromisos
• te hace revisar tus capacidades y buscar nuevas
• te invita a tener mejores interacciones con tus compañeros para tener éxito
• te invita a cuestionarte, cuestionar respetuosamente a los otros y cuestionar a la organización en la que estas inmerso

En definitiva, no te puedes quedar quieto ante un marco que cada semana, dos semanas o máximo un mes te muestra tu verdad tal cual es, o cambias, o cambias (así lo he visto funcionar cantidad de veces)

Scrum por sus ciclos de PHVA(2) continuos, termina cambiando al Equipo, al Scrum Master y al Product Owner, y al final de su viaje en la construcción del producto terminan siendo personas completamente distintas  y quienes hayan vivido este viaje sabrán darme la razón.

Para cerrar es importante aclarar que no solo Scrum puede darte este beneficio, cualquier modelo de trabajo que en ciclos cortos (de no más de un mes) nos esté enfrentando a la verdad y nos esté retando a salir de nuestra zona confort generará resultado similares.

Bonus Track

Ahora, cuando alguien me pregunta ¿que tiene que hacer para ser Agile Coach? lo invito a que comience este camino con corazón (3) siendo Scrum Master - que es el Agile Coach del equipo Scrum-, y enfrente allí sus verdades, junto con su equipo, y luego de al menos cuestionarse, cuestionar, y retar durante un buen tiempo determine hacia donde seguir avanzando.

Bueno, hasta acá esta corta reflexión y compartir.

Si tienes algún comentario bienvenido el feedback en la zona de comentarios

Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Actividad que le aprendí de mi gran amigo Carlos Gil
2. El ciclo Planear - Hacer - Verificar - Actuar, promovido por E. Deming

3."...Cualquier cosa es un camino entre cantidades de caminos. Por eso debes tener siempre presente que un camino es sólo un camino. Si sientes que no deberías seguirlo, no debes seguir en él bajo ninguna condición. Para tener esa claridad debes llevar una vida disciplinada.Sólo entonces sabrás que un camino es nada más un camino, y no hay afrenta, ni para ti ni para otros, en dejarlo si eso es lo que tu corazón te dice.

Pero tu decisión de seguir en el camino o de dejarlo debe estar libre de miedo y de ambición. (...) Mira cada camino de cerca y con intención. Pruébalo tantas veces como consideres necesario.

Luego hazte a ti mismo, y a ti solo, una pregunta: ¿Tiene corazón este camino?

Si tiene, el camino es bueno; si no, de nada sirve. Todos los caminos son lo mismo, no llevan a ninguna parte. Son caminos que van por el matorral. Ningún camino lleva a ninguna parte, pero uno tiene corazón y el otro no..." Uno hace gozoso el viaje; mientras lo sigas, eres uno con él. El otro te hará maldecir tu vida. Uno te hace fuerte; el otro te debilita."

El problema es que nadie se hace la pregunta, y cuando por fin se da cuenta de que ha tomado un camino sin corazón, el camino está ya a punto de matarlo.Un camino sin corazón nunca se puede disfrutar. Hay que trabajar duro tan sólo para tomarlo. En ese punto pocas personas pueden parar a pensar y dejar el camino...

En cambio, un camino con corazón es fácil: no te hace trabajar por tomarle gusto. Para mí existe solamente el viajar por caminos con corazón, en cualquier camino que pueda tener corazón. Por ahí viajo, y el único desafío que vale la pena es atravesarlo en toda su longitud. Y por ahí viajo, buscando, buscando, sin aliento". (“Las enseñanzas de Don Juan” de Carlos Castañeda.)