9 + 1 acciones que debes empezar a realizar para ser un Scrum Master extraordinario

Photo by Parabol on Unsplash

Nivel: principiante. Para todo público.

Presentación

Como coach y consultor ágil, y antes Scrum Master, durante más de una década he acompañado y colaborado con muchos equipos en diferentes industrias. Hace poco publiqué con mi gran amigo Jorge Abad el libro Scrum:epítome de experiencias, que resume en 338 páginas muchos de los experimentos que realizamos y de las lecciones que aprendimos durante todo este tiempo. Espero que el libro llegue a tus manos en algún momento. Mientras tanto, en mi Gazafatonario seguiré compartiendo más de todo esto, incluyendo algunas de las cosas que me han sorprendido en el camino.

1.    Entender el rol y las responsabilidades de Scrum Master

Como Scrum Master, eres responsable del proceso Scrum. También eres responsable de brindar retroalimentación de calidad al equipo y eliminar impedimentos.

Una forma efectiva de pensar en esto es que tu trabajo como Scrum Master no es solo asegurarse de que todos estén haciendo su propio trabajo correctamente, sino también asegurarse de que sepan cómo hacerlo mejor, para que ya no te necesiten. O, al menos, dar esa impresión. En la práctica, un equipo, por muy maduro que sea, siempre necesitará de un Scrum Master extraordinario.

2.   El enfoque principal del Scrum Master es el empoderamiento del equipo, no la gestión de proyectos

•     No eres un director de proyectos. Un Scrum Master no es un administrador de proyectos; eres el coach del equipo. Como tal, tu enfoque principal debe ser ayudar al equipo a ser autoorganizado y multifuncional, eliminando los impedimentos para el progreso (en lugar de resolverlos todos).

•     Tu trabajo no es solo desarrollo. De hecho, si bien la organización para la que trabajas puede tener un rol de Product Owner establecido que administra los requisitos y libera valor en cada Sprint, no solo lo estarás acompañando durante toda la gesta como Scrum Master. Además, pasarás la mayor parte de tu tiempo trabajando directamente con todos los miembros del equipo de trabajo, empoderándolos, para ayudarlos a comprender lo que significa hacer el trabajo con un marco de desarrollo serializado de productos como Scrum (y por qué es importante) para que se sientan capacitados para tomar decisiones sobre la mejor manera de lograr los objetivos propuestos.

•     Necesitas que todos participen para que este enfoque funcione bien para todos los involucrados. Hay muchos beneficios asociados con mantener equipos lo suficientemente pequeños, por ejemplo, que todos sus miembros puedan tener cierta superposición en las habilidades propias de cada uno, es decir, que el equipo se convierta en uno multifuncional. También, cuando alguien que carece de experiencia necesita la ayuda de otra persona pero no sabe qué preguntas debe hacer primero antes de iniciar cualquier tipo de comunicación entre ellos, la sinergia existente en un equipo pequeño hace que esa comunicación comience a ser más fluida. Además, un Scrum Master extraordinario puede ayudar a que las personas del equipo se relacionen mejor entre sí sin necesidad de forzar algún tipo de conversación artificial.

3.   El Scrum Master guía al equipo para que se organice a sí mismo

Eres el verdadero líder del equipo, el guardián del proceso y el que ayuda a tu equipo a autoorganizarse y autogestionarse. También facilitas la colaboración en equipo, la comunicación clara y el progreso hacia los objetivos del sprint con la ayuda de los artefactos de Scrum.

El Scrum Master sirve como coach para el equipo al garantizar que sus miembros trabajen de acuerdo con la teoría Scrum (por ejemplo, sin multitarea), ayudándolos a prevenir y resolver impedimentos (por ejemplo, deuda técnica) y manteniéndolos enfocados en sus objetivos a través de revisiones periódicas y retrospectivas.

4.   El trabajo del Scrum Master es eliminar los impedimentos, no resolverlos todos

Un Scrum Master extraordinario es un solucionador de problemas y, en general, es una persona analítica. Los mejores pueden ayudar a los equipos a eliminar sus propios impedimentos y a autoorganizarse para que puedan proporcionar valor continuamente. Es importante no confundir el rol del Scrum Master con el de un gerente de proyecto, quien es responsable del resultado de un proyecto en lugar de simplemente facilitarlo. Un Scrum Master extraordinario debe ser hábil para eliminar impedimentos, ¡no para resolverlos todos!

5.   El Scrum Master entiende que no existe tal cosa como "la mejor manera"

El Scrum Master entiende que no existe tal cosa como "la mejor manera". El proceso debe adaptarse al equipo y su entorno. Para adaptarse, él o ella debe ser capaz de aprender cosas nuevas.

Esto significa que no todos los Scrum Masters son iguales. Algunos son mejores en ciertas cosas que en otras. ¡Está bien! Es parte de lo que nos hace a todos tazas de café especiales.

En cualquier caso, el Scrum Master se aleja y aleja a su equipo de quienes vienen con “la mejor manera de hacer esto es…”.

6.   El Scrum Master entiende que cada organización es diferente y necesita un enfoque diferente

El Scrum Master entiende que cada organización es diferente y, por lo tanto, requiere un enfoque distinto. Por ejemplo, si una organización es muy jerárquica y burocrática, la Scrum Master deberá trabajar con la gerencia de la organización para hacerla más ágil. Esto significa ayudarlos a comprender cómo pueden ser más efectivos mediante la adopción de prácticas de Scrum y otras prácticas ágiles, como la eliminación de impedimentos y la mejora de procesos para que el equipo pueda organizarse por sí mismo. Si la organización no tiene demasiadas reglas o regulaciones, entonces podría ser más fácil para el Equipo Scrum autoorganizarse sin necesidad de mucha ayuda de su Scrum Master.

7.   El Scrum Master entiende la importancia de sumergirse en la cultura Ágil a través de aprendizaje, capacitación y experimentación

La cultura ágil es una mentalidad, no solo un conjunto de procesos. Es importante comprender que la cultura ágil no es algo que se pueda aprender en un día. Se necesita tiempo, capacitación y experimentación para convertirse en parte de esta nueva forma de trabajar.

El Scrum Master entiende que la cultura ágil se trata de la mejora continua y no de seguir reglas.

8.   El Scrum Master sabe adaptarse rápidamente a las nuevas circunstancias y cambios en el entorno

El Scrum Master sabe que es un líder servicial y se esfuerza constantemente por crear un entorno en el que el equipo pueda volverse más productivo. El Scrum Master entiende que el éxito depende de tener un equipo motivado y de alto rendimiento, por lo que es responsable de eliminar todo lo que se interponga en el camino del éxito de su equipo.

El papel de un líder servicial es permitir que otros crezcan y tengan éxito. Cuando tu trabajo como Scrum Master está bien hecho, será difícil para ti identificar exactamente cuál ha sido tu contribución porque has estado trabajando entre bastidores para asegurarte de que todos los demás tengan lo que necesitan para hacer su trabajo de manera efectiva.

Como parte de esta dedicación para capacitar a otros, es importante no solo saber cómo, sino también cuándo es el momento de recibir alguna retroalimentación u orientación de asesoramiento o tutoría relacionados con el cumplimiento de los principios o procesos ágiles (también conocido como facilitación).

9.   El Scrum Master entiende que el objetivo de cualquier equipo maduro debe ser la mejora continua

•     Como Scrum Master, debes comprender que el objetivo de cualquier equipo maduro debe ser la mejora continua. El marco de trabajo Scrum está diseñado para ayudar a las organizaciones a lograr este objetivo al alentar a las personas y los equipos a mejorar constantemente sus prácticas de trabajo a través de ciclos de retroalimentación rápidos y cambios pequeños e incrementales.

•     Este concepto se llama Kaizen en la comunidad Lean y Mejora Continua en Ágil. También se conoce como "aprendizaje organizacional" en algunos círculos, porque requiere lecciones regulares de experiencias pasadas, tanto buenas como malas, para que puedan aplicarse para mejorar los resultados futuros o evitar problemas similares en el futuro (en lugar de simplemente arreglar las cosas cuando se rompen).

9 + 1. No tengas miedo de salir de tu zona. ¡Una nueva aventura podría estar a la vuelta de la esquina!

Entonces, eres un Scrum Master y asistes al curso de capacitación para obtener la tan anhelada certificación. Aprendes muchas cosas nuevas sobre Scrum y cómo puedes ayudar a las organizaciones de todo el mundo. El entrenamiento es divertido, pero notas que falta una cosa en tu vida: ¡emoción!

Empiezas a pensar en cómo podrías conseguir algo de aventura en tu vida. ¿Irás a una aventura al aire libre con amigos o familiares y les enseñarás cómo hacer cosas como escalar rocas, saltar de un puente elevado o navegar en kayak? Esto se sentirá como estar de vacaciones porque estás fuera del trabajo por un par de días, pero luego, cuando regreses a casa, ¡podrías tener más energía que antes! ¿Y si esta nueva forma de vivir puede traer alegría a tu vida? ¡Nunca se sabe hasta que se prueba!

Estoy seguro de que sabes que esto es lo que quieres hacer, pero tal vez haya cosas que te detengan. Tal vez has estado trabajando en ti mismo durante años y parece que no puedes progresar. O tal vez eres nuevo en todo esto de "ser un gran líder ágil" y no sabes por dónde empezar. 

Seamos realistas por un segundo: nadie es perfecto. Y el perfeccionismo puede ser paralizante cuando se trata de hacer cualquier cosa, especialmente cuando se trata de ser alguien extraordinario como un Scrum Master o un líder ágil que está listo para asumir cualquier desafío que se presente a continuación.

Inténtalo. Todo gran triunfo empieza con un primer paso. Y dentro de algunas semanas, incluso meses, habrás querido dar ese primer paso hoy mismo.

Conclusión

El Scrum Master es un rol esencial en cualquier organización moderna. El trabajo del Scrum Master es guiar y acompañar a los equipos para que puedan entregar sus productos de manera más efectiva, eficiente y con alta calidad. Eres un líder y los mejores líderes siempre están aprendiendo. Saben que la única forma de liderar verdaderamente es refinando constantemente sus habilidades y ven a su equipo como una plataforma para el crecimiento y el desarrollo.

Como líder, siempre debes trabajar para mejorarte a ti mismo. Nunca debes quedarte quieto y pensar que lo tienes todo resuelto. Siempre habrá más para aprender, así que aprovecha cada oportunidad para ampliar tu base de conocimientos leyendo libros sobre liderazgo, asistiendo a conferencias y seminarios, o realizando programas de capacitación diseñados específicamente para tu función como líder ágil.

Como el próximo curso que facilitaré con Jorge Abad a partir de este 22 de octubre. Encuentras toda la información en:

https://luchosalazar.com/portfolio/nuevo-curso-scrum-master/

También te invito a descargar este póster en alta definición con diez cualidades que te pueden ayudar a convertirte en la mejor versión de Scrum Master que puedas llegar a ser:

http://www.gazafatonarioit.com/2017/05/cualidades-de-un-scrum-master.html

De historias de usuario a historias de persona

 Y una forma más de delimitar y hacer pequeñas las historias de usuario

El problema actual

Dividir historias de usuario se ha convertido en un dolor de cabeza para los practicantes ágiles, principalmente para quienes usan esa técnica como motor para describir las necesidades de los usuarios y las características finales de los productos.

Lo voy a decir de otra forma: en mi trasegar diario con equipos y empresas que acompaño en el uso del enfoque y prácticas y marcos de trabajo ágil, he visto que dividir historias de usuario es algo de lo que todos hablan y tratan de practicar, pero les está costando.

Una de las causas de fondo de todo esto es la subvaloración que se le ha dado a la práctica de historias de usuario. Por ser algo tan sencillo, tan liviano, se estudia con poco detalle, de manera superficial y muy rápido. Los practicantes ágiles apenas si le están dedicando algunos minutos con la creencia de que ya conocen todo lo que deben conocer al respecto. Pero no es así. De ser algo tan simple, pasó a ser algo tan poco entendido y muy mal practicado. Quizás pasa lo mismo que con Scrum, liviano y fácil de entender, pero difícil de llegar a dominar.

Voy a ir más a fondo: el problema no es dividir historias de usuario en sí. Es tener historias de usuario lo suficientemente pequeñas, pero de Valor para el negocio y para el usuario, que se puedan elaborar en muy poco tiempo, desde unas pocas horas, hasta dos o tres días máximo, teniendo en cuenta iteraciones cortas de 10 días. Y cuando digo 2 o 3 días como máximo, me refiero a que la historia queda Terminada, cumple con todos los criterios de aceptación y con todas las condiciones de la Definición de Terminado para las historias de usuario individuales.

Entran las historias de persona

Soy Nancy. Ama de casa. Jubilada hace muchos años. Quiero hacer una transferencia de dinero a mi nieta sin tener que ir al banco. No quiero exponerme a un contagio y ya no tengo fuerzas para esperar de pie haciendo largas colas. Y quiero dedicar mi tiempo a otras labores de la casa.

Quiero hacer la transacción desde mi celular o en el PC de la casa.

Debe ser fácil de realizar porque no soy experta en el uso de estos dispositivos.

Quiero hacerlo de manera segura y rápida. Que no me roben mi platica.

 

Miguel es periodista. Viaja continuamente. Quiere saber cuándo le han consignado sus honorarios y sus gastos de viaje para llevar un control estricto de sus ingresos y gastos.

Miguel quiere recibir información de las consignaciones en su celular, quizás a través de mensajes de texto.

El mensaje debe incluir información sobre el valor de la consignación, el concepto por el cual se hizo y la fecha y hora de esta.

Miguel quiere que nadie más pueda tener acceso a esa información en caso de que se le extravíe el celular.

Aquí hay dos historias de usuario, dos historias, 2 relatos desde el punto de vista muy particular y hasta íntimo de dos personas. Tienen nombre propio, atraviesan vicisitudes específicas, necesidades singulares. Requieren que se cumplan algunas condiciones que consideran valiosas. Estas representan el éxito de su experiencia de cliente usando productos de alguna corporación o empresa. Son historias de persona.

Las historias de persona son concretas, en contraposición a las abstracciones naturales de una historia de usuario que señalan o lidian con, por ejemplo, Amas de Casa, Empleados, Clientes, Jubilados, trabajador autónomo o free lance, entre muchos otros. La misma historia permite conocer qué hace la persona, cómo lo hace, con quien lo hace, qué información intercambia y con quién la intercambia o quién es el receptor de esta. De alguna manera también deja ver sus principales problemas o inconvenientes al hacer lo que hacen. Es como si el equipo de trabajo, incluso los interesados y el mismo Product Owner o Product Manager, lo estuvieran viendo en acción, algo que se ha perdido en las últimas décadas en pro de prácticas que, de distintas manera, impiden el contacto o el acercamiento de quienes hacen productos con los consumidores o usuarios de estos.

Las historias de persona comienzan con la “persona” que originó la necesidad, con nombre y características demográficas únicas. Viene de la práctica User Persona. Esta persona tiene una identidad única y esto delimita el ámbito o el alcance de la historia y, por consiguiente, de la característica del producto que un equipo está forjando. He usado esta técnica en los últimos años y he comprobado que, en general, las historias resultantes son pequeñas, siguen siendo de valor y, efectivamente, se pueden labrar en muy pocas horas o, a lo sumo, en muy pocos días, junto a otras historias en una iteración breve.

Esta es una regla general, por supuesto. Es posible que algunas de estas historias todavía tengan que dividirse aún más para que se puedan trabajar en un sprint corto sin el riesgo visible de que no se puedan terminar junto a las demás.

No es la primera vez que uso el concepto de persona relacionado con las historias de usuario. El primer bloque o nodo de mi User Story Conversation Canvas es sobre las personas. Sobre esto explico que “el equipo debe conocer muy bien el perfil de estas personas, los aspectos personales y profesionales que los identifican, la educación, datos demográficos, sus hábitos e incluso sus motivaciones y comportamientos, lo que les gusta y lo que no. Después de todo desarrollamos productos y servicios para seres humanos. El equipo debe sentir que conoce al usuario”.

El enigma del “usuario” en la historia de “usuario” y cómo resolverlo

Imagen de OpenClipart-Vectors en Pixabay

No me malentiendan. He escrito lo suficiente sobre historias de usuario, incluso he publicado un libro con mi gran amigo Jorge Abad sobre estos menesteres cuya edición en inglés recientemente fue referenciada por la Agile Alliance. No hay un problema de fondo con el usuario en la historia de usuario. Pero conocer más al usuario sí ayuda.

En general, un “usuario” es un concepto abstracto con cierto nivel de vaguedad que se puede automatizar o categorizar para trabajar con él, pero su uso ha mostrado ser de mucha valía en los negocios y en la industria. Un “usuario” describe actividades y responsabilidades de un grupo de individuos. Escribí ampliamente sobre eso en mi libro Asuntos de la Ingeniería de Software, cuando hacía referencia a los Casos de Uso de Ivar Jacobson y a un elemento fundamental de los casos de uso: el Actor. Y un usuario es precisamente eso, un actor. De hecho, decía en una de mis Lecturas Fundamentales, en noviembre de 2006 que “Debemos indagar por las costumbres del actor, su perfil, su experiencia, su conocimiento, el entorno donde se mueve”, nada diferente de lo que estoy diciendo hoy nuevamente, 16 años después.

Un usuario es un rol que se define a través de una tarea o acción concreta o un grupo de funciones con mucha afinidad, que son ejecutadas por personas durante el consumo de un producto o el uso de un sistema. Sin embargo, los usuarios no son algo tan simple como pueden parecer para el practicante ágil inexperto y aún para muchos expertos. Los usuarios pueden llegar a gozar de una ambigüedad tal que vuelven problemática la obtención de historias de usuario pequeñas y de valor. He revisado conjuntos de historias de usuario donde los usuarios exhiben incompatibilidades entre ellos o donde unos tienen sobrecarga de responsabilidades o donde se presenta cierta tensión entre unos usuarios y otros, además de algunas otras tramas inesperadas.

En particular, la ambigüedad es un aspecto destacado para el diseño de productos porque nos muestra una fotografía de la ausencia de precisión que una persona, sus colegas e incluso todos en la empresa pueden llegar a tener sobre los roles y sus responsabilidades. He dedicado más de dos décadas a estudiar este fenómeno y he tenido experiencia de primera mano cuando de usuarios o consumidores y sus responsabilidades o acciones se trata. Por ejemplo, he leído, debatido y ayudado a mejorar decenas de historias de usuario con usuarios como “cliente”, “visitante”, “abonado”, “cliente potencial”, “interesado” o “solicitante” que dicen muy poco o nada sobre el contexto de uso de la historia de usuario y que obstaculizan de distintas formas la división de una épica en historias más pequeñas y trabajables.

Una de las pocas formas que me ha funcionado para resolver todo esto es que todos los interesados en el producto, es decir, el equipo de producto y el equipo de trabajo en pleno vean al usuario en acción. Hay disponer de la logística necesaria, a lo Ojo del Gran Hermano, para que todas estas personas tengan la oportunidad de ver a sus potenciales usuarios o consumidores trabajando. ¿Qué hacen? ¿Cómo lo hacen? ¿Cuándo? ¿Con quién lo hacen? ¿Qué información intercambian unos con otros y quienes de estos también son usuarios y quienes no? ¿Cuáles son sus principales problemas o las dificultades más frecuentes que impactan su desempeño? ¿Cuáles son los criterios de éxito que tienen en cuenta en su accionar habitual?

Resolver estas cuestiones es de suma importancia antes de pensar en la solución que necesitan estos clientes o consumidores.

De vuelta a las historias de persona

Imagen de Gerd Altmann en Pixabay

Hola, soy Mabel, Gerente de Crédito Hipotecario. Quiero un informe de solicitudes de crédito para realizar proyección de aprovisionamiento y trabajar en las próximas campañas con el área de Marketing.

El informe debe ser diario y debo poder clasificarlo por tipo de crédito, pero también quiero tener un resumen por tipo de crédito y la tendencia respecto a los últimos 5 días.

También quiero clasificarlo por tipo de solicitante y tener un subtotal de lo solicitado por tipo de solicitante.

De manera predeterminada quiero ver el informe del día inmediatamente anterior, pero también quiero tener la posibilidad de ver el informe de una fecha anterior.

He estado usando una ligera variación de la forma Davies-Cohn para representar las historias de persona:

Como [usuario] Quiero [esta característica] Para [lograr este beneficio u objetivo]

que puede llegar a ser innecesariamente prolija y repetitiva, aunque muy fácil de entender y de usar en muchos entornos dada la gran difusión y documentación que ha tenido en las últimas dos décadas.

Pero bien podría usar muchas otras grafías para representar historias de usuario. Por ejemplo, puedo usar las historias de usuario estilo BDD, como en:

Registrar datos personales.

Dado que Ibeth, asesora de prensa de la alcaldía, solicitante de crédito de libre inversión, se mantiene muy ocupada en su día a día y tiene poco tiempo para hacer gestiones de manera presencial, ingresó los datos solicitados y existe al menos un dato sin diligenciar. Cuando ella intente enviar los datos, entonces recibirá un mensaje informándole de los datos sin diligenciar y estos datos aparecerán marcados en rojo y no se podrán almacenar los datos, aunque se le permitirá almacenar los datos de manera temporal si ella así lo prefiere.

En conclusión, hay tantas o más formas para representar historias de persona que para representar historias de usuario. Y una vez más, noten amigos lectores que uso el término “representar” como lo he hecho desde hace años, para alejarme y alejarlos de la limitante y problemática expresión “escribir historias de usuario”. Aquel es más abierto, indica que se pueden usar no solo palabras sino también figuras y simbología de distinto tipo que la mente y la imaginación sean capaces de retener. No sobra decir aquí que lo más importante de las historias de persona también es la conversación que se mantenga alrededor de cada una de ellas.

Las personas son instancias de los usuarios. Son ejemplos. Y los ejemplos te ayudan a encontrar inconsistencias en las historias y porque te delimitan un contexto. Pero sobre todo, los ejemplos son buenos porque te ayudan a iniciar conversaciones.

Y bueno, además del innegable beneficio del tamaño (sucinto, en el sentido de pequeño) de las historias de persona, de su contexto concreto e individualizado, otras ventajas de este instrumento derivado son los siguientes:

·       Ayudan a definir un mejor y más aproximado Producto Mínimo Viable, ya que, por naturaleza, estas historias de persona son mínimas y minimalistas, en el sentido de que son esenciales y eliminan o ayudan a eliminar lo que puede llegar a ser superfluo en el producto, es decir, nos ayudan a eliminar desperdicio, a elaborar el producto correcto desde el comienzo.

·       Las personas son, por naturaleza, colaborativas. Cada una usa o consume un producto de una manera diferente, pero entre todas colaboran para que el consumo o utilización del producto se maximice.

·       Ayudan a que quienes se encargan de exponer los productos a sus usuarios, es decir, aquellos que tienen la difícil pero fascinante labor de brindar la mejor experiencia de usuario y de cliente posible, tengan éxito, dado que las personas se conocen mejor, son más concretas, generan más empatía y puedes imaginarlas con una sonrisa cuando el producto las esté ayudando a lograr sus propios objetivos. Las personas nos permiten conectarnos emocionalmente con ellas, los usuarios abstractos quizás no.

·       Las historias de persona ayudan a iniciar y a mantener conversaciones más fluidas y verosímiles que las historias de usuario. Incluso nos permiten crear otras personas (personajes de la historia) para los eventos alternativos de la historia o para los procesos de manejo de excepciones en esta.

·       Las personas son más imaginables o creíbles o comprensibles que los usuarios porque tienen un rostro y un nombre y una identidad.

Llamado a la acción

Finalmente, te invito a que uses este modelo de historia, de historia de persona. Eso sí, cuéntame y cuéntanos cómo lo podemos extender y practicar mejor. Y no dejes de contactarme con cualquier inquietud que tengas respecto a este o a cualquiera otra inquietud sobre las historias, sean de usuario o de persona.

La dimensión desconocida de las transformaciones ágiles (#Agiles2022)

 

En el pasado Ágiles Latinoamérica 2022 (#Agiles2022) en Armenia, Colombia, tuve la oportunidad de conducir una sesión sobre transformaciones ágiles.

La llamé La dimensión desconocida de las transformaciones ágiles y fue más que todo una conversación con los asistentes sobre este asunto de cómo abordan o cómo están afrontando las empresas actuales esto del cambio organizacional y cultural.

Específicamente, la transformación ágil.

El punto de partida fue precisamente esto de la “instalación de la agilidad” como un paquete (de software). Los líderes organizacionales quieren que el cambio ocurra en “un dos por tres”, muy rápido, con mínimo esfuerzo y esto es simplemente un imposible.

Entonces presenté en primicia mundial este “instalador” de agilidad, a la mejor usanza de un paquete tipo ERP pero para agilidad y Lean y muchas de las prácticas y conceptos que giran alrededor de estos.

Muchos me han preguntado que si hay un video de la charla, no lo hay, fue una conversación amena, donde también participó mi gran amigo Jorge Abad, con quien facilité otras sesiones en el evento. Pero lo que sí tenemos es un video del instalador, aquí se los dejo.

Algunos otros aspectos de los que hablamos en la sesión fueron:

El Manifiesto por la transformación frágil, una suerte de antimanifiesto que abstrae la realidad de cómo estamos ayudando a las organizaciones con sus programas de cambio y cuyo contenido encuentras en:

http://www.gazafatonarioit.com/2019/01/algunos-errores-comunes-que-estan.html

Finalmente, algunas conclusiones, a manera de cosecha:

Las empresas exitosas no hablan de #agile o #scrum, ¡simplemente lo hacen!

Y mientras muchos #coaches y empresas se enfocan en #frameworks, roles y nuevos procesos, quienes quieren alcanzar el éxito saben que todo comienza con las #personas.

“Si deseas una cultura ágil con alta autonomía e innovación, debes contratar para ello. Los grandes líderes contratan a los grandes talentos, los grandes talentos permiten una gran cultura”.

Las personas y la #cultura no son una ocurrencia tardía, son la BASE de la agilidad. Todo lo demás se basa en esto (o se desmorona, si no tienes la gente y la cultura).

Pero si contratas personas principalmente por sus habilidades o para obedecer órdenes, ninguna cantidad de Scrum, Kanban, Scrum@Scale o SAFe te ayudarán.

¡Como #AgileCoach sé que todo comienza con las personas y la cultura! Aquí es donde debe comenzar la transformación.

 

¿Estuviste en el #Ágiles2022 en Armenia? ¿Qué te pareció? Por favor, déjamelo saber en el foro.

English Version 

I leave here the English version of the installer.

Apuntes sobre transformaciones ágiles IV: los expertos en agilidad, la resistencia al cambio y el pensamiento generativo

 

Image by Gerd Altmann from Pixabay 

Algo debemos estar haciendo bien.

Hace una década, los estudios de adopción ágil decían que la cultura organizacional de entre 6 y 8 de cada 10 empresas estaba en oposición a los valores y principios ágiles. Hoy ese número ha descendido hasta 4 de cada 10, según el último reporte del estado de agilidad.[1] De hecho, en el reporte del estado de adopción de agilidad, más significativo para Latinoamérica dado que alrededor del 75 % de los encuestados somos de esta región, este número bajó del 34 % al 12 % en 2022.[2]

Pero todavía falta.

Hoy por hoy, muchas empresas consideran el cambio organizacional, sobre todo este de la transformación al enfoque ágil, como un proyecto que los lleva de un estado A o punto inicial a un estado B o punto final. Eso está bien. Al menos para empezar. Lo que conocen la mayoría de las empresas es la gestión por proyectos y en principio no hay que atribular a sus líderes con cosas más allá de lo conocido.

Pero rápidamente debemos ayudar a que eso cambie. Ayudarles de distintas maneras a que entiendan que el cambio es un proceso continuo y lo que buscamos con él es alinear y realinear a la organización a un entorno en constante cambio. Un Líder Transformacional sabe que la empresa debe estar en un estado de Emergencia Ágil todo el tiempo.

Entran los expertos en agilidad

Image by Gerd Altmann from Pixabay 

En general y, en el mejor de los casos, estas organizaciones trabajan con compañías consultoras a las que acuden para contar con ayuda experta en los temas que los angustian. Normalmente, estos expertos llegan investidos de un aire de pericia y con habilidades novedosas para la organización.

Diestros en pensamiento ágil, maestros en pensamiento Lean y Kanban, consejeros en liderazgo y cambio, coaches y mentores empresariales ágiles, especialistas en marcos de trabajo y modelos como Scrum, Nexus, LeSS, SAFe, Scrum@Scale, UnFix, Spotify, Design Thinking y otros “Design”; Senséis de los OKR, los VSM (Value Stream Maps), el feedback transparente y continuo, y de las mejores retrospectivas; y hasta guías espirituales. Clasificados por niveles de experiencia: ultra seniors, semi seniors, juniors y aprendices.

Estos expertos llegan enumerando a diestra y siniestra todos los modelos de gestión del cambio conocidos y otros no tan conocidos: la organización empieza a escuchar apellidos como Kotter y siglas como ADKAR, reencauchados pero que siempre vienen bien, como Drucker, modelos como LCM (Lean Change Management) y técnicas como Management 3.0, junto con un sinnúmero de ideas, prácticas, propuestas y formas de hacer las cosas preplanificadas aún antes de tocar las puertas organizacionales.

No son recetas, anuncian, pero sí lo son.

Muchas veces, esos expertos en agilidad llegan de compañías que no practican lo que predican. Empiezan a hablar de aplanar la organización y de trabajo en redes, de manera colaborativa, pero vienen de un silo en su propia empresa, la misma cuya estructura está lejos de ser considerada como plana o donde se puedan registrar comportamientos de trabajo en clanes o de adhocracia, y donde muchas veces nadie más los conoce. Otras veces llegan de consultoras que están muy distanciados de conocer los problemas diarios de sus clientes.

La gran receta de cambio, anuncian a los cuatro vientos empresariales, es entonces:

1.    Reconocer o definir el problema a resolver

2.    Analizar y diagnosticar (los infames assessments)

3.    Identificar posibles soluciones por parte de los expertos

4.    Plasmar y ejecutar un plan de acción

Con los consabidos objetivos de:

·       Disminuir el time-to-market

·       Mejorar el clima laboral

·       Reducir los desperdicios en los procesos

·       Aumentar el RoI

·       Alinear las áreas de TI con el negocio

Entre tantos otros. Incluso, en los últimos años, todo esto está cubierto del manto de los OKR. OKR para esto y OKR para lo otro. OKR para la estrategia y OKR para la operación. OKR para los equipos y OKR para las personas. Y más.

Soy John Connor: si estás leyendo esto, eres de la resistencia

Image by Gerd Altmann from Pixabay 

Durante la última década he estado en muchas de esas posiciones de las que hablo. Soy de esos consultores “expertos” que van por las empresas con buenos deseos de aportar algo al mejoramiento de estas. Y he llegado a una conclusión perentoria:

Los modelos planificados y preparados de cambio suscitan resistencia.

Lo sabíamos hace mucho: las personas no batallan, al menos no mucho, cuando de usar prácticas ágiles se trata, por eso se les da muy bien el Scrum y el SAFe y los OKR y todas esas. Pero las personas sí libran una guerra “fratricida” contra el cambio de mentalidad. La amígdala cerebral hace aquí su trabajo muy bien hecho y genera un temor que muchas veces es incomprendido, pero natural. Es un miedo cuyo propósito es la supervivencia laboral, por decirlo de alguna manera. La amígdala logra o ayuda a que las personas eviten situaciones, otras personas, objetos o aspectos que pongan en riesgo máximo su estabilidad profesional, económica, social y su salud.

Los expertos en agilidad también llegan con la vacuna antiresistencia, en una o dos dosis, con miras a una dosis de refuerzo más adelante. Entonces hablan de la curva de innovación de Rogers y de los conservadores y ultraconservadores (mayoría tardía y rezagados) en la empresa y qué hacer con ellos a continuación. Pero muchas veces, los expertos no alcanzan a detectar, mucho menos a ver, esta resistencia como una retroalimentación a gritos por parte de los involucrados. De hecho, algo que ocurre mucho en las iniciativas de cambio es que los ciclos de retroalimentación son extensos o no se presentan del todo.

Sí, también nos da miedo la retroalimentación.

Finalmente, en los entornos complejos y altamente complejos que caracterizan las organizaciones en las que trabajamos habitualmente, los desafíos están desbordados de alta incertidumbre y ambigüedad, de falta de precisión. En estos ambientes, las soluciones a esos retos emergen vía experimentación. Hay que establecer una hipótesis, realizar un experimento y analizar los resultados en retrospectiva. Y esto hay que hacerlo de manera frecuente, implacablemente.

Entran el pensamiento generativo y el triple impacto

Image by Gerd Altmann from Pixabay 

Algo que he aprendido en la última década es que los procesos de cambio requieren primero de una TPP o transformación personal profunda. Esta TPP requiere de adquirir atributos o especias que nos permitan a cada uno de los líderes del cambio y a cada uno de los líderes de la organización y quizás a cada persona de esta comenzar a producir ideas generativas, a tener un pensamiento emergente, uno cuya capacidad de originarse sea cruda pero flexible, un pensamiento que a su vez habilite nuevas formas de pensar y de hacer las cosas, incluso que genere emociones, información y conocimiento de manera frecuente. Esto hará que germinen formas novedosas de cultura.

Junto a este pensamiento generativo, bien puedes tener en cuenta las siguientes recomendaciones:

1.    Los expertos están allí para proporcionar y facilitar espacios de diálogo entre las personas y equipos comprometidos con el cambio, no para realizar el cambio en sí mismo. Hasta tanto ellos mismos no se comprometan, más que involucrarse, o hasta tanto no formen otros expertos internos a la organización, no estarán haciendo bien su trabajo desde el exterior. Y eso no ocurrirá hasta tanto no conozcan en detalle la cultura organizacional, la forma de hacer las cosas en los distintos niveles corporativos y los innumerables escenarios que sirven de atmósfera a las tareas diarias en la empresa.

2.    Acorta los ciclos de retroalimentación, tanto como a todos los días. Estos ciclos no deben ser más extensos que unos muy pocos días de trabajo. Interioriza, practica y promueve una cultura de feedback efectivo y frecuente. De hecho, en vez de “retroalimentación”, promueve en tus equipos las conversaciones de mejora. Estos son diálogos donde la información se transmite de tal forma que recaiga sobre la huella que deja el comportamiento del otro en el objetivo trazado y en ti mismo, y donde esa información se comparte sin juicios.

3.    Ya lo dije. Pero insisto. El experimento y la experimentación implacable son el camino en entornos VUCA/BANI y lo que venga al respecto en el futuro próximo. La complejidad de los problemas y de los eventos que ocurren en una organización cuya base de trabajo es el conocimiento es extremadamente alta. Déjenme repetirlo con un sinónimo: la complejidad inherente a las empresas de conocimiento es considerablemente alta. Y por ello, para resolver cualquier cosa, para sobrepasarlos, se hace necesario una mentalidad diferente, un pensamiento adaptativo que incluya el Trabajo Conducido por Hipótesis (TCH), uno donde continuamente se establezcan hipótesis y se conduzcan experimentos que prueben esas hipótesis o las refuten. Esto es promover una cultura proclive al ensayo y al error, una cultura donde estos últimos incluso tengan sus quince minutos de fama.

4.    Siempre hablamos de interiorizar, practicar y promover comportamientos que en el mediano plazo, y más en el largo plazo, empiecen a cambiar la cultura de la empresa. En este contexto, promover significa hacer viral esos comportamientos, es decir, viralizar la cultura. Difundirla. Distribuirla a todos los rincones de la organización. Lograr que cada ser humano que trabaja en, que entrega algo a, o que recibe algo de la empresa, respire el mismo aire cultural, en distintos tonos, colores y sabores, pero bajo el mismo manto al fin y al cabo, el manto de la cultura.

Advertencia: es muy posible que en el camino hacia esa nueva cultura, tengas que exigirla de alguna manera. Eso sí, nunca, antes de haberla demostrado con ejemplos y más ejemplos y de haberte asegurado de que los demás la hayan entendido.

5.    Hoy, ningún proceso de cambio será efectivo ni contribuirá al desarrollo personal, profesional y motivacional de los integrantes de una empresa y de sus clientes, si no tiene en cuenta el triple impacto de las organizaciones Brillantes. Para una transformación auténtica, una que encauce el propósito superior de la empresa no solo hacia lo financiero, sino también hacia lo social y lo ambiental, los agentes de cambio y los líderes transformacionales deben sembrar el gen que recodifique la organización con un ADN cuya doble hélice esté constituida por la adaptabilidad y el pensamiento generativo. Si no piensas en el beneficio social y ambiental, y te quedas solo en el necesario fruto económico, es muy probable que el cambio que quieras originar no tenga trascendencia más allá de los límites de la empresa.

En este sentido te invito a conocer más del LBAM o Lean Business Agility Model, un modelo creado por mi gran amigo Jorge Abad [3] y en cuyo desarrollo he colaborado. El LBAM es un modelo simplificado que reúne en una única perspectiva la agilidad a nivel estratégico, táctico y operativo; también, la agilidad en los equipos transversales y de soporte; la Mentalidad Lean-Agil, el Liderazgo Transformacional y de Crecimiento soportando todas las funciones y áreas de la organización, con foco en el cliente, como la mayor obsesión de todos en la empresa. [4]

Es definitivo: “Un negocio saludable no puede existir en una sociedad enferma”.[5]

Como siempre, no dejes de contarme en el foro cómo te va con todo esto.

Referencias

[1] 15th Annual State Of Agile Report. 2022. digital.ai.

https://digital.ai/resource-center/analyst-reports/state-of-agile-report

[2] Agile Adoption Report 2021. 2022. Certiprof.

https://certiprof.com/pages/certiprof-agile-adoption-report-2021

[3] Nuevas Aguas, Nuevos Navíos, Nuevos Navegantes: Business Agility con notas sobre Transformación Digital. 2022. Jorge Abad.

http://www.lecciones-aprendidas.info/2022/07/zarpamos-ya-esta-disponible-mi-nuevo-libro-nuevas-aguas-nuevos-navios-nuevos-navegantes-business-agility-con-notas-sobre-transformacion-digital.html

[4] Lean Business Agility Model. 2022. Jorge Abad y Lucho Salazar.

http://www.gazafatonarioit.com/2022/09/lean-business-agility-model.html

[5] Drucker Report 2020 * Drucker Institute. 2020. La frase fue escrita por Peter Drucker en 1974. “A healthy business, a healthy university, a healthy hospital cannot exist in a sick society.”

Sobre los apuntes anteriores

I. Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio

http://www.gazafatonarioit.com/2018/04/apuntes-sobre-transformaciones-agiles_1.html

II. Apuntes sobre transformaciones ágiles: las personas, sus miedos y qué hacer al respecto

http://www.gazafatonarioit.com/2018/07/apuntes-sobre-transformaciones-agiles.html

III. Apuntes sobre transformaciones ágiles: lo bueno, lo malo y lo feo

http://www.gazafatonarioit.com/2020/10/apuntes-sobre-transformaciones-agiles.html