"Estoy convencido de que la Agilidad o Agilismo es un camino y no un fin. Me encanta ayudar a los equipos a cocrear las mejores condiciones para abrazar la Agilidad Organizacional."
Próximos
Cursos
![incompany](http://leonelzapien.com/media/pages/home/6d53975c51-1676345301/incompany.webp)
Cursos
In-company
Cualquiera de los cursos ofertados en el calendario, o bien, cursos específicos a la medida de tus necesidades. Podemos cocrear juntos una experiencia sublime de capacitación en un grupo privado, formado por personas de tu empresa.
Hey!, Más información sobre estoConsultoría
La Agilidad o Agilismo es un camino y no un fin. Te acompaño en este viaje para cocrear las mejores condiciones en tu organización para abrazar la Agilidad Organizacional.
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:
Visita mi
Blog
![Antipatrones de Scrum: Scrum but](http://leonelzapien.com/media/pages/blog/antipatrones-de-scrum-scrum-but/648d2a6466-1720462248/leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-cursos-consultor-guadalajara-mexico-blog-articulo.webp)
Scrum
Antipatrones de Scrum: Scrum but
Scrum no funciona. He escuchado esta frase muchas más veces de las que me gustaría admitir,
aunque la realidad es que, cuando profundizamos en cómo estos equipos llevan Scrum en su día a día, salen a flote diversas prácticas que desvirtúan Scrum, prácticas que se llevan a cabo de manera incorrecta (de manera intencional o no intencional), y por lo tanto un efecto aparente es que Scrum “no está funcionando”, cuando la causa raíz es, en realidad, una mala práctica, o lo que se conoce como un **antipatrón**.
Scrum un marco de trabajo, pero más que eso, hoy siendo las 5:34 a.m. del 8 de julio de 2024, continúa siendo **el marco de trabajo más utilizado en el mundo**, no lo digo yo, lo muestran los diversos estudios anuales sobre Agilidad o Agilismo que se publican por diversas organizaciones.
Scrum establece una forma de colaborar evaluando de manera continua cómo construir un producto (o servicio), obtener retroalimentación del cliente/usuario final, y adaptar creativamente en base a la información obtenida siempre centrados en entregar un incremento de producto que agregue valor al cliente/usuario final.
En este artículo no abordaremos lo que Scrum es, no es un artículo introductorio (si quieres leer un poco sobre los principios de Scrum, (link: https://leonelzapien.com/blog/que-es-scrum text: te comparto aquí un artículo que escribí sobre este tema hace un par de años)), aquí abordaremos sobre eso que “no es Scrum”, esos antipatrones que desvirtúan el marco de trabajo y consecuentemente llevan a equipos a sufrir el proceso y concluir que “Scrum no funciona”.
(image: scrum-logo.webp)
# Anti… ¿qué?
Aquí abro un breve paréntesis.
Primero lo primero, no sé si conozcas el término **antipatrón**, pero vamos iniciando aquí. Un antipatrón es un enfoque que nos va a conducir a una mala solución a un problema, pueden ser en ocasiones enfoques “generalizados” o que se utilicen ampliamente, pero, aun así, no deja de ser una solución inadecuada y por lo mismo son ineficaces y/o improductivos para resolver determinada clase de problemas comunes.
Una vez aclarado lo anterior, ya hemos calentado motores, entremos directo en tema sobre de antipatrones en Scrum, ¡Aquí vamos!
Cierro paréntesis.
# Scrum but
Hoy vengo a platicarte sobre algo que se conoce como **Scrum but…**, que traducido sería algo como **Scrum pero…**, y se le conoce así precisamente porque, cuando a alguien le preguntan:
- Y ustedes, ¿utilizan Scrum?
- ¡Claro que sí!
- ¿Y cómo les va con *[inserte-aquí-cualquier-tópico-relacionado-con-Scrum]* (por ejemplo, las retrospectivas / producto backlog / incrementos de producto / la definición de terminado, etc.)?
- Ah, bueno. Es que sí utilizamos **Scrum, pero…** *[inserte-aquí-cualquier-“parche”-o-forma-de-hacer-algo-que-no-está-alineado-con-La-Guía-Scrum]*
Y ahí es donde surge el “pero”, es ahí donde, como decimos acá en México, la puerca torció el rabo.
Por esto, hoy hablaremos sobre **Scrum but,** ya que esta lista de “peros” puede ser virtualmente infinita, vamos a ver algunos de los principales ejemplos que he tenido oportunidad de ver de primera mano en diversos equipos, así como posibles soluciones.
Un
![Innovación & MVP - Diseñar y probar hipótesis de negocio](http://leonelzapien.com/media/pages/blog/innovacion-mvp-disenar-y-probar-hipotesis-de-negocio/d35ef1e829-1717358050/experimento-ideas-de-negocio-mvp-leonel-zapielopez-ideas-agilidad-guadalajara-mexico.webp)
MVP, Product Management, Innovación
Innovación & MVP - Diseñar y probar hipótesis de negocio
“No cometas el error de ejecutar ideas de negocio sin evidencia: Prueba tus ideas, sin importar qué tan bien luzcan en teoría” – David J. Bland & Alex Osterwalder.
# Hipótesis de negocio
¿Tienes una idea de un nuevo producto o servicio?, ¿Una nueva funcionalidad que piensan agregar para tu usuario o cliente?, para pasar de una idea de negocio a un elemento validado, se debe de probar de manera rápida y lo más barato posible (en el artículo pasado hablamos sobre el **Producto Mínimo Viable o MVP**, Minimum Viable Product en inglés, puedes leer el artículo completo (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)).
Pues bien, está chévere esta idea de que un MVP nos invita a validar ideas de negocio con experimentos antes de ir a mayor escala. Pero ¿Por dónde empezar si quiero hacer un experimento para probar una idea?, ¿Por dónde inicio?
Lo primero que necesitamos asentar es que una **idea de negocio** es en realidad una **hipótesis** (ya sé que esto suena muy del ámbito científico, pero en realidad así es). Hasta que se valide obteniendo un resultado (se cumple y por lo tanto es correcta, o no se cumple), solo entonces dejará de ser una hipótesis.
“El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje.” – Eric Ries (The Lean Startup)
# Probar ideas de negocio: Un proceso iterativo
El ciclo Diseño-Prueba es un proceso iterativo, creado por David Bland & Alex Osterwalder, tiene dos grandes áreas: Diseño & Prueba, veamos cada una a detalle:
(image: design-test-innovacion-strategyzer-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp)
**Diseño:**
Es la actividad de llevar ideas vagas o dispersas, a proposiciones de valor, que después puedan concretarse como modelos de negocio.
**Prueba:**
Necesitamos descomponer una idea de negocio en hipótesis pequeñas y fáciles de validar mediante experimentos que proporcionen evidencia que ayuden a decidir los siguientes pasos.
# Diseño
En este primer paso el objetivo es generar la mayor cantidad de opciones como sea posible (debemos evitar enamorarnos de nuestra primera idea, no es personal, solo son negocios), basándose en la intuición, observación o en lo que se conozca sobre los clientes.
(image: design-test-innovacion-strategyzer-01-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp)
Las ideas locas, irreverentes, aquellas que retan el Status Quo, son más que bienvenidas (de hecho, eso es lo que buscamos). En este punto, no es el momento de empezar a desmenuzar el modelo de negocio y cuestionar la validez o potencial éxito en el mercado de una idea. No aún. **Queremos que el equipo diseñe como si tuviera razón**, ¿Tenemos sobre la mesa alguna idea de negocio innovadora?
**Pregunta para llevar: **
¿El equipo está “empujando” los límites?, o ¿Están jugando a lo seguro y manteniéndose cerca de lo que la empresa hace actualmente?
# Prueba
Una vez estemos satisfechos con lo realizado en la etapa de diseño, es hora de pasar a las pruebas.
(image: design-test-innovacion-strategyzer-02-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp)
El primer paso en el ciclo de prueba es definir y priorizar las hipótesis de negocio. Si la hipótesis es muy grande, la dividimos pequeñas partes comprobables. Aquí lo esencial es la palabra “comprobable”, para esto debemos cocrear (de verdad, es increíble el poder de la crear de manera colaborativa), seleccionar y ejecutar experimentos adecuados que nos proporcionen información que respalde y nos ayuden a validar (o desechar) nuestras hipótesis. En pocas palabras, necesitamos **evidencia**.
# Tarjeta de Prueba o Test Card
Aquí te comparto una herramienta muy útil, desarrollada por Strategyzer, que nos ayuda a definir un experimento para probar una idea: (link: https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card text: La Tarjeta de Prueba (Test Card)). Aquí veremos brevemente cómo llenar esta tarjeta:
(image: test-card-strategyzer-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp)
1. **Hipótesis:** Define la idea de negocio que se cree que es verdadera.
**Ejemplo: **“Creemos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.”
2. **Prueba:** ¿Qué experimento (o experimentos) ejecutarás para determinar obtener información que permita validar si hipótesis es verdadera o falsa?
**Ejemplo: **“Para verificar esto, nosotros agregaremos un breve video sobre el curso y un botón de
![El Método Lean Startup & Producto Mínimo Viable (MVP)](http://leonelzapien.com/media/pages/blog/el-metodo-lean-startup-producto-minimo-viable-mvp/94e0c6cfab-1715027020/leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-blog.webp)
Product Management, MVP, Innovación
El Método Lean Startup & Producto Mínimo Viable (MVP)
“Si estamos creando algo que nadie quiere, no importa si lo hacemos en tiempo y dentro del presupuesto” – Eric Ries El creador del método Lean Startup, Eric Ries, menciona que “demasiados planes de negocio parecen diseñados para planificar cómo lanzar un cohete: Prescriben los pasos que hay que dar y los resultados esperables con un gran nivel de detalle en cada paso, lo establecen todo como si cada minúsculo error en las asunciones o suposiciones pudiera llevar a un resultado catastrófico.” Eric Ries lo deja muy en claro: No podemos prever todos los posibles pasos (por más análisis de Fortalezas y Debilidades, de riesgos, estimaciones, simulaciones, y una larga lista de etcéteras), no podemos preparar cada detalle, nunca podremos concebir todos los posibles escenarios. Es por esto que Eric Ries, propone: **El Método Lean Startup**, que se basa en una premisa simple pero fundamental: En lugar de hacer planes complejos basados en muchas suposiciones, se pueden hacer ajustes constantes mediante un ciclo de retroalimentación llamado **Crear-Medir-Aprender**. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-01.webp) En el artículo de hoy, hablaremos sobre Lean Startup, el ciclo Crear-Medir-Aprender, y sobre el poderoso enfoque del **Producto Mínimo Viable** (**MVP**, por sus siglas en inglés, Minimum Viable Product). # El caso de IMVU: Un error garrafal que llevó a la gran epifanía de Eric Ries IMVU, una gran empresa dedicada al desarrollo de software, decidió entrar en el mercado de mensajería instantánea. Era el año 2004, y este mercado en aquel tiempo tenía centenares de millones de usuarios a nivel mundial. Empresas como AOL (America On Line), Microsoft y Yahoo! dominaban el mercado. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-02.webp) IMVU llega con una nueva idea: Mundos y juegos virtuales a través de avatares 3D personalizables, que pueden agregarse a las aplicaciones de mensajería instantánea ya existentes. Si el mercado de mensajería instantánea tenía cientos de millones de usuarios, entrar con esta propuesta que complementaba a las aplicaciones de mensajería, sonaba como un gran éxito. El equipo de IMVU, liderados en aquel tiempo por Eric Ries, estuvo más de 6 meses trabajando intensamente para desarrollar este producto, haciendo pruebas, discutiendo qué elementos o funcionalidades agregar y cuáles remover, poniendo muchísimo esfuerzo en la calidad, trabajando durante meses, jornadas hasta altas horas de la noche y fines de semana. Finalmente llegó el gran día del lanzamiento. Eric Ries menciona al respecto lo siguiente: **“Y entonces, ¡no pasó nada! Resultó que nadie probó nuestro producto”** **“Nuestra propuesta de valor estaba tan desencaminada de lo que los clientes querían, que ni siquiera lo probaban**, y, por lo tanto, no llegaban a descubrir lo malas que habían sido nuestras elecciones sobre el diseño. Los consumidores no descargaban nuestro producto.” El equipo de IMVU optó por hacer mejoras al producto, introducir nuevos cambios, uno que otro cliente llegaba a descargar su producto (Eric Ries reconoce que al inicio eran principalmente amigos y familiares de ellos mismos), y a pesar de tantas mejoras y retrabajo, pronto se quedaron sin amigos que quisieran probar su producto, y con unos ingresos mensuales de poco más de $300 dólares al mes. **“Estábamos mejorando el producto día a día, pero el comportamiento de los consumidores no cambiaba: todavía no querían probarlo.”** # Momento de hacer las cosas de manera diferente Para que el equipo de IMVU intentara hacer las cosas de manera distinta a partir de este punto, influyeron fuertemente dos factores: Un poco tuvo que ver la frustración de estar trabajando en un producto que nadie compraba, y un poco más tuvo que ver que se estuvieran quedando sin dinero para continuar operaciones. Hay un dicho: “La desesperación es la madre de la inventiva”, así que en este punto Eric Ries y todos en IMVU estaba bastante desesperados. ¿Qué hicieron ahora? **Comenzaron a hablar con los clientes** (verdaderas conversaciones, de esas que son cara a cara). Llevaban a clientes a sus oficinas, los entrevistaban, les mostraban pruebas de su producto, hacían ajustes en base a sus comentarios, y después volvían a mostrarles más pruebas. El equipo de IMVU tenía una idea en mente de su producto: Un avatar 3D que se puede personalizar, que se agrega como complemento a la aplicación de mensajería instantánea de preferencia del usuario, se enamora del producto, después invita a todos sus amigos a usarlo, y se vuelve viral. No suena nada mal. La cuestión es que después de docenas de entrevistas y pruebas con clientes reales, directo en sus oficinas, se dieron cuenta que su concepto de “mensajería instantánea complementaria” estaba destinado al fracaso desde un inicio, a nadie le interesaba eso. # Ok, y entonces ¿ahora qué? Era momento de reconocer que el trabajo de más de 8 meses no le interesaba a nadie. Trabajo tirado a la basura. ¿Cuál fue la razón de que el equipo de IMVU durara tanto para construir su producto?, habían estado trabajando en hacer un producto de alta calidad, que fuera compatible para todas las redes sociales o aplicaciones de mensajería de aquella época… y cuando hicieron todo esto, se dieron cuenta que a nadie le interesaba. # Es hora de hacer redirigir el rumbo: Pivotar (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-03.webp) Eric Ries menciona que Pivotar es detenerse, hacer una pausa y evaluar si merece la pena seguir por este camino. En este caso de IMVU, al reconocer finalmente que la respuesta de los clientes no era positiva, la decisión fue abandonar la estrategia inicial, **tomar un nuevo camino** lanzando un nuevo producto (hacer un pivote), y validar lo más pronto posible su nueva propuesta, directamente con los clientes. El objetivo de estas conversaciones directas y (ahora más frecuentes) que querían tener con los clientes era ayudarles a **identificar conforme iban construyendo su producto**, qué funcionalidades les gustaban a los clientes (aportan valor), y cuáles no (lo cual se considera como un desperdicio o despilfarro). La idea es obtener esta retroalimentación lo más pronto posible y no ya que el producto está totalmente terminado, 8 meses después, y descubrir que fueron 8 meses de trabajo tirado a la basura. No se trataba de adivinar lo que los clientes querían, ni de decirles lo que deberían de querer, sino de entenderlos, ver cómo utilizaban la propuesta de producto, y en base a la retroalimentación obtenida directamente de su experiencia con el producto, lo que Eric Ries llamó **Aprendizaje Validado**, ahora sí, mejorar el producto. “Cuando pivotamos a partir de la estrategia inicial (después de escuchar a los clientes), todo empezó a cambiar […] no porque estuviéramos trabajando más duro, sino porque lo hacíamos de una forma más inteligente, **a partir de escuchar las necesidades reales de nuestros clientes.**” # Ciclo Crear-Medir-Aprender Lo que el equipo de IMVU comenzó a hacer a partir de su experiencia anterior, fue plantearse una **hipótesis de negocio:** (sí, ya sé que esto de "hipótesis" suena muy del ámbito científico, pero en realidad así es, ya que es algo que creemos pero hasta que no lo validemos, no sabremos si es cierto o no). La hipótesis en este ejemplo era: Creemos que los jóvenes están interesados en un avatar 3D para sus aplicaciones de mensajería instantánea. Basados en esta hipótesis, en vez de construir durante 8 meses un producto que fuera compatible para todas las aplicaciones de mensajería, y que tuviera todas las funcionalidades, determinaron **construir un experimento que les permitiera validar su hipótesis lo más pronto posible.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-04.webp) **Crear **un producto que no fuera malo en cuestiones de calidad, pero no algo muy robusto ni sofisticado, solo las funcionalidades básicas y que pudiera utilizarse, por ejemplo, en vez de que fuera compatible con todas las aplicaciones de mensajería, elegir una sola, la de mayor uso (de esta manera, se requeriría relativamente muy poco tiempo en construirlo). Esta primera versión del producto es lo que se conoce como **Producto Mínimo Viable** (**MVP** por sus siglas en inglés, Minimum Viable Product), un producto con las mínimas funcionalidades que requerimos, solo las necesarias para probar si a la gente le aporta valor o no. Obtener información es el siguiente paso, a fin de poder **medir**… ¿Cómo medimos?, cara a cara con el cliente: Observándolo con nuestro producto o servicio, ¿Qué funcionalidades o características utiliza y cuáles no?, ¿Es fácil e intuitivo que lo utilice o tenemos que explicarle cómo hacerlo?, ¿Cuáles son sus comentarios después de utilizar nuestro producto?, ¿Le gusta?, ¿Realmente resuelve su necesidad o le hace la vida más fácil?, ¿Descargan nuestra versión del producto?, ¿La recomiendan? La idea es obtener información relevante, **métricas accionables** que nos ayuden a determinar cómo vamos. **Aprender **es el último paso de este ciclo. En base a la información recabada, ¿Cómo vamos?, ¿Cuál es el aprendizaje validado después de correr este pequeño experimento?, aquí la cuestión fundamental es: La hipótesis de negocio que habíamos considerado de manera inicial, ¿se cumple?, si la respuesta es positiva, podemos continuar por este rumbo con un producto o servicio que sabemos que tiene aceptación de parte de los clientes, tal vez agregando o removiendo algunas funcionalidades o características, haciendo algunos ajustes. Por otro lado, tal vez la respuesta es negativa y a nadie le interesa este producto o servicio, si es el caso, se debe de evaluar si es necesario hacer un **pivote** y ajustar el rumbo: **Plantear una nueva hipótesis de negocio y volver a correr el ciclo Crear-Medir-Aprender.** # El Método Lean Startup Así nace el método Lean Startup, creado por Eric Ries. Pero a todo esto, **¿Qué es el Método Lean Startup? La aplicación del pensamiento Lean (reducir el desperdicio o despilfarro) al proceso de Innovación.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) En el método Lean Startup, un experimento es más que una simple investigación teórica; también es un primer producto. Un **Producto Mínimo Viable o MVP**, que ayude a empezar con el proceso de aprendizaje lo más pronto posible. El MVP no es necesariamente el producto más pequeño que se pueda imaginar; es la forma más rápida de entrar en el ciclo de retroalimentación **Crear-Medir-Aprender** con el mínimo esfuerzo (y lo más barato posible). El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje. A lo largo de este proceso, tras muchas iteraciones, se puede descubrir que algún elemento del producto o estrategia es erróneo y decidir que ha llegado el momento de cambiar, un pivote, a un método diferente para alcanzar la visión. # ¿Y es factible construir ese MVP? Ok, esa idea de MVP suena bien... pero ¿Ya existe la tecnología de Star Trek para teletransportar a una persona, o hacer maleable el adamantium?, aquí la palabra clave es si este MVP es **factible **de construirse. De acuerdo con **Paulo Caroli**, famoso escritor y desarrollador de **Lean Inception **(sí, lo sé. Parece que todos se han puesto de acuerdo para agregar la palabra “Lean” como prefijo a todo lo nuevo), el error más común en la creación de un MVP es el pensamiento unilateral: Pensar solo en el desafío tecnológico, o solo en lo que le encantaría al usuario, o simplemente en lo que valida el negocio. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-06.webp) Un MVP adecuado, de acuerdo con Paulo Caroli, se encuentra justo en la intersección de: 1. Lo que es valioso para el usuario. 2. Es utilizable. 3. Es técnica y económicamente factible construirlo. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) # Conclusiones Es imposible predecir cómo responderá un cliente a un producto o servicio que se lance al mercado. La mejor manera de entonces de actuar es escucharlo directamente, cómo responde y cuáles son sus necesidades reales. Para esto, la mejor aproximación es partir de experimentos, un producto mínimamente viable que nos ayude a validar una hipótesis de negocio de manera rápida y barata, antes de proceder a construir un producto o servicio a mayor escala y detalle. Para esto nos podemos apoyar en el ciclo Crear-Medir-Aprender, y cada vez que completemos una vuelta a este ciclo, determinar la forma en que habremos de actuar en base al **aprendizaje validado** que hemos obtenido. Eric Ries menciona que “la cantidad de tiempo que una empresa puede mantenerse como líder del mercado para explotar sus primeras innovaciones se está reduciendo y esto crea un imperativo. Incluso para las empresas más afianzadas: invertir en innovación”, y ¿Cómo podemos hacer esto?, creando algo “barato”, midiendo con los clientes o usuarios finales, aprendiendo, determinar si es necesario ajustar, y volver a iniciar. Añadiría un elemento más a lo anterior: Aprender divirtiéndonos durante el proceso, disfrutar el viaje por el ciclo Crear-Medir-Aprender, si hacemos lo que hacemos con pasión, la experiencia (además de enriquecedora), será totalmente memorable. **¿Habías escuchado hablar antes del Método Lean Startup?, ¿Cómo te ha ido experimentando con MVPs y obteniendo aprendizaje validado de tus productos o servicios?** ## Referencia: • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries. • Lean inception: Creando conversaciones hacia un producto exitoso. Paulo Caroli.
6 de mayo de 2024Yo soy
Leonel :)
![leonel-zapien-lopez-ideas-agilidad-consultor-agile-scrum-management-3.0-kanban-guadalajara-mexico](http://leonelzapien.com/media/pages/home/da73ef4bef-1713544151/leonel-zapien-lopez-ideas-agilidad-consultor-agile-scrum-management-3.0-kanban-guadalajara-mexico.webp)
¡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