Apasionado
de la Agilidad
Consultor
& Facilitador

"Estoy convencido de que la Agilidad es un camino y no un fin. Me encanta ayudar a los equipos a co-crear las mejores condiciones para abrazar la Agilidad."

Próximos
Cursos

Ver más cursos
incompany

Cursos
In-company

Cualquiera de los cursos ofertados en el calendario, o bien, cursos específicos a la medida de tus necesidades. Podemos co-crear juntos una experiencia sublime de capacitación en un grupo privado, formado por personas de tu empresa.

Hey!, Más información sobre esto

Consultoría

La Agilidad es un camino y no un fin. Te acompaño en este viaje para co-crear las mejores condiciones en tu organización para abrazar la Agilidad.

  • Facilitación
    Facilitación

    Facilitar es “hacerlo fácil”.
    Facilito sesiones para guiar a personas y equipos hacia un resultado predeterminado ¿Cómo?, a través prácticas, dinámicas y herramientas diversas de gamificación que fomenten las conversaciones poderosas y liberen el potencial de las personas.
  • Mentoría & Coaching
    Mentoría & Coaching

    Enfocada en cuestiones directas sobre temas específicos. Es una opción adecuada si tienen alguna consulta puntual y se encuentran en la exploración de alternativas.
    Una manera de ayudar a desarrollar nuevos conocimientos y habilidades específicos ¿Cómo?, a través de compartir experiencia y guía, a la vez que se pone en práctica lo aprendido.
  • Consultoría
    Consultoría

    Les acompaño en el viaje de evolución ágil de tu organización: Partir de un estado inicial, co-crear las mejores condiciones de manera iterativa que potencialicen su capacidad de adaptarse al cambio y abrazar la Agilidad.
Hey!, Más información sobre esto

Testimonios

Algunos testimonios de personas con quienes he tenido el gran gusto de colaborar profesionalmente a lo largo de este mágico camino de la Agilidad:

  • “

    “Leonel consiguió resultados de cambio sorprendentes en la empresa con la mentoría de SCRUM. Es un profesional muy enfocado para trabajar en el aprendizaje de cada colaborador de nuestra organización. Tiene excelentes conocimientos en el marco de SCRUM, y gracias a él hemos podido llevar a cabo la implementación de varios proyectos de forma exitosa.”

    **Miguel Ángel Pedraza González** Dirección de Transformación Digital e Innovación en (Fintech-Retail)

    Miguel Ángel Pedraza González
    Dirección de Transformación Digital e Innovación en (Fintech-Retail)

  • “

    “Algo que cabe destacar entre todo lo positivo, es su método y el expertise con el cual se maneja en conjunto con la pasión y dinamismo que emplea al explicar los temas, por ende, puedo confirmar y reafirmar que ha sido una de las mejores experiencias de aprendizaje profesional que he tenido.”

    **Sascha Alexander Pedersbeck Franco** Scrum Master | PM

    Sascha Alexander Pedersbeck Franco
    Scrum Master | PM

  • “

    "Destaco la facilitación de nuestro trainer Leonel Zapien López, impecable.
    Me llevo la forma de explicar los conceptos y las dinámicas utilizadas que ayudan a entender los conceptos puestos en práctica."

    **Cristian Rodríguez** Agile Coach | SAFe Agilist | CSM | Transformación digital (España)

    Cristian Rodríguez
    Agile Coach | SAFe Agilist | CSM | Transformación digital
    (España)

Visita mi
Blog

Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado
Scrum
Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado

En Scrum, hablar de calidad del producto es hablar de la **Definición de Terminado**, la cuál es popularmente conocida como **DoD**, así a secas, DoD, un acrónimo debido a su nombre en inglés: **Definition of Done**. Esta Definición de Terminado es una descripción formal de lo que debe de cumplirse para que el producto que se está entregando cuente con las medidas de calidad requeridas. Es decir, lo que debe de cumplirse y validarse para asegurar que el producto que se está construyendo pueda ser puesto en producción, que lo pueda utilizar directamente usuario final, y que sea un producto de calidad (que no tenga fallas o bugs, que cumpla con los lineamientos de la organización, que el programa no “se rompa”, etcétera). No pretendo que este sea un artículo teórico, pero es necesario ver algo de teoría. Así que, partiendo de una “definición de libro”, veamos qué es la Definición de Terminado. De acuerdo con el Glosario de Scrum.org, la Definición de Terminado es: **“Un entendimiento compartido de las expectativas que el incremento debe cumplir para poder ser liberado a la producción.”** Aquí hay un par de ideas clave que es relevante enfatizar: • **“Entendimiento compartido”:** Esto significa que es co-creada por todo el equipo Scrum, que todos la comprenden y están de acuerdo con ella. Es decir, que no es algo que definen solo los desarrolladores como área técnica, sino que negocio, a través del Product Owner, debe de compartir este entendimiento. **• “Las expectativas que el incremento debe cumplir”:** En Scrum buscamos entregar un incremento de producto en cada sprint, esto es un incremento funcional que puede utilizar el usuario final a partir de ese momento en caso de ser requerido. Por eso, al definir en la DoD lo que el producto debe de cumplir, se crea una línea base en términos de calidad, ya que cualquier incremento de producto cumple siempre con la DoD, lo que quiere decir que hay un nivel de calidad “mínimo” establecido para todos los incrementos. **• “Para ser liberado a producción”:** Como mencionaba en el punto anterior, cada incremento de producto que se entrega debe de ser un incremento completamente funcional, que puede utilizar el usuario final, a partir de ese momento en caso de ser requerido. Al ser un entendimiento compartido, es claro y transparente para todo el equipo lo que “terminado” significa. No existe algo como “**casi-casi-terminado**”, está terminado o no lo está, por lo tanto, se puede entregar o no. Aquí me gustaría compartir 5.1 puntos muy chéveres para que puedas co-crear con tu equipo una poderosa Definición de Terminado. Estas son algunas ideas que han funcionado después de colaborar con diversos equipos. Veamos una por una: # 1. Co-creación: Ya que se trata de un entendimiento compartido por el equipo, es mucho más enriquecedor que sea co-creado por todo el equipo. Parecerá obvio este punto, pero una vez colaboré con un equipo en el cual el líder técnico definía la DoD porque era quien “tiene más experiencia”, y el resto del equipo, por ser juniors, solo se apegaba a lo definido. Nos tomó un tiempo el que pudiéramos avanzar todos juntos hacia la co-creación, pero ya llegando a ese nivel, el crecimiento del equipo y de la calidad del producto fue innegable. **La co-creación fomenta la diversidad de ideas y perspectivas, además de que ayuda s que las personas sientan que formaron parte en el proceso de crear algo nuevo, por lo que el sentido de pertenencia y compromiso aumenta.** # 2. Evolutiva: **La DoD debe de inspeccionarse y adaptarse regularmente**, no está escrita en piedra, y conforme el equipo va madurando, también la DoD debe de hacerlo. En un escenario real, ya que hablamos de responder al cambio, es necesario que la DoD se ajuste conforme el contexto técnico cambia, por ejemplo, ¿Se ha detectado un nuevo defecto o bug que no había ocurrido antes?, o ¿Qué tal cuando una actualización tecnológica hace necesaria una nueva validación? Si es el caso, agregar eso a la DoD. # 3. Visión del futuro: Ya que la DoD debe de ir madurando y evolucionado, es poderosísimo que el equipo tenga una visión compartida del estado futuro que pretende alcanzar, el nivel de calidad al cual el equipo aspira a llegar, quizá no este sprint ni el siguiente, pero sí como un estado hacia el cual el equipo va avanzando, paso a paso. Tal vez técnicamente el equipo aún no tiene los conocimientos y/o experiencia necesaria, pero está capacitándose, aprendiendo y eventualmente llegarán a ahí. # 4. No es una receta de cocina: La DoD no debe de ser prescriptiva. Indicar con puntos y comas lo que se debe de hacer como un procedimiento o receta, puede limitar la autogestión del equipo. Aquí no hay “mejores prácticas”, solo recordemos que no buscamos la documentación extensiva. Lo adecuado, como todo en la vida, es el balance. Documentar en la DoD lo justo y necesario para el equipo, no más, no menos. # 5. Transparencia real: La transparencia significa que la información debe de estar visible y disponible para las personas interesadas. En este caso, con transparencia “real” me refiero a que no solo visible y disponible es suficiente, sino que debe de ser entendible y comprensible para todos. Por ejemplo, ¿El Producto Owner sabe a qué se refiere que todo el código esté integrado?, la verdad es que no es necesario que sepa cómo hacerlo técnicamente, pero sí es importante que comprenda la esencia de lo que esto implica, y que comprenda su importancia, así como el impacto de no hacerlo. # 5.1 Y aquí un Bonus: ¡Diversión! Esto es fundamental. El cumplir con objetivos de calidad y código limpio no implica que debe de ser algo aburrido. Desde las dinámicas de facilitación para co-crear una DoD, inspeccionarla y adaptarla, hasta el aseguramiento de su cumplimiento, son oportunidades para que el equipo se divierta, se abra a lo lúdico, a nuevas ideas, fomentar las condiciones para que el equipo entre en estado de “Flow” y detone la creatividad. ¿Lo has experimentado con tu equipo? Que el equipo cuente con una DoD es esencial, si no cuenta con una,** el mejor momento para empezar a co-crearla fue el sprint pasado. El segundo mejor momento es hoy**. El hacer código limpio siempre evita problemas y dolores de cabeza, ayuda a no dejar trabajo pendiente para el final o “**escondido debajo de la alfombra**” que regresará al equipo después como problemas debido a mala calidad. El retrabajo es un tipo de desperdicio e impacta en la productividad. (image: icono-iceberg-05-large-to-web-site.webp) Para cerrar, me gustaría reforzar que el objetivo de Scrum es entregar cada sprint un incremento de producto que sea funcional, que cumpla con el objetivo del sprint y que, en última instancia, sea un paso adelante hacia el objetivo del producto… y la Definición de Terminado, es piedra angular en esto. Recordemos que** en el momento en que un elemento del Product Backlog cumple con la Definición de Terminado, nace un Incremento de producto.** Cuéntanos, ¿Qué te parecieron estos 5.1 puntos para una poderosa DoD? ¿Qué otro punto agregarías? Me encatará leerte y que conversemos :)

2 de junio de 2023
Tarjetas de colaboración: Fomentando conversaciones & armonía
Management 3.0
Tarjetas de colaboración: Fomentando conversaciones & armonía

En el trabajo, no somos solo empleados. También tenemos una vida, tenemos personalidad, preferencias personales, entre otras infinitas cosas. Al ser primeramente personas, nuestro estado de ánimo y desempeño en la oficina puede verse impactado por estas preferencias y rasgos personales. Conocernos unos a otros, en nuestros equipos y fuera de estos, ayuda a que las personas seamos identificados como eso, personas con una vida, y nos proporciona la sensación de que somos escuchados y que el mundo es empático con nosotros. Esto ayuda a fomentar un ambiente de trabajo que funciona mejor para todos. Por otro lado, al ignorar estos rasgos y necesidades personales, cuando sentimos que otros los ignoran constantemente, es un detonante potencial de conflictos e infelicidad en el lugar de trabajo. Y esto se ve reflejado en nuestro desempeño. **Management 3.0** llega con una propuesta: (link: https://management30.com/practice/personal-collab-cards/ text: Tarjetas Personales de Colaboración (Personal Collab Cards)), el cual puede verse como “un manual personal” con un resumen de aspectos relevantes para el trabajo, aspectos que debemos de conocer de cada persona con la que colaboramos. Las tarjetas de colaboración personal “estándar” que propone Management 3.0 contienen, entre otra información: • Zona horaria y disponibilidad para reuniones. • Canales de comunicación preferidos y formas de usarlos. • Funciones y temas de los que una persona es responsable o en los que desea ser incluida. • Intereses personales y cosas que pueden desmotivarlos • Partes interesadas con las que una persona trabaja regularmente, especialmente fuera del equipo. Poniendo un ejemplo concreto, **mi Tarjeta de Colaboración Personal **menciona cosas como: • Me llamo Leonel y gusta que me digan Leo. • Radico en Guadalajara, México, y mi zona horaria es Hora Central Estándar (CST), es decir UTC-6. • Si necesitan contactarme, mi forma predilecta es por mensaje de Whats App, así podemos ponernos de acuerdo fácilmente para una llamada o reunión (a menos que sea algo urgente). Para algo urgente no hay nada mejor que una llamada. • Si me envían un correo electrónico, entiendo que es algo que debo de atender, que es importante, pero asumo que no es algo urgente. • Mis horarios regulares para atender reuniones son de 09:00 a 18:00 horas, pero al colaborar con personas de distintos husos horarios, puedo tomar sin problema alguna reunión antes de mis 07:00 o después de mis 18:00 para alguna situación especial, solo necesitamos ponernos de acuerdo previamente. • Entre otros puntos… pero mejor, aquí comparto **mi Tarjeta Personal de Colaboración**: (image: management-3.0-personal-collab-card-leo-v01-a.webp) La **T-R-A-N-S-P-A-R-E-N-C-I-A** es la clave para a que, algo tan sencillo como las Tarjetas Personales de Colaboración, funcionen. Las tarjetas deben de estar disponibles y visibles para todas las personas con quienes colaboramos. Pegadas en un área común, si hablamos de un entorno presencial al 100%, o por ejemplo, en un tablero en Miro/Mural, en Trello o Confluence para contextos digitales o equipos distribuidos. **Como en toda herramienta visual, el punto no es el tablero o, en este caso, la Tarjeta de Colaboración, sino las conversaciones que se generan.** Y eso es lo poderoso de este tipo de herramientas. ## No hay que perder de vista el enfoque Ágil Recordemos el primer valor del (link: https://agilemanifesto.org/iso/es/manifesto.html text: Manifiesto Ágil): **“Individuos e interacciones sobre procesos y herramientas”**, esta herramienta, la Tarjeta de Colaboración, es solo eso… una herramienta. Lo enriquecedor y realmente poderoso es la conversación entre personas que esta tarjeta fomenta. **Procuremos pues, esas conversaciones agradables, con un café, un mate o como en mi caso, un té verde, donde seamos personas charlando antes que profesionales llegando a un acuerdo.** ## Tips para pasar al nivel Jedi en Colaboración Ya para comenzar a cerrar, aquí un par de puntos importante para que los tomes en cuenta cuando apliques esto en tu equipo: 1. Las Tarjetas de Colaboración Personal no sustituyen a otras prácticas o herramientas para que los integrantes de un equipo se conozcan mejor, por ejemplo, los (link: https://www.leonelzapien.com/blog/mapas-personales-conociendo-mejor-a-un-equipo text: Mapas Personales de Management 3.0). En este sentido, se complementan. Los Mapas Personales hablan más a detalle de las personas, las Tarjetas de Colaboración se pueden ver como un “resumen” o como un “manual” de lo esencial que necesitamos conocer sobre una persona con quien colaboramos. 2. Los campos que conforman las Tarjetas de Colaboración se pueden adaptar, no es obligatorio que sean de la manera en que se muestra en la plantilla de Management 3.0, depende del contexto de tu equipo y organización. Solo recuerda conservar la esencia:** ¡Mantenerlo simple!** 3. Las Tarjetas de Colaboración no están escritas en piedra, al igual que cualquier elemento o artefacto, son dinámicas. ¿Por qué? Porque nosotros como personas somos dinámicas, evolucionamos con el tiempo, cambian nuestro contexto, nuestras ideas… por lo tanto, recuerda revisar esto con tu equipo regularmente. 4. Estas tarjetas son poderosas para hacer más suave la llegada de nuevos integrantes al equipo (súper poderoso revisarlas durante el **onboarding**). ## Conclusión Para finalizar, no es mandatorio un tiempo o espacio específico para que un equipo cree sus tarjetas, pero si lo haces: **Si das al equipo un tiempo y espacio específico para que juntos revisen, actualicen y conversen sus Tarjetas de Colaboración, por ejemplo, durante un workshop o durante una sesión de integración de equipo o team building, la atmósfera hará el ejercicio aún más enriquecedor**. Se puede enlazar esta dinámica en equipo junto con los Mapas Personales, que anteriormente ya había mencionado, y estos pueden servir como base para desarrollar dinámicas más profundas para los equipos, como el (link: https://management30.com/practice/team-agreement-canvas/ text: Lienzo de Acuerdos de Equipo (Team Agreement Canvas))… pero esto es tema de otro artículo en este blog. Te invito a que experimentes aplicando las Tarjetas Personales de Colaboración con tu equipo, siempre inspeccionando y adaptando los resultados. Si te animas, nos compartes qué resultados obtuvieron. Cuéntanos… ¿Habías escuchado hablar antes de las Tarjetas Personales de Colaboración?, ¿Qué opinas sobre sobre esta herramienta? ¿Qué información sugieres agregar para utilizarla en tu equipo?

7 de mayo de 2023
El primer libro de Scrum del mundo
Scrum
El primer libro de Scrum del mundo

**“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum”**. Así es como introducen Ken Schwaber y Mike Beedle por primera vez el evento Daily Scrum en el libro **“Agile Software Development with Scrum”**, el cual fue el primer libro escrito en la historia de la humanidad sobre el marco de trabajo Scrum, por allá del año 2001. Hace unos días estuve releyendo el libro “Agile Software Development with Scrum” (Desarrollo de Software con Scrum), el cual es conocido en el mundo de la Agilidad como **“El libro negro de Scrum” **por su característica portada. Es una joya histórica por ser el primero de miles y miles y miles de libros que se han escrito sobre Scrum a lo largo y ancho del mundo. ¿Te ha pasado alguna vez que una película o canción que “te gustaba mil” cuando eras adolescente, cuando la ves o escuchas 10-15 años después… como que ya no “conecta” contigo? De igual manera, cada que leemos de nueva cuenta un libro lo vemos con una perspectiva distinta, puesto que somos una persona “diferente” de cuando lo leímos por primera vez (nuevas experiencias de vida nos han llevado a nuevos modelos mentales, nuevos paradigmas, nueva ideología, nuevas prioridades, etcétera). En este caso, después de releer “El libro negro de Scrum” no puede ser más cierto que lo veo desde una perspectiva distinta, no solo porque yo he evolucionado como persona… sino que **Scrum, como marco de trabajo, también ha evolucionado** (a verdaderos pasos agigantados) desde que lo presentaron al mundo oficialmente en 1995 sus co-creadores Jeff Sutherland y Ken Schwaber (quien es, por cierto, uno de los co-autores de este libro). Aquí te comparto varias ideas sobre Scrum tal como fueron concebidas originalmente, así como una comparativa con el enfoque actual. Lo interesante es que, si lo vemos con las gafas o lentes de hoy,** a 21 años de la publicación de este libro, muchas de sus ideas pueden considerarse como disfuncionales o incluso antipatrones**… Entonces, ¿está mal el libro? ¡Nada de eso!, solo recordemos que estamos en la “tierra del empirismo”, debemos de crear para enseguida inspeccionar y adaptar. Así que el hecho de que Scrum haya evolucionado de la manera que lo ha hecho (y lo seguirá haciendo), es una muestra clara del empirismo aplicado a su máximo potencial. ¡Poderosísimo! Sin más rollos, aquí van algunas de estas comparativa de ideas acerca del “Scrum del primer libro” y el enfoque actual: ## 1. El Daily Scrum es una junta de estatus… que solo debe de llevar ¡el Scrum Master! **1.1 **“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum” **1.2 **“El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum. El Scrum Master mantiene el Daily Scrum breve, hace cumplir las reglas asegurándose de que las personas hablen brevemente.” Si un Scrum Master llegara este 2023 al evento internacional Scrum Day y dijera que el evento Daily Scrum es una junta de estatus, una muchedumbre con antorchas y trinchetes lo acusaría de anti-Agilista. (image: muchedumbre-con-fuego-y-trinchetes.webp) Imagen de WikiSimpsons (https://simpsons.fandom.com/es/wiki/Turba_furiosa) Me sorprendió ver que al Daily Scrum se le concibió inicialmente como una junta de estatus. Todo esto ha evolucionado, actualmente el Daily (así se le conoce en el medio, Daily “a secas”) no es para entregar estatus, tiene como propósito generar transparencia, que en equipo se inspeccione el progreso hacia el Objetivo del Sprint y adaptar según sea necesario. Respecto a la segunda idea del libro,** “El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum”**, la evolución nos ha llevado a buscar el enfoque en la autogestión del equipo, es decir, que sean capaces de gestionarse sin necesidad de que un Scrum Master lo haga por ellos, por esto actualmente el Daily es un evento de los Desarrolladores para los Desarrolladores, ellos mismos inspeccionan su progreso hacia el ya mencionado Objetivo del Sprint, el Scrum Master no dirige la sesión, y, de hecho, puede no asistir y el evento no se detiene. ## 2. No es un Marco de Trabajo o Framework… es un ¿Método? En la introducción del libro, Mike Beedle (co-autor) menciona: “Tuve la buena fortuna de leer un mensaje de Jeff Sutherland y reconocer que era de hecho información muy importante. Él anunció que junto con Ken Schwaber estuvieron trabajando en **un método llamado Scrum**” Este punto me llamó mucho la atención, pues es añejo el debate sobre Scrum sobre si es un Framework y por qué no es una Metodología, pero antes de este libro nunca había visto que lo llamaran método. Para aquellos que ya conocen Scrum, disculpen que lo vuelva a mencionar, pero siempre partimos de aclarar que Scrum es un Marco de Trabajo o Framework, pues proporciona una serie de eventos y artefactos con los que se debe de trabajar, indicando 3 roles (Scrum Master, Product Owner y Desarrolladores), con esto se identifican los resultados que se desean obtener, pero no entra en ningún tipo de detalle sobre la manera en que esto debe de hacerse, es decir, deja “espacio abierto” a los propios equipos para sean ellos quienes decidan la mejor manera de hacer esto, el “cómo” hacerlo, en su contexto particular. Eso es un Framework, en tanto que un Método es un modo ordenado y sistemático de actuar o proceder para llegar a un resultado o fin determinado. Siendo muy simplistas podemos decir que es un procedimiento que se sigue para conseguir un objetivo. Un Framework deja más espacio a que las personas definan la manera de hacer las cosas, fomenta la experimentación y el empirismo, pues solo es una base para resolver un tipo de situaciones. ## 3. Enfoque en Proyectos y más Proyectos **3.1 **“Cada proyecto es diferente […] Diversas tácticas ayudan, pero sin Scrum esos proyectos fueron eventualmente abrumados por la complejidad inherente en proyectos de desarrollo de sistemas” **3.2 **“La gerencia debe de negociar de las cuatro variables [costo, fecha, funcionalidad y calidad] con los clientes “ Es oficial: **Scrum inició como un enfoque para gestionar proyectos de manera ágil**. Esto ha evolucionado en el último par de décadas y el enfoque actual no es hacer proyectos, sino productos. Esto quizá pueda sonar contradictorio, pues un producto puede ser el entregable que se genera al finalizar un proyecto, un resultado único. Esto es cierto, vivimos en un mundo de proyectos, pero la enorme diferencia es el enfoque… un proyecto se centra en entregar “algo” dentro del tiempo, costo y alcance definido, en tanto que, desde la perspectiva de producto, nos centramos en el impacto que este “algo” que entregamos produce para el usuario final. Buscamos construir productos que resuelvan algún problema del usuario/cliente, que hagan su vida más fácil. Un producto define su éxito en base al **V-A-L-O-R **que proporciona. ** P.D. #1** Personalmente siempre he creído que debemos de ir un paso más allá… un producto que resuelva un problema lo puede hacer cualquiera, **debemos enfocarnos en ¡crear productos que enamoren!** Estas son solo algunas de las ideas del “Scrum del primer libro” que plantean Schwaber y Beedle, la verdad es que hay mucha tela de la cual cortar. Es de esos temas profundos que dan para largas conversaciones acompañadas de un buen café, té, mate o la bebida de tu predilección (en mi caso, me inclino por el té verde). Por esto, y para no hacer un artículo tan extenso, en una próxima entrada de Blog continuaré con la segunda parte de “El primer libro de Scrum del mundo”. ¡Nos vemos en el capítulo 2! **P.D. #2** Mike Beedle (1962-2018), co-autor de este libro y firmante original del Manifiesto Ágil, fue mi primer maestro de Scrum. Con él tuve el enorme gusto de tomar mi primer curso de Scrum por allá del año 2014, una experiencia súper chévere! **Pero, por favor cuéntanos: ¿Conocías la esencia original de Scrum? ¿Qué opinas sobre la forma en que Scrum ha evolucionado? ¿Qué te pareció?**

26 de abril de 2023
Ver más artículos súper chéveres

Yo soy
Leonel :)

me

¡Hey!, ¿Qué tal?

Soy un espíritu libre y creativo: Amo viajar y las actividades al aire libre como trekking y acampar.
Soy fan de los comics, de Star Wars y me encanta la salsa cubana.

Mi pasión en la vida (además de la Agilidad) es la fotografía y la literatura.... todo esto es parte de mi ikigai.

Aquí te platico sobre mí y mi experiencia profesional