La Sala Obeya: Gestión visual y colaborativa de proyectos

La Sala Obeya es una herramienta para la gestión visual de proyectos usada en la cultura Lean. Obeya se refiere a un espacio físico o digital, donde se visualiza información clave del proyecto, con el propósito de facilitar la comunicación, colaboración y toma de decisiones con agilidad.

Sala Obeya, que en japonés significa Sala Grande, tiene su origen en Toyota, y fue implantada con la primera generación del Prius en la década de 1990.

Imagen tomada de: https://institutolean.co/obeya-room-trabajando-juntos-en-la-misma-direccion/

Se ha implementado bajo diferentes denominaciones, tales como: “Cuarto de guerra” o “War Room”, “Big Room”, “Salón de programas”, “Sala de control”, “La sala de pulso”, “Sala de trabajo”, “Sala de reuniones”, “Discovery Room”, “Sharing Room”, “Sala de flujo de trabajo”, “Sala de gestión visual”, entre otras.

Una forma de organizar la información del proyecto en una Sala Obeya es siguiendo la estructura del Ciclo de Deming PDCA, disponiendo en distintas “paredes” información sobre la Planificación del proyecto, su Ejecución (Do), Verificación y Actuación.

Cada equipo decide qué información necesita en la Sala Obeya, y que eventos periódicos realizar para su evaluación y mejora.

Por ejemplo, para un proyecto Scrum:

Pared	Información	Eventos
Planificación (Plan)	· Básica del proyecto: Nombre, descripción,   objetivos, alcance general, entre otros ·  Fecha inicio y fecha fin ·  User Story Mapping ·  Equipo de Trabajo ·  Plan de entregas (MVP y otros releases)	Revisión de la Planificación   Mensual
Ejecución (Do)	·  Sprint activo ·  Puntos de atención ·  Alertas de interés para el equipo	Dailies   Diario
Verificar (Check)	·  Métricas del proyecto ·  Velocidad media del equipo ·  Porcentaje de predictibilidad del equipo ·  Evolución del proyecto	Verificación mensual   Mensual
Actuar (Act)	·  Tareas de mejora continua ·  Tareas bloqueadas ·  Registro de riesgos	Actuar para mejorar   Mensual

Para construir y operacionalizar una Sala Obeya, se debe considerar:

1. Seleccionar la plataforma tecnológica donde funcionará la Sala Obeya (PowerBI, Confluence, Jira, Teams, Sharepoint, etc).
2. Determinar que mecanismos de seguridad se necesitan implementar para el control de acceso a la Sala Obeya.
3. Establecer el Alcance y el MVP que facilitará la validación y evolución del concepto.
4. Realizar un plan preliminar de trabajo que incluya el diseño, maquetación, interfases, desarrollo, pruebas y puesta en producción.
5. Desarrollar la Sala Obeya utilizando un marco de trabajo ágil.

María Esther Remedios

Ig @Soy.Agile.Coach

¿Qué es Agile 2?

Tras 20 años del movimiento Agile, surgido formalmente con el Manifiesto ágil en el año 2001, son muchas las lecciones aprendidas, y ya se evidencia la necesidad de pivotarlo, adaptando y enriqueciendo los valores y principios de la agilidad.

Un equipo de expertos agilistas ha creado Agile 2, cuyos análisis y propuestas se resumen en la página https://agile2.net/, la próxima iteración de Agile.

Desde mi punto de vista, Agile surge como un MVP que ha dado a las organizaciones la libertad de iterar y evolucionar la agilidad acorde a sus necesidades, contexto y criterios propios, y como en todo proceso empírico, la experimentación deja resultados que necesitan ser revisados para ser cambiados o para ser incorporados como mejores prácticas que seguirán evolucionando dentro de la cultura de la mejora continua.

Agile 2 propone evolucionar los valores y principios del manifiesto ágil, a fin de incorporar nuevos elementos que fortalezcan la fundamentación de los marcos de trabajo, cuyo fin último es apoyar a las organizaciones y equipos de trabajo en la resolución efectiva de sus problemas y en el logro de sus metas y objetivos.

Entre los cambios destacados, en materia de Valores, Agile 2 propone nuevos valores en un equilibrio donde éstos se complementan, incorporando factores clave como el Liderazgo y la importancia de las personas además de los equipos:

Valores Agile	Valores Agile 2
Aunque valoramos los elementos de la derecha, valoramos más los de la izquierda	Valoramos todas estas cosas y nos esforzamos por equilibrarlas o combinarlas para cada situación.
1. Individuos e interacciones sobre procesos y herramientas 2. Software funcionando sobre documentación extensiva 3. Colaboración con el cliente sobre negociación contractual 4. Respuesta ante el cambio sobre seguir un plan	1. Consideración y prescripción 2. Resultados y productos 3. Particulares y equipos 4. Comprensión empresarial y comprensión técnica 5. Empoderamiento individual y buen liderazgo 6. Adaptabilidad y planificación

En el campo de los principios, Agile 2 los amplia y estructura en 10 áreas:

Principios Agile

Principios Agile 2

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.   4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.   ­7. El software funcionando es la medida principal de progreso. 8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

1. Planificación, transición y transformación -    Cualquier iniciativa requiere tanto una visión u objetivo como un plan flexible, orientable y orientado a resultados. -    Cualquier transformación significativa es principalmente un viaje de aprendizaje, no simplemente un cambio de proceso. -    El cambio debe venir desde arriba. -    El desarrollo de productos es principalmente un viaje de aprendizaje, no simplemente una "implementación". 2. Producto, cartera y partes interesadas -    Obtener comentarios del mercado y las partes interesadas de forma continua. -    La única prueba de valor es un resultado comercial. -    Trabajar de forma iterativa en pequeños lotes. -    El diseño del producto debe integrarse con la implementación del producto. -    Crear documentación para compartir y profundizar la comprensión. -    Quienes ofrecen productos y servicios deben sentirse responsables ante sus clientes por el impacto de los defectos. 3. Datos -    Los datos tienen un valor estratégico. -    El modelo de información de una organización es estratégico. -    Recopile y analice cuidadosamente los datos para la validación del producto. 4. Marcos y metodologías -    Adapte un marco ágil a su trabajo, su cultura y sus circunstancias. -    Las organizaciones necesitan un "marco inicial" adaptado a sus necesidades. 5. Dimensión técnica y fluidez técnica -    La agilidad técnica y la agilidad empresarial son inseparables: no se puede comprender una sin comprender también la otra. -    Los líderes empresariales deben comprender cómo se crean y se entregan los productos y servicios. -    El liderazgo en la entrega de tecnología debe comprender la entrega de tecnología. -    Los equipos y el liderazgo en la entrega de tecnología deben comprender el negocio. 6. Individualidad vs. Equipo -    Todo el equipo resuelve todo el problema. -    Fomentar la diversidad de comunicación y la diversidad de estilos de trabajo. -    Los individuos importan tanto como importa el equipo. -    Tanto los especialistas como los generalistas son valiosos. -    Las diferentes certificaciones Agile tienen un valor desigual y requieren un escrutinio. 7. Equipo v. Organización -    Favorecer los flujos de entrega de extremo a extremo, en su mayoría autónomos, cuyos equipos tienen autoridad para actuar. -    Fomentar la colaboración entre equipos a través de objetivos compartidos. -    Favorecer a los equipos de larga duración y convertir su experiencia en una ventaja competitiva. 8. Mejora continua -    Ponga límites a las cosas que causan arrastre. -    Integrar temprano y con frecuencia. -    De vez en cuando, reflexione y luego promulgue el cambio. -    No comprometa completamente la capacidad. 9. Enfoque -    Respetar el flujo cognitivo. -    Facilitar a las personas la participación en un trabajo centrado e ininterrumpido. -    Fomentar intercambios profundos. 10. Liderazgo -    El factor de éxito más impactante es el paradigma de liderazgo que la organización exhibe e incentiva. -    Proporcionar un liderazgo que pueda empoderar tanto a las personas como a los equipos, y establecer la dirección. -    Escala de modelos de liderazgo. -    Los modelos organizativos de estructura y liderazgo deben evolucionar. -    Los buenos líderes están abiertos. -    Un equipo a menudo necesita más de un líder, cada uno de un tipo diferente. -    La autoorganización y la autonomía son aspiraciones y deben darse de acuerdo con la capacidad. -    Validar ideas a través de pequeños experimentos contenidos. -    El desarrollo profesional de las personas es fundamental.

 

Muchas empresas han complementado Agile con prácticas DevOps, Lean, Kanban, Management 3.0, incluso han integrado la agilidad a la gerencia de proyectos y al uso de datos estadísticos, métricas e indicadores para medir desempeño y éxito.

Estoy de acuerdo en fortalecer la agilidad con estos nuevos valores y principios, pero considerar que Agile ha sido un fracaso o que necesita un nuevo comienzo, en mi opinión, no es cierto en todos los casos, y que en todo caso dependerá de la madurez agile en que se encuentre la organización.

¿Y tú que opinas? Te leo en los comentarios.

Gracias

Ig @Soy.Agile.Coach

#Agile, #Agile2, #AgileCoach, #ScrumMaster, #ManifiestoAgil

La Maestría Técnica del Agile Coach

Entre las competencias del agile coach, y del Scrum master, destaca la maestría técnica, especialmente importante cuando se trata de equipos que trabajan con productos de tecnología.

La maestría técnica nos permite conectar con los retos y oportunidades del equipo de trabajo, participar en conversaciones donde se tratan los problemas de arquitectura, seguridad, plataformas, calidad del software, automatización, etc. No digo que tengamos que ser especialistas en cloud, phyton o java, o dominar las herramientas de integración continua y de automatización de pruebas, pero si tener el conocimiento necesario para comunicarnos efectivamente con el equipo.

Con esta competencia, ayudamos al equipo a cumplir con el noveno principio del manifiesto ágil: La atención continua a la excelencia técnica y al buen diseño mejora la agilidad, y como se afirma en el marco de escalado LeSS: La agilidad organizativa está limitada por la agilidad técnica.

Algunas técnicas que favorecen la excelencia técnica son:

• Lean Code: es código limpio que funciona (Ron Jeffries), está bien estructurado, tiene un propósito claro, sigue buenos principios de diseño y es fácil de entender y de mantener. Es una filosofía de diseño de desarrollo de software que enfatiza la simplicidad, la eficiencia, la flexibilidad y la accesibilidad.
• Deuda Técnica: préstamo que nos permite avanzar y aprender rápidamente (Ward Cunningham), y luego se paga refactorizando el código para que refleje el conocimiento adquirido.
• Pair Programming: especifica que siempre haya dos personas trabajando al mismo tiempo en el código y que, en la medida de lo posible, se sienten juntas. Una se encarga de escribir el código y la otra de supervisarlo en tiempo real. Al mismo tiempo, están constantemente intercambiando impresiones: debaten problemas, encuentran soluciones y desarrollan ideas creativas.
• Costo del Cambio: es común asegurar que corregir un error se vuelve exponencialmente más costoso mientras más tarde se detecte. Beck (XP) sugiere que, con una buena combinación de tecnologías y prácticas de programación, la curva puede achatarse, manteniendo el costo de cambio bajo. Si incorporar funcionalidad se volviese cada vez más costoso, difícilmente podríamos mantener la agilidad.
• Testing automatizado: que permiten tener la mejor velocidad posible, desarrollar en forma sostenible y disponer de una buena documentación del sistema.

Más allá del software, también hay que velar por la excelencia técnica del producto y del negocio, recurriendo a técnicas como la investigación de mercado, el benchmarking, experiencia de usuario (UX), data análisis, gestión de riesgos, etc.

Marcos de trabajo como Scrum y Kanban, son menos prescriptivos y se adaptan a diferentes tipos de proyectos y servicios. En otros marcos más orientados al mundo del desarrollo del software, encontramos prácticas técnicas específicas, como en: eXtreme Programming (XP), Lean Software Development (LSD), Test-Driven Development (TDD), Feature Driven Development (FDD), Agile Unified Process (AUP), Adaptive Software Development (ASD), Crystal Clear, Dynamic Systems Development Method (DSDM), entre otros.

Conocer sus técnicas nos permite enriquecer otros marcos de trabajo, y como les compartí en el artículo Scrum, Kanban, XP ¿Hay uno mejor? ¿Se pueden combinar?, cuando implementamos por ejemplo Scrum en desarrollo de software, es muy recomendable integrar prácticas de la ingeniería como TDD o Pair Programming para asegurar la excelencia técnica.

Déjame saber tu opinión en los comentarios.

Gracias por leerme

Ig: @Soy.Agile.Coach

Scrum, Kanban, XP ¿Hay uno mejor? ¿Se pueden combinar?

Cuando las organizaciones deciden ser ágiles y lean, además de una iniciativa de transformación y gestión del cambio, necesitan decidir cuál, o cuáles, marcos de trabajo ágiles van a implementar en sus equipos de trabajo. Ante las diferentes opciones, quizás se pregunten ¿hay uno mejor?, y la respuesta, como es usual, será depende del contexto.

Los marcos de trabajo ágiles tienen un propósito común: facilitar prácticas basadas en los valores y principios ágiles y lean, en las áreas que precisan de rapidez y flexibilidad, fomentando el aprendizaje, la mejora continua y la capacidad de responder de forma ágil a los cambios del contexto.

Conocer los fundamentos de los marcos ágiles nos permite usar el que mejor ayuda al equipo de trabajo a conseguir productos, proyectos o servicios de alta calidad.

Cabe destacar, que el primer valor del Manifiesto Ágil es "Individuos e interacciones sobre procesos y herramientas", por lo que los métodos ágiles son adaptables, y vamos a encontrar que hay marcos más prescriptivos y otros más adaptativos. Dependiendo del contexto y el propósito de cada equipo, se apreciará el disponer de unas determinadas prácticas.

Por ejemplo, XP (eXtreme Programming) es más restrictivo en comparación con Scrum, dado que incluye las prácticas de Scrum más un conjunto de buenas prácticas específicas de la Ingeniería del Software, tales como Desarrollo Dirigido por Pruebas (TDD) y la Programación en parejas (Pair Programming). Scrum es más restrictivo que Kanban ya que prescribe el uso de iteraciones de duración fija (sprints) y roles, mientras que Kanban no lo hace.

Cada equipo debe ser capaz de seleccionar y/o adaptar un subconjunto adecuado de prácticas para su producto, proyecto o servicio, pero esto será difícil en un inicio, por lo que en agile sugerimos seguir el modelo Shu-Ha-Ri, donde en una primera etapa el equipo aprende y aplica las prácticas de acuerdo a los procedimientos de trabajo establecidos (Shu), en la segunda etapa el equipo, en búsqueda de la mejora continua, va experimentando y adaptando las prácticas iniciales (Ha), y en la tercera etapa, donde el equipo ha madurado la comunicación e interacción, será capaz de crear sus propias prácticas y combinar las propuestas en los distintos marcos ágiles.

Esto nos lleva a reflexionar sobre la segunda pregunta: las prácticas de los diferentes marcos ¿se pueden combinar?, y la respuesta, desde mi opinión, es que Sí, aunque existen ciertos límites.

Hace algún tiempo publiqué un artículo sobre Scrum y Kanban juntos en Agile: Scrumban, desde la perspectiva de un equipo que evoluciona un producto donde se gestionan incidencias, peticiones de soporte y evolutivos.

Más allá de los nombres, me parece más que apropiado, conveniente, integrar prácticas de un marco en otro dominante. Por ejemplo:

· Scrum con Kanban, donde puede incorporarse en el Scrum Board un WiP que ayude al equipo a enfocarse en terminar más rápido las tareas actuales. Scrum.org tiene una certificación de Scrum profesional con Kanban y un conjunto de recursos que incluye una guía de Kanban para equipos Scrum: https://www.scrum.org/resources/suggested-reading-professional-scrum-kanban.

· Kanban con Scrum, donde puedes implementar Dailies que favorezcan la sincronización y colaboración en los miembros del equipo, o decidir priorizar el trabajo de las columnas y tener ciclos periódicos de feedback, tal como lo propone Scrum.

· Scrum con XP, aplicado al desarrollo de software, puede integrar prácticas de la ingeniería cómo Pair Programming para elevar la calidad del código.

Para evitar confusiones, los marcos suelen tener algunas de sus restricciones menos negociables. No podrás llamar Scrum a un método de trabajo sin sprints, ni Kanban a un método que no gestione la eficiencia del flujo de trabajo.

Cabe destacar, que los marcos son medios y no fines en si mismos, y que, en todo caso, son métodos empíricos, por lo que la experimentación y adaptación serán la base de la mejora continua.

Me interesa conocer tu opinión. ¡Muchas gracias!

Ig: @Soy.Agile.Coach


#Scrum, #Kanban, #XP, #Scrumban, #MarcosAgiles, #Agile, #Lean, #AgileCoach, #ScrumMaster, #Empírico, #Experimentación, #Adaptación.

La parte Coach del Agile Coach

Hace algo más de dos años, escribí sobre el Agile Coach: Nuevo rol y competencias en el Agilismo. En general, un Agile Coach es un especialista en Agile con competencias de un Coach profesional.

Muchos de nosotros venimos del área técnica, con roles como gerente de proyectos, líder técnico, analista de sistemas, desarrollador de software, QA, etc. Hemos aprendido y experimentado la agilidad, volviéndonos expertos en sus marcos de trabajo y prácticas ágiles, incluso asimilando sus valores y principios, logrando un mindset agile.

Un agile coach es un agente de cambio, un profesional que ayuda a las personas, equipos y organizaciones en su proceso de transformación agile. Esto significa que necesita ser un buen Coach. Compartiré algunas ideas de qué ha significado ser Coach para mí.

1. Fortalecer una mentalidad progresista, optimista, paciente, enfocada, aprendiendo de los errores, manteniendo una alta autoestima que inspira confianza, pero sin arrogancia.
2. Comprender a las personas, respetar las diferencias, ser empático y desarrollar estrategias para conectar, motivar, transmitir y mantener conductas que sirvan de ejemplo.
3. Usar métodos y herramientas vanguardista, y con un pensamiento sistémico, apoyar los procesos de cambio con lo mejor del mercado, facilitando el desarrollo y aceleración de los resultados. Esto nos exige mantenernos en continua actualización.
4. Aplicar las etapas del coaching, donde en una etapa inicial hacemos un diagnóstico y acordamos los objetivos del cambio deseado, en la segunda etapa damos formación, acompañamiento y seguimiento a la evolución del proceso, hasta la etapa final, donde evaluamos juntos los logros y avances. No olvidar que nuestro rol siempre es temporal.
5. Utilizar herramientas de coaching, tales como: preguntas, plantillas, gráficos y dinámicas que nos ayuden a recopilar información y generar reflexiones y aprendizajes en las personas y equipos con los que trabajamos el cambio.
6. Aprender que el coaching va por niveles, facilitando cambios progresivos, comenzando con el nivel de remediación que impacta comportamientos, siguiendo con el nivel generativo para cambiar creencias y valores, y llegar al nivel evolutivo que transcienden a la identidad, misión y propósito, el fin último del proceso de transformación.
7. Comprender que la motivación es la base del cambio, y que en un inicio puede haber personas Inconscientemente incompetentes, que son ignorantes de los nuevos retos y oportunidades que se avecinan; al darles formación pasan a ser Conscientemente incompetentes, donde la resistencia y el temor hacen que la motivación baje; el agile coach busca mantener el enfoque y crear disciplina, y con mucha práctica lograr que las personas sean Conscientemente competentes, hasta que logramos el cambio de mindset  y de hábitos que hacen que las personas sean Inconscientemente competentes, alcanzando el verdadero cambio.
8. Caminar las etapas de un proceso de cambio con la organización, reconociendo que cambiar el status quo comienza con uno o más eventos detonadores que generan resistencia y caos, hasta que conseguimos integrar los cambios y alcanzar un nuevo status quo.
9. Facilitar el aprendizaje es diferente a enseñar, propiciando un entorno con dinámicas y conversaciones que promueven la mejora continua y el incremento del desempeño.
10. Desarrollar actitudes y hábitos esenciales en el coaching como lo son: no juzgar, no opinar, escuchar atentamente, promover que el equipo hable, cuidar las palabras, ser espejo, etc.
11. Formular buenas preguntas que incentiven el aprendizaje, evolución y consecución de los objetivos, que promuevan la conversación, reflexión y el debate, evitando sugerir respuestas o preguntas cerradas que inhiban la expresión abierta de las ideas.
12. Autoevaluar frecuentemente nuestro ADN agile, revisando nuestras competencias como agile coach, (Agile Coaching Competency Framework), enfocándonos en ser un líder practicante lean agile, buen facilitador, profesor, mentor y coach, junto con el dominio técnico, funcional y organizacional donde nos desempeñamos. Ser un catalizador de los procesos de cambio y de la mejora continua, promoviendo el empoderamiento y autonomía de las personas y equipos de trabajo, facilitando la eliminación de las barreras, ayudando a las personas en el desarrollo de sus competencias (duras y blandas) promoviendo una cultura de aprendizaje, y realizando prácticas ágiles significativas como: tener buenas e ingeniosas conversaciones, identificar problemas relevantes a ser resueltos, hacer coaching en función de la demanda (pull coaching), facilitar retrospectivas que promuevan una cultura de mejora continua, entre otras.

Y para ti, ¿cómo ha sido tu experiencia como coach de agile?

Gracias por leerme,

María Esther Remedios

Ig @Soy.Agile.Coach

 

#Agile, #AgileCoach, #Scrum, #Kanban, #Coaching

 

Mis errores, aprendizajes y desafíos como Agile Coach

 Ser Agile Coach pasa por diferentes etapas. En principio no tienes claro que significa, luego lo vas interpretando, y en el camino, experimentas, cometes errores, aprendes y mejoras. No podía ser de otra forma si asumes la agilidad como una filosofía de vida.

Ser ágiles es un camino de transformación, que tienes que andar, y desandar, múltiples veces; pero que cosa, que valga la pena, no es así. 

A continuación te presento 9 de los errores que he cometido y los aprendizajes que he obtenido de ellos.

Mis inicios con la agilidad se remontan al 2010, donde como docente universitario, abrimos una electiva en Ingeniería Informática sobre Agilidad y marcos de trabajo ágiles. Me había estudiado en profundidad toda la teoría que conseguí sobre el tema y comencé a ejercer de Scrum Master. Con una amplia experiencia como consultor y gerente de proyectos, mi tendencia inicial era dar soluciones, y era natural cuando es lo que siempre te han pedido, y siguen pidiendo, los clientes.

Y ese fue mi primer error, mantener mi rol de consultor tradicional, y decirle a los equipos y personas, lo que, según mi punto de vista, debían hacer. Poco tiempo después comprendí que un agile coach no es quien da soluciones, sino quien logra que personas y equipos descubran por ellos mismos las soluciones a sus problemas y retos.

Como Scrum Master, mi foco inicial fue que los equipos Scrum aplicaran el marco lo más apegado posible a la guía de Scrum, convirtiendo la agilidad en una práctica rígida más parecida a un modelo de desarrollo iterativo e incremental, ya incluido en la Ingeniería del Software a principios de los años 80. Este fue mi segundo error, interpretar la agilidad como una práctica, con sus métodos, técnicas y herramientas, descubriendo con el tiempo que la agilidad, en esencia es una filosofía, un mindset, que permite a los equipos y organizaciones, implementar modelos de trabajo ágiles sostenibles en el tiempo, adaptativos y empíricos, donde sus prácticas están basadas en valores y principios, conceptos que no son negociables.

Al principio, no fue difícil lograr mejoras significativas en el resultado de los proyectos, pero al poco tiempo, estos resultados podían dar un giro inesperado y los equipos perder predictibilidad y confianza en la agilidad. Un tercer error fue no haber incorporado, en mis primeros proyectos ágiles, estrategias de gestión del cambio que trabajaran con las creencias y resistencias naturales de profesionales formados y con experiencia en metodologías tradicionales. Como agile coach necesité fortalecer mis competencias como agente de cambio y desarrollar la empatía suficiente para comprender las dificultades que estos procesos de transformación implican, acompañando a las personas y unidades organizativas en su proceso de transformación agile.

Cuando tienes la oportunidad de trabajar con grandes empresas, donde eres el agile coach de 10 equipos de trabajo, te encuentras con muy diversas situaciones. En dos de las empresas grandes donde he trabajado como agile coach, los Scrum Master, en su mayoría, son profesionales con mucha experiencia en gerencia de proyectos. Mi cuarto error fue pensar que sería fácil formar y trasmitir los conceptos y beneficios de la agilidad, así como implementar y hacer sostenibles los nuevos marcos de trabajo ágiles, aprendiendo que, si bien es cierto que la agilidad es fácil de comprender, es difícil de implementar.

Mi pasión por la agilidad me ha llevado en ocasiones, a transmitir su filosofía y sus prácticas, como una panacea que resuelve todas las necesidades de personas y equipos. En una oportunidad, dictando un curso sobre los fundamentos de la agilidad, un participante dando su feedback me dijo que había mucho marketing en agile. Quinto error, y en el que todavía trabajo, es el de hacerse fanático de la agilidad, ya que esto inhibe nuestra capacidad de escucha y de empatía con las personas que debaten con sus puntos de vista. Como agile coach he comprendido que ser agile implica un proceso evolutivo que pasa progresivamente por varias etapas. Creo en la agilidad, busco transmitir asertivamente sus conceptos, soy apasionada, sin llegar a ser fanática de la agilidad.

Mi sexto error era mi tendencia a replicar cuando alguien, usualmente el Scrum Master, cuestionaba alguna práctica ágil, lo que podía generar una reacción defensiva y poco abierta al debate constructivo. Como agile coach he aprendido a mejorar la escucha activa, a empatizar con las perspectivas y temores del otro, y a plantear las preguntas que ayudan a las personas a plantearse otras posibilidades.

Cuando comienzas a entender el valor de las preguntas, en un principio puede que no domines muy bien esta técnica, por lo que el séptimo error es sobrecargar al equipo y a las personas con una excesiva presión por obtener respuestas, producto de un exceso de preguntas. Uno de los desafíos que tengo como agile coach es encontrar un equilibrio entre las preguntas y el aporte de ideas que facilite un ambiente confortable y fluido de trabajo.

He podido comprobar que todos los equipos ágiles no maduran al mismo ritmo ni en duraciones similares, mi octavo error fue creer que en 3 o 4 sprints cualquier equipo ágil podía estabilizar su velocidad y lograr un determinado nivel de madurez. He visto equipos que en 2 o 3 sprints fluyen con el marco de forma natural, y otros equipos con 10 o 12 sprints que presentan dificultades manteniendo algunos principios y prácticas. Como agile coach he aprendido que cada equipo necesita un acompañamiento diferente, la personalidad y experiencia de cada uno de sus miembros (técnicos, especialistas y funcionales), su contexto organizacional, la naturaleza del producto que evoluciona, entre otros, son elementos que influyen en cómo evoluciona e implementa la agilidad en cada equipo y organización.

Muchas organizaciones y equipos son poco tolerantes a los errores y no están acostumbrados a la experimentación. Mi noveno error fue pretender cambiar esta cultura sin una estrategia clara y específica que promueva el aprendizaje y la mejora continua. Como agile coach he desarrollado algunas competencias interpersonales y comunicativas para ayudar a cambiar esta mentalidad, así como fomentar un clima de confianza y seguridad, donde los equipos tengan la autonomía y valentía suficiente para experimentar y asumir con responsabilidad sus acciones.

Comencé esta disertación indicando que ser agile coach implica un camino donde experimentas, cometes errores, aprendes y mejoras, y seguirá siendo así, no existe una meta de desempeño y efectividad para un agile coach. Parafraseando a Buda No hay un camino a la agilidad: la agilidad es el camino.

#Agile, #AgileCoach, #Scrum, #Errores, #Experimentación, #Cambio, #Mindset, #Confianza, #Valentía, #EscuchaActiva, #Empatia

Kanbanízate para ser más Productivo

Los agilistas somos personas que integran el mindset y la práctica agile en su vida personal. Con ello, logramos coherencia y beneficiamos a nuestras labores y resultados personales, familiares, sociales y laborales.

Os dejo algunas ideas para mejorar nuestra productividad utilizando prácticas Kanban y destacando el valor del autocuidado de nuestra salud integral (física, mental y espiritual) y de la mejora continua para integrar en nuestro día a día buenos hábitos.