[Web] La delegación en tiempos del covid-19

Imagen de Gerd Altmann en Pixabay 

Son tiempos difíciles. Estamos atravesando una crisis sin precedentes en la humanidad. Con asombrosa rapidez, hemos tenido que adaptarnos a un entorno que no imaginábamos posible hace apenas algunas semanas.

Afortunadamente, para quienes hemos navegado en la incertidumbre y la volatilidad, estos escenarios no son del todo novedosos. Hemos insistido hasta la saciedad en la última década que debemos practicar y promover la adaptación a los cambios. Sabemos que la vida, como la conocemos, es capaz de transformar hábitats de una perfección inescrutable, en ambientes aún más complejos y virtuosos.

Los cambios están ocurriendo por doquier, sin parar y sin que haya un comando y control superior para dar órdenes y, para ello, en las organizaciones hemos puesto de manifiesto la necesidad de delegar. Y los tiempos actuales requieren de medidas actuales. El trabajo remoto, cuya necesidad es a todas luces evidente, demanda un alto nivel de confianza y de empoderamiento en las personas.

El objetivo es lograr que nos ocupemos de todas las tareas habituales sin supervisión, que se establezca una meta, una dirección y se fijen prioridades, se analicen los problemas, se hagan planes, se ejecuten y se tomen decisiones difíciles. Todo sin la mirada del Gran Hermano sobre nosotros. Se trata de que las personas y los equipos sean efectivamente autónomos y autoorganizados.

¿Cómo lograrlo? En esta sesión hablaremos de ello, delegación y empoderamiento, cómo no controlar mientras nos cuidamos de una pandemia para sobrevivir en este universo pletórico de ambigüedades y complejidades, niveles de delegación y qué tiene que ver la confianza en todo esto. Se trata de hacerlo gradual aunque hoy no tenemos mucho tiempo, pero es posible pensar en delegar una gran tarea mientras nos tomamos treinta segundos para lavar bien nuestras manos y cuidarnos de la enfermedad.

¡Los esperamos!

Pueden descargar la presentación aquí.

Puedes ver el video de esta presentación, facilitada para la Tribu Ágil de Perú el 17 de abril de 2020:

El imposible y desatinado caso de SCRUMStudy®

Imagen de Sophie Janotta en Pixabay

Una colega lanzó esta pregunta en una comunidad de Scrum Masters:

Que tal grupo, […],

Duda: (corríjanme si estoy mal, por favor)

Entre las diferentes compañías tales como SCRUMstudy^®, Scrum Alliance, Scrum.org, etc.

En cuestión a la teoría que imparten todas las diferentes compañías/empresas ¿existe alguna diferencia entre el contenido que imparten para enseñar a sus receptores Scrum? o ¿Todas las compañías en cuestión a teoría enseñan lo mismo pero te certifican según la compañía en la que tomaste la capacitación o curso?

[…]

Saludos.

[Texto copiado con permiso de su autora]

Recordé que hace ya algún tiempo estuve involucrado en otro foro sobre la muchas veces discutida pregunta “¿dónde me certifico?”. Mis ideas de entonces quedaron registradas en:

https://www.linkedin.com/pulse/donde-me-certifico-como-scrum-master-luis-antonio-salazar-caraballo/

Pero esta nueva pregunta iba más allá. Hablaba de la teoría. Y lo que más me llamó la atención fueron las respuestas iniciales de otros foristas quienes, de alguna manera, no diferenciaban en el tratamiento de Scrum que hace el así llamado SBOK^® y la guía oficial de Scrum, escrita por sus creadores.

Como es un tema escabroso, de esos que elevan las pasiones, lo pensé mucho antes de involucrarme. Finalmente, pudo más la responsabilidad que tengo con el “hacer bien las cosas”, el compromiso que tengo con el mejoramiento del uso de Scrum por parte de las personas, equipos y organizaciones a mi alrededor. Así que esta fue mi respuesta:

Imagen de David Mark en Pixabay

A ver si trato de explicar esto con una analogía:

Aunque la FIFA no inventó el Fútbol, es hoy el organismo que “rige” los estándares, que regula, que establece las “reglas” de ese deporte. A pesar de ello, es posible jugar al fútbol con variantes y no “pasa nada”: fútbol playa, fútbol 5, fútbol 7, fútbol sin porterías, etcétera. Cada una de estas otras versiones tiene distintas reglas, creadas o inventadas por nosotros mismos, las personas, o por algún organismo distinto a la FIFA. Hay menos jugadores en algunos, hay variaciones en las reglas, en fin. Pero en definitiva, el Fútbol como tal, el deporte del balón, el universal, es el de la FIFA.

Así ocurre con Scrum. Este marco de trabajo fue creado por Jeff Sutherland y Ken Schwaber y fueron ellos quienes escribieron originalmente lo que hoy se conoce como la guía de Scrum. El primer documento lo presentaron al mundo en 1995. Puedes encontrar más de los orígenes de Scrum en:

https://www.scruminc.com/origins-of-scrum/

Ahora bien, son Jeff Sutherland y Ken Schwaber quienes siguen actualizando y manteniendo la guía (la teoría) de Scrum de tanto en tanto. Ellos reciben la retroalimentación de la comunidad pero finalmente ellos son sus creadores y, por decirlo de alguna manera, sus guardianes. Aunque bien todos nosotros deberíamos ser custodios de esa guía oficial también.

Después de Scrum llegaron organizaciones como la Scrum Alliance, creada precisamente para fomentar el uso del framework. Ellos crearon algunas certificaciones asociadas: Scrum Master, Product Owner y Scrum Developer. Y basaron sus cursos y certificaciones en la guía de Scrum escrita por Sutherland y Schwaber.

Más tarde aparecieron empresas como Scrum.org de Ken Schwaber y Scrum Inc., de Jeff Sutherland.

Y luego otras empresas certificadoras. Incluyendo SCRUMStudy^®. Casi todas estas últimas empresas certificadoras de Scrum son independientes, de terceros, pero basan sus certificaciones en la guía de Scrum escrita por Sutherland y Schwaber, la guía oficial.

Casi todas, excepto SCRUMStudy^®, que basa sus entrenamientos (teoría) y exámenes de certificación en un libro que ellos llaman Scrum Body of Knowledge (SBOK^®). Un libro de más de 400 páginas la última vez que lo consulté. Mientras que la guía oficial solo tiene unas 18 páginas en español.

Imagen de LhcCoutinho en Pixabay

Este SBOK^® es como esas otras versiones de Fútbol de las que te hablé al comienzo. Tiene otras reglas, muy diferentes a las que tiene la guía de Sutherland y Schwaber, los creadores de Scrum.  Imagina las diferencias nada más en número de páginas. De 18 a más de 400. Pero quisiera poner tres ejemplos de las disparidades que presenta la una versus la otra:

1. Roles propuestos: en Scrum “oficial” (en la guía de Sutherland y Schwaber, la de 18 páginas), los tres roles propuestos son: Dueño de Producto, Scrum Master y Equipo de Desarrollo. Solo tres y nada más que tres. Estos tres roles forman lo que conocemos como Equipo Scrum. Mientras tanto en el SBOK^® se proponen 2 tipos de roles: Roles Core y Roles Non-core. A los primeros pertenecen los tres roles de la guía oficial aunque con una discrepancia: el equipo de desarrollo se llama Equipo Scrum. En la guía oficial, como dije antes, este Equipo está compuesto por los tres roles. Aquí no. Y los roles non-core son Stakeholders (dentro de los cuales cuentas Customer, Usuarios y Patrocinador), Vendedores y Cuerpo de asesoramiento de Scrum. En definitiva, son reglas distintas.
2. En la guía oficial de Scrum, el tamaño del equipo de desarrollo va de 3 a 9 personas. En la sección 3.6.2 (Tamaño del Equipo Scrum), el SBOK^® dice que “El tamaño óptimo de un Equipo Scrum es de seis a diez miembros”. Otra vez, una regla disímil.
3. En la guía oficial de Scrum, la duración máxima del Sprint es de un mes. Mientras que en la sección 2.7.1 (Scrum Time-boxes), el SBOK^® dice que “Un Sprint es una iteración Time-boxed de una a seis semanas de duración”. Otra disparidad.

Y así podemos encontrar muchas. De 18 a más de 400 páginas. Simplemente son reglas desiguales, algunas muy opuestas. El SBOK^® No es Scrum.

Con esto solo estoy tratando de señalar que la guía de Scrum, la cual puedes descargar de inmediato desde https://www.scrumguides.org/download.html o directamente la edición en español desde: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf, es la guía oficial que te presenta la teoría y las reglas de Scrum. Es la única fuente fiel, escrita y mantenida por sus creadores.

¿Quién sabe? Seguramente, si vas a jugar Fútbol y tomas el balón con la mano o si en tu equipo hay trece jugadores en la cancha recibirás una infracción y quizás hasta no puedas jugar.

Espero que sea de utilidad.

Saludos,

Las primeras reacciones a mis ideas en el foro fueron bastante positivas. De hecho, mucho más de lo que merezco. Pero eso me motivó a trasladar la explicación hasta mi Gazafatonario, para que más personas tuvieran acceso a ella. Por favor, déjame saber qué piensas al respecto.

Soy un buen Scrum Master pero la empresa no está preparada

O “Soy un buen Scrum Master pero la empresa no es ágil”

Imagen de mohamed Hassan en Pixabay

Cuando eres Scrum Master, sea cual fuere tu nivel de experiencia o de madurez en el rol, nunca más se da el caso de “no soy yo, son ellos”:

• Es que apenas están implementando Scrum, ellos (la organización, los equipos, las personas) no están maduros. | ¿Es posible “implementar” Scrum?
• Es que todavía están (los equipos, las personas) atascados en los modos tradicionales de gestión y creen que soy el jefe o el gerente.
• Es que ellos necesitan entender la nueva forma ágil de trabajar que quieren adoptar. | ¿”Adoptar”, luego no era “implementar” Scrum?
• Es que están esperando que yo comande al equipo desde alguna suerte de puesto de control o cabina de mando.
• Es que yo no tengo autoridad sobre el equipo. Soy solo un líder servicial a su servicio, como dice la guía de Scrum. Y el equipo es autogestionado. Funciona por sí solo. | ¿Un equipo “funciona”?
• Y la lista de razones puede llegar a ser interminable.

Muchas organizaciones con una fuerte cultura de comando y control no te tomarán en serio como Scrum Master si no muestras habilidades para tomar el control de la situación. Las formas de hacer las cosas y mucho menos las formas de pensar actuales se cambian en pocos meses. Hacer que la empresa, los equipos y las personas maduren o siquiera estén conscientes de su nivel de agilidad es tu responsabilidad también.

Imagen de Gerd Altmann en Pixabay

No puedes simplemente ignorar la cultura actual de la organización y conducirte sobre los nuevos preceptos que te “dicta” la agilidad, el pensamiento Lean o prácticas como Scrum. “Es que ellos no entienden nada de liderazgo servicial ni de mejoramiento continuo”. No hay tal cosa como “ellos y nosotros” en el pensamiento ágil.

No te apresures. Da un paso a la vez y aprende de la reacción del entorno. Concéntrate primero en el equipo y ve escuchando al resto de la organización sin atribularte por la avalancha de ideas, solicitudes, advertencias, restricciones, desafíos, oposiciones y demás escenarios que vas a vivenciar. Para ello, viene bien hacerse acompañar de otros Scrum Masters, coaches ágiles o de cualesquiera que te proporcione ideas y que desee llevarlas a cabo contigo.

Estás allí para enseñarle a cada miembro del equipo a ser un líder, para empoderarlo y ayudarlo a aclarar su rol en este nuevo orden de las cosas, para remover algunos de los obstáculos en su camino pero más que a nada para instruirlo en cómo eliminarlos por sí mismo. Por sobre todas las cosas, no pierdas de vista que vienen de la cultura de ser recursos, así que piensa en ellos como personas y haz todo lo que esté a tu alcance para aumentar su felicidad.

Eres su entrenador pero deja que ellos también te entrenen. Aprende de la cultura y de los comportamientos imperantes. Luego, comienza a promover y a resaltar nuevos comportamientos “a lo ágil” y a desalentar, sin presión, las conductas actuales que no posibilitan el mejoramiento del equipo. Define un buen conjunto de valores que sean consistentes con el mensaje que quieres enviar y con el nuevo camino que les quieres mostrar, los valores de Scrum te ayudan, sí.

Asegura victorias tempranas. Una matriz de Esfuerzo versus Valor siempre viene bien en estos casos. Asegúrate de hacer con tu nuevo equipo lo que está en la zona de mayor Valor pero menor Esfuerzo y por ningún motivo mires la zona de mayor valor y menor esfuerzo.

Matriz de Esfuerzo versus Valor

Esfuerzo y Valor son relativos. Asume que todo lo que haces genera Valor y requiere de cierto esfuerzo. Pero incluye las variables que necesites para garantizar que algunas tareas, de tres a cinco de ellas, generan más valor que otras y requieren menos esfuerzo que otras. Y así, hasta completar la matriz. Distintos ejercicios te pueden llevar a lograr esto en pocos minutos, aun si tu equipo no es el mejor comunicándose.

Ve a lo seguro, sin dejar de experimentar. Después de todo, de eso se trata, de aprender mediante experimentos rápidos y baratos. Sigue la línea Shu-Ha-Ri como en esta infografía que preparé con mi gran amigo, compañero de batallas ágiles, Jorge Abad (@Jorge_Abad):

Scrum Master Shu-Ha-Ri

En esta etapa inicial, como Scrum Master, sigue la guía de Scrum con cierta precisión. Concéntrate en cómo organizar y llevar a cabo los eventos con el equipo, que se tengan los artefactos y que cada miembro del equipo Scrum se desempeñe como lo plantea la guía, sin preocuparte demasiado por la teoría subyacente; por ejemplo, en cómo planificar en un entorno empírico. Si hay múltiples variaciones sobre cómo hacer algo, solo decídete por la forma en que la guía lo establece o en como lo aprendiste. Tengo que decirlo, en este último caso, quizás estés equivocado, así que igual, hazte acompañar de alguien más experimentado, incluso de miembros de tu nuevo equipo. Ellos ahora son tu familia.

Más adelante pasarás a los demás estados. Recuerda que si ingresaste al equipo y a la organización, hay una alta probabilidad de que la madurez en materia de desempeño de todos quizás se reinicie “a lo Tuckman”, en donde los miembros del equipo tengan miedo (otra vez) de pedir ayuda unos a otros y a ti, no confiarán completamente en ti y te monitorean de cerca cuando estés trabajando en una tarea específica, con o sin ellos; muchos de ellos tendrán sus propias ideas sobre el proceso y las agendas personales serán rampantes; quizás te encuentres con roles específicos dentro del equipo, como líder técnico, facilitador, diseñador, documentador, incluso gerente; volverán las discusiones abstractas (si alguna vez se fueron) sobre distintos conceptos y temas y algunos miembros estarán impacientes con estos debates. Entre otros comportamientos típicos de la etapa de Formación de un equipo tradicional.

Incluso parecerá que estás logrando poco hacia la consecución de los objetivos del proyecto (sí, todavía se llamará “proyecto) y recibirás toda la carga de la culpa cuando te señalen a ti y a la nueva forma ágil de hacer las cosas que intentas poner de manifiesto en el ambiente. No te preocupes mucho por ello, aunque no estén completamente seguros de las metas y problemas del proyecto, algunos, quizás todos, estarán entusiasmados y orgullosos de estar en el equipo y a la expectativa de lo que pueda venir.

Las cosas así, quizás no puedas ir más allá del estado Shu, así te sientas con la fuerza, la experiencia y el coraje para empezar con el estado Ri. Lo leí de Melina Jajamovich (@latodoterreno) recientemente, “No hay seniority que valga cuando se trata de #agilidad | El mindset es un desafío de cada día”. Eres un eterno aprendiz, inculca eso en tu equipo, estás allí para acompañarlos a ser mejores.

Finalmente, empieza a pensar en el futuro del equipo. De hecho, esto se convertirá en lo más común y en lo mejor que podrás hacer en tu nuevo rol. Con el tiempo aprenderás que para un Scrum Master extraordinario no hay tal cosa como “no puedo hacer esto o aquello porque surgió algo urgente”. Debes adelantarte en el tiempo y visionar cómo llevarás al equipo al siguiente nivel de crecimiento, sin dejar de vivir en el presente para estar al frente de las tareas menos mundanas de protección y liderazgo del equipo.

Ya eres Scrum Master, no lo eches a perder solo porque el resto de la organización no te entiende. Asume tu responsabilidad, toma el control y muéstrales las cosas fantásticas que pueden lograr con agilidad. Es tiempo de cambiar.

La deuda de producto: cómo se manifiesta y qué hacer al respecto

The Uncomfortable Entrance - Illustration by Katerina Kamprani

Este tipo de deuda se presenta cuando el producto no constituye algo significativo para tu identidad como consumidor o usuario, para tu desarrollo personal o tu bienestar. Aquí estamos hablando de la experiencia de usuario. Es decir, si el producto no genera en sus consumidores emociones y actitudes positivas que sean capaces de impactar su estatus actual. O si esos usuarios no perciben aspectos del producto como su utilidad, la facilidad de uso y la eficiencia, entonces estamos ante una deuda en rojo.

Le faltan esos atributos tangibles e intangibles que brindan al consumidor los beneficios esperados por este y que le resuelven una necesidad específica. Con tangibles me refiero a lo que hace el producto, a la tecnología, al diseño, a la forma. Con intangibles, a los elementos emocionales que generan apego en el usuario, a su identidad de marca, a su ecosistema, a si impacta positivamente la vida de quienes lo consumen y si ese impacto es sostenible. Otra vez, estas dos clases de características es lo que hace posible una extraordinaria experiencia de consumidor, de cliente.

La deuda de producto también es interna, algo que muchas veces ni siquiera el usuario es capaz de percibir. Me refiero a la cultura de Agilidad en medio de la cual fue creado o elaborado el producto, al empoderamiento del equipo, a la felicidad de sus miembros, al foco en el cliente que pusieron todas las personas encargadas de su ideación, descubrimiento, prototipado, desarrollo y puesta en producción de ese producto.

La deuda de producto crece cuando el equipo no aprendió ni mejoró un ápice durante su desarrollo. Además, si el equipo y otros interesados no conocen al cliente, cuáles son sus necesidades o porqué deberían adquirir o usar el producto, la deuda de ese producto también se incrementa.

Si no hubo confianza en el equipo, no se le delegaron las principales responsabilidades para elaborar el producto ni se les habilitó un entorno seguro, donde el empoderamiento y la experimentación estuvieran a la orden del día, hay más deuda de producto.

Si todas las buenas ideas del producto terminan con su despliegue al mercado, todavía habrá un gran camino que recorrer, una deuda aumentada que pagar. El despliegue del producto no es el objetivo. La meta es el cliente, su satisfacción, su felicidad, mejorar su modus vivendi. Si nos quedamos en la puesta en marcha del producto, apenas si nos habremos concentrado en la salida del producto, un número de características de las cuales no sabemos cuáles serán usadas y cuáles no. Consecuencia: más deuda de producto. En cambio, si nuestro foco es el cliente y sus necesidades y la experiencia que tenga usando el producto, entonces estaremos concentrándonos en el valor, en el resultado positivo que puede entregar ese producto a la humanidad.

Otras causas de la deuda de producto:

• Siempre aplicamos las mismas prácticas en todas partes
• Siempre exigimos adherencia a actividades y procesos, ágiles o no
• Definimos la cadena de herramientas permitida
• Forzamos la estandarización en todas partes
• Creemos que el proceso habla por sí mismo
• Confiamos en el proceso más que en las personas y el equipo

Las cosas así, podríamos definir la deuda de producto como:

Deuda de Producto = Falta de Experiencia de Usuario + Falta de Tangibles (Tecnología, Diseño, Forma) + Falta de Intangibles (Emociones, Identidad de Marca) + Falta de Agilidad + Falta de Foco en el Cliente + Falta de Confianza en el Equipo + Falta de Delegación + Otros*

* Incluye aquí los que aplican para tu entorno específico

Para no incurrir en más deuda de producto

El Dueño de Producto debe:

• Definir y liderar la visión del producto.
• Investigar y probar las necesidades del cliente / mercado
• Identificar opciones de productos de alto valor.
• Hacer que los elementos del backlog estén "preparados" para su planificación y desarrollo
• Aceptar solo trabajo "terminado"
• Realizar demostraciones de producto
• Fomentar la consistencia donde esta sea importante, en todos los niveles de la organización
• Explicar siempre el valor detrás de un proceso
• Observar, aprender de y analizar el mercado.
• Compartir ideas en la organización con respecto al producto y aceptar retroalimentación oportuna
• Decidir las fechas de lanzamiento y el contenido.
• Salir al mercado (a producción) tan rápido como sea posible e ir afinando el producto a medida que recibe información de su uso
• No lanzar en la fecha, lanzar en calidad (a lo Spotify).
• Asegurarse de que el producto vaya de excelente en su salida inicial a extraordinario después del lanzamiento, afinándolo continuamente.
• Saber cuándo descontinuar o sacar el producto del mercado

El equipo de desarrollo de producto debe:

• Ser pragmático en la elección de las herramientas
• No obsesionarse con las ceremonias o eventos de un proceso o marco de trabajo, por muy ágil que este parezca. Atención a eso Scrum Másters, coaches ágiles, habilitadores ágiles, consultores Lean y estrategas Kanban, entre otros.
• Demostrar voluntad de evolucionar en función de la retroalimentación que proporcione el entorno

Toda la organización debe:

• Concentrarse en el Valor.

¡Esperen! Sobre Valor del producto hablaré en una próxima oportunidad. Hasta entonces, déjame saber en el foro tus experiencias e impresiones sobre este asunto crítico de la deuda de producto.

Créditos de la imagen de portada:

The Uncomfortable Entrance

Illustrations by Katerina Kamprani

https://www.theuncomfortable.com/portfolio/the-uncomfortable-entrance/

Las mejores o buenas prácticas ágiles no existen

¡Las peores o malas tampoco!

Veamos la historia de cómo es esto.

Hace quince años escribía un artículo que dio pie a mi primer libro Asuntos de la Ingeniería de Software (clic aquí), se trata de las muy comentadas hace un par de décadas: Seis Mejores Prácticas (clic aquí), las mismas que promulgaba el Proceso Unificado (UP o RUP, dependiendo de la edición que hayamos usado de la metodología - clic aquí).

Lo nuestro ahora son los experimentos, usamos lineamientos “tipo Scrum” basados en la teoría del control empírico de procesos, planteamos hipótesis y las probamos en períodos muy cortos de tiempo, tratando de aumentar el número de experimentos por unidad de tiempo. De esta manera, si fallamos, lo hacemos rápido y barato; pero si tenemos éxito, entregamos valor igual de rápido y de barato.

De esta forma, toda práctica, toda idea es bienvenida. El hecho de que una práctica no le funcione a un equipo o a una organización no quiere decir que no le servirá a otro equipo o a otra organización, incluso entre equipos de la misma empresa esto puede suceder. Los escenarios y las variables del entorno son diversos, es por ello que dejamos atrás las recetas predefinidas tipo RUP, CMMi y similares. Pero el sentido inverso de esta afirmación también se cumple: el que funcione en un contexto no es garantía de que una práctica funcione en otro.

Hoy por hoy aprendemos por experimentación, descubrimos por experimentación (por ejemplo, descubrimos el software que escribimos), innovamos por experimentación, diseñamos por experimentación, cambiamos por experimentación. En este apartado quiero referirme precisamente a lo que Jason Little llama Gestión Lean del Cambio (clic aquí).

Un modelo no lineal, basado en la retroalimentación, para gestionar el cambio

Algo que nos ocurre muy seguido es que fallamos al tratar de identificar el problema correcto a resolver, lo que confluye en la insalubre generación de desperdicio. Toda práctica que nos posibilite el evitar esa falla se convierte en una sinfonía para nuestros oídos.  Los experimentos nos ayudan a reconocer a gran velocidad si el problema que tenemos entre manos es el oportuno, es el que debemos resolver a continuación.

De hecho, los experimentos están en el corazón de la innovación. También, las mejoras incrementales a los productos y servicios que desarrollamos requieren que hagamos experimentación continua. Para todo esto es necesario:

• Trabajar en equipo: el trabajo colaborativo, en equipo, la inteligencia colectiva es lo que permite el éxito. El ejercicio de la colaboración siempre está en la cima de mis prioridades.


• Simplicidad: no se trata solo de no generar desperdicio, sino también de refinar el problema, dividirlo en problemas cada vez más pequeños.


• Dar un paso a la vez: no tratemos de experimentar con todo y de todo de una sola vez. Esto casi siempre es un camino al abismo. Lo que quizás sí podemos hacer es realizar varios experimentos al tiempo. ¡Funciona para mí!


• Obtener conocimiento pronto y con frecuencia: hay que recorrer rápidamente todo el camino. El objetivo son los consumidores finales, no grupos controlados de clientes o usuarios.  Los MVP funcionan pero no todos pueden quedarse en el laboratorio.


• Estar preparados para fallar y aceptarlo: nos va a ocurrir. ¡Me ha ocurrido! Simplemente levántate mañana con más energía, con una gran sonrisa y con una nueva idea. En esto de la agilidad siempre sale el Sol, radiante, así que vuelve a invitar a tus amigos e inicia un nuevo experimento.


• Cerciorarse de que tu organización considere la seguridad como un prerrequisito valioso (agilidad moderna – clic aquí – donde, de hecho, experimentar y aprender rápidamente es otro principio).

De todo esto he logrado:

• Ahorrar dinero: tanto para mí como para las organizaciones para las cuales he trabajado y no hablo solo de mis empleadores, sino de los clientes también.


• Fallar de forma positiva: y también a evitar que se produzcan fallas más significativas que produzcan resultados desastrosos, grandes pérdidas de tiempo, dinero, oportunidad, marca y hasta de felicidad de todos los comprometidos.


• Desarrollar mejores productos y servicios: o ayudar a diseñarlos, descubrirlos y ponerlos en funcionamiento, al servicio de miles o de millones de personas.


• Aprender más y más rápido: la experimentación nos permite estar más informados y tomar mejores decisiones sobre nuestras ideas y proyectos. Muchas cosas parecen de sentido común, pero he aprendido que el sentido común muchas veces no es la práctica común.


• ¡Ser más feliz!

Y esta es la historia del porqué no existen las buenas, mejores, malas o peores prácticas en agilidad.

Por ello, la próxima vez que alguien te diga (incluso a veces levantándote la voz) que algo no se puede hacer bajo el manto de la agilidad o al usar Scrum o algún otro marco de trabajo ágil, indaga primero los hechos, los datos que dieron origen a tal aserción. O no lo hagas del todo. Simplemente realiza tu propio experimento y déjanos saber de los resultados. 

La soportable levedad del ser ágil

“La pubertad cercana a las Pléyades”, del artista surrealista Max Ernst.

“El hombre nunca puede saber qué debe querer, porque vive solo una vida y no tiene modo de compararla con sus vidas precedentes ni de enmendarla en sus vidas posteriores”.

[Milan Kundera, La insoportable levedad del ser. 1984]

Cavilar sobre qué es lo que decidimos ser y hacer implica reconocer que esas decisiones son únicas en su momento. No podemos regresar a ese evento en particular y cambiar de decisión. Lo que sí podemos hacer es reflexionar frecuentemente sobre cómo ser más efectivo… (El resto de la frase ya la conocemos, de lo contrario, la podemos buscar en el Manifiesto Ágil). En la práctica, no hay repetición de nada. Así que podemos darle poca o mucha importancia a esa decisión, recapacitar sobre sus posibles consecuencias e irremediablemente enfrentarlas como sea.

No queremos que los Scrum Masters, coaches ágiles, mentores, facilitadores ágiles, expertos, agentes de cambio, consultores ágiles, habilitadores de agilidad, especialistas Teal, managers 3.0, entrenadores Ágiles certificados, asesores Lean, asesores de confianza, Senseis de la transformación, peritos en trabajo en progreso y todos los que omito por no hacer interminable este panegírico, pasen a ser simplemente agilistas viejos, de los que ya nadie se acuerde y que desaparezcan en la nada. Pero es un hecho, tan solo unos cuantos, muy, muy pocos, imprimirán su nombre en la memoria de las personas, pero, ya sin testigos fehacientes, sin un solo recuerdo real, quizás pasen a ser marionetas de un movimiento que pudo cambiar el destino de millones de personas en el mundo.

Las decisiones, inevitablemente, implican conseguir información, hechos, pero también involucran sentimientos. Es precisamente por esas emociones que luego las consecuencias de tales decisiones se avistan como ventajosas o como desfavorables. De alguna manera, este constante cálculo entre lo que resulta conveniente para algunos, por interesante, por beneficioso, por experimentar algo distinto, tiene una consecuencia que, en términos de lo que queremos transformar, se podría medir como el peso o como la levedad de esa derivación.

Los agilistas estamos decididos a vivir con una levedad de ser alterada por temas como volatilidad, incertidumbre, complejidad, ambigüedad, ensayos,  valores y principios, eficiencia, entrega de valor, colaboración, mejoramiento continuo y adaptación a los cambios, que nos hacen examinar no solo la naturaleza de las organizaciones actuales, sino también indagar por la naturaleza humana misma. Ese es el motivo por el cual nos estamos cuestionando todo a cada momento, es por eso que tenemos ese apetito insaciable por aprender, por experimentar, por redescubrir quienes somos a cada instante.

Es posible que no seamos capaces de ser ágiles precisamente porque deseamos ser ágiles, porque queremos que los demás cambien (sean ágiles), en lugar de aproximarnos a ellos sin exigencias y querer solo su mera compañía en el proceso de transformación. La agilidad compromete un sinfín de ideas que son como los imperios: cuando desaparece la idea sobre la cual han sido construidos, perecen ellos también. Los agilistas, en cambio, debemos ser más fuertes que eso. Nuestras ideas deben o deberían permanecer más allá de nuestra presencia.

La cultura no es más la forma cómo hacemos las cosas por aquí, es la manera cómo cambiamos las cosas por aquí. Cambiar nosotros y cambiar nuestro entorno para mejorar significa, entre muchas otras cosas, desarraigar, desaprender y aprehender, es decir, olvidar lo antiguo, por obsoleto, por inútil, por falto de valor y entender nuevos modelos de pensamiento holístico, reconocer que la agilidad vive precisamente porque también está presente la posibilidad de su ausencia. Y eso, mis estimados amigos, es lo que nos asusta más.

La carga más pesada es por lo tanto, a la vez, la imagen del más intenso arraigo ágil que puedas encontrar. Cuanto más pesada sea la carga, más a ras de tierra estará nuestra visión, más real y verdadera será, alcanzable, soportable. ¡Es la soportable levedad del ser ágil! El ágil es algo que eres.

A propósito del nombre del libro que originó el título de este artículo, como agilista (en cualquiera de los sabores que he mencionado y en los que no), tu trabajo, tu tarea es crear personas, no recursos (personajes). Si es con pasión, seguramente vas a empatizar tanto con esas personas que al ayudar a transformarlas te vas a preguntar que harás con tu vida más adelante. Ellas no siempre son felices, no siempre saben lo que quieren, no siempre están insatisfechas ni tienen las ideas claras. Es quizás lo mismo que sucede contigo como agente de cambio pero es tu deber, o debería serlo, mostrar los posibles caminos, proponer los experimentos, llevarlas de la mano. 

Quienes finalmente quieren cambiar se esfuerzan por comprender la levedad de lo ágil y lo que parece una distraída intrascendencia de los conceptos de agilidad, entrega de valor y mejoramiento continuo. Primero a través de una ligera presunción de lo que todo esto puede ser, quedándose puramente en lo cosmético y “lindo” de las emociones ágiles, y después acudiendo a la ayuda de un agente de cambio, que es cuando quieren comprobar si es cierto que ser ágil y hacer ágil – o hacer agilidad – son dos cosas distintas.

No puedo terminar este discurso seudofilosófico (mea culpa) sin dejar de acudir directamente al tratamiento que Kundera hace de sus propios personajes en la novela de referencia y hacer un juego de palabras: «los personajes (ágiles) no nacen como los seres humanos, del cuerpo de su madre, sino de una situación, una frase, una metáfora en la que está depositada, como dentro de una nuez, una posibilidad humana fundamental que el autor (agente de cambio) cree que nadie ha descubierto aún o sobre la que nadie ha dicho aún nada esencial».

Durante mucho tiempo seguiremos retornando a lo esencial, a lo escuetamente fundamental, mientras el movimiento ágil que nos convoca no pare de recibir adeptos en sus filas.