Perspectivas - Articulos destacados

A lo largo de los últimos años, a medida que las organizaciones buscaban desarrollar sus iniciativas ágiles más allá del nivel de los equipos, los marcos de trabajo de escalado ágil causaban furor. Y a medida que las personas discutían en detalle los méritos del Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Nexus o el “Modelo Spotify”, algo se perdió en el camino. Las conversaciones sobre el escalado ágil empezaron a parecerse a las de los aficionados de fútbol en un bar:

“¡SAFe es la muerte de Agile! ¡Es lo peor!”

“¡Scrum @ Scale es una copia barata de LeSS!”

“¡LeSS es para startups, es pura fantasía para el mundo real!”

“¡Messi es muchísimo mejor que Ronaldo!”

Se convirtió en un chiste recurrente decir que el escalado ágil era como el sexo adolescente – todos hablan de él, nadie sabe cómo hacerlo, todos creen que el resto lo está haciendo, entonces todos dicen que ellos también lo hacen.

Recientemente, ha habido una comprensión colectiva de que, en realidad, se requiere una visión más holística del desafío. Escalar Agile en una organización es más que implementar un marco de trabajo (procesos). Es principalmente un cambio sobre cómo vemos el trabajo - una nueva mentalidad. Ya se ha demostrado que insertar procesos ágiles en una organización tradicional genera el efecto de “Water-Scrum-Fall”. Este término definido por Forrester es un enfoque híbrido que perpetúa el modelo de desarrollo en cascada donde predomina una estructura centralizada, y donde se lleva adelante un proceso secuencial, en vez de iterativo. Al final, es un proceso en el que los riesgos que se corren son mucho mayores.

Se ha llegado a entender que para realmente transformar una organización, hay múltiples áreas a las que se debe atender, incluyendo:

¿Cómo aceleramos las decisiones? (empoderamiento)

El desafío que proponen estas grandes preguntas para la gente que está trabajando en transformaciones ágiles está claro – las respuestas, en algunos casos, siguen cambiando. En parte por la velocidad del cambio en el mercado, pero principalmente porque,a medida que experimentamos, aprendemos más sobre nosotros mismos y sobre quiénes queremos ser.

Si las respuestas siguen cambiando, ¿no deberían seguir cambiando también nuestros procesos?

Y ahí tienes el problema básico con las transformaciones ágiles enfocadas en el proceso – pones el carro por delante de los caballos. Independientemente de si decides utilizar LeSS, SAFe, Scrum @ Scale o algún marco caro hecho a medida, la dura realidad es que el marco que elijas no garantizará el éxito. En un mundo ágil, tus procesos no deberían ser estáticos, sino que deben cambiar constantemente. Adaptándose a las necesidades emergentes de personas motivadas y con objetivos. 

En estas circunstancias, entender los patrones que subyacen la agilidad organizacional se hace más importante que el propio marco de trabajo en escalado. Si entiendes las bases – su propósito, sus puntos fuertes y debilidades, y sus condiciones – puedes adaptar tus procesos en el camino con más facilidad. No es necesario implementar SAFe para beneficiarse de la planificación a medio plazo. No es necesario implementar LeSS para beneficiarse de los feature teams.

Todos estos patrones pueden ser utilizados como bloques de la estructura organizacional. Cuando los equipos y los líderes los entienden, pueden seguir reorganizándolos como parte de sus actividades de mejora continua – jugando con su estructura organizacional para ayudar a crear un entorno en el que las personas puedan hacer su mejor trabajo.

Los marcos de escalado ágil han demostrado ser útiles en dos áreas:

definir muchos patrones de escalado ágil (y agruparlos en una unidad coherente)

proporcionar a los equipos y organizaciones un punto de partida para su transformación ágil

Así que el punto aquí no es que los marcos de escalado ágil son malos o irrelevantes. Proveer un punto de partida para que los equipos mejoren de manera continua es algo extremadamente valioso. Al igual que los marcos a nivel de equipo como Scrum, ese punto de partida evita que los equipos tengan que reinventar completamente la rueda. 

De todas maneras, no debemos perder de vista que las transformaciones ágiles consisten en cambiar la mentalidad de una organización. Los procesos y la estructura existen de apoyo, dejando que las personas pongan en práctica esa nueva mentalidad. Es entonces clave que cualquier organización que esté pensando en transformarse hacia formas ágiles de trabajo no se enfoque en qué marco usar, sino en responder las preguntas más importantes. Y a medida que encontremos más respuestas sobre lo que necesitamos/queremos ser como organización, revisar de forma continua nuestra estructura para simplificar, potenciar y catalizar. 

Para lograr esto (una estructura de adaptación continua), necesitamos entender más que solo el marco de escalada en sí – necesitamos entender los bloques (patrones) que sustentan la agilidad organizacional.

Más allá de los marcos de escalado ágil – estructuras de adaptación continua

Celebrando los 25 años de Scrum, el 18 de noviembre de 2020 se presentó la nueva guía en un evento llevado a cabo conjuntamente por Scrum Inc. y Scrum.org; las empresas de Jeff Sutherland y Ken Schwaber respectivamente, co-creadores de Scrum. Desde ese momento, La Guía de Scrum (Noviembre 2020) puede leerse y descargarse (en varios idiomas, incluso) en: scrumguides.org.

Lo primero que llama la atención es su menor tamaño. En sólo 10 páginas, los autores desgranan este marco de trabajo desde la “Definición de Scrum” hasta la descripción del “Compromiso: Definición de Hecho”, último artefacto descrito en la nueva guía. Pero no nos dejemos engañar, una guía de menor tamaño hace aún más grande a Scrum, un marco de trabajo agnóstico a la definición del valor que vayas a construir con él, una línea de trabajo que sus autores han venido desarrollando en cada evolución del marco.

Otro de los aspectos que más revuelo está generando está relacionada con los antiguos Roles de Scrum, que han pasado a denominarse “Responsabilidades”. De este modo, el concepto de Scrum Team gana en importancia (frente a los antiguos roles), pasando a describirse como un equipo autogestionado, y siendo responsabilidad del propio Scrum Team el definir quién hace qué, cuándo y cómo. De esta forma, nuevas implementaciones de Scrum son posibles, sin faltar a lo especificado en la Guía de Scrum:

Un Scrum Team formado por una persona ocupando permanentemente las responsabilidades de PO, una persona ocupando permanentemente las responsabilidades de SM, y varias personas ocupando permanentemente las responsabilidades de Developer.

Un Scrum Team formado por una persona ocupando las responsabilidades de PO, con varias personas ocupando las responsabilidades de Developer, que además se van turnando las responsabilidades de SM en orden, aleatoriamente o como/cuando ellos consideren.

Un Scrum Team formado por varias personas ocupando las responsabilidades de Developer, y rotando entre ellos las responsabilidades de PO y de SM.

Existe además un cambio sutil, pero no por ello menos importante, del que quizá no te hayas dado cuenta: la duración del Sprint ha pasado de tener una duración máxima (timeboxed) a tener una longitud fija. Esto, igual que ya ocurría antes, permite que un Sprint no se alargue, el cambio viene en que ahora también impide que un Sprint se acorte, y de esta forma, se fomenta aún más si cabe el concepto de ritmo sostenido.

Otro cambio importante es la reaparición de los “compromisos”. Y aunque sea un cambio que está provocando discusiones en diferentes ámbitos, permitidme haceros una pregunta ¿a nadie le llamaba la atención que en la guía del 2017 se incluyese el valor del Compromiso, pero luego no se especificaran compromisos en toda la guía? Pues en la nueva guía, el Scrum Team se compromete con el Objetivo del producto, con el Objetivo del Sprint, y con la Definición de Hecho para garantizar mejorar la transparencia y poder medir el progreso de entrega de valor del Product Backlog, el Sprint Backlog y el Incremento respectivamente.

Los aspectos presentados en este artículo son un pequeño resumen de algunos de los cambios que incorpora La Guía de Scrum (Noviembre 2020). Quedan sin comentar algunos otros como la eliminación (¡por fin!) de las tres preguntas de la Daily Scrum, el incorporar el desarrollo del Sprint Goal en la Sprint Planning por parte del Scrum Team, u otros cambios que en mi opinión seguirán contribuyendo a que Scrum siga siendo el marco de trabajo ágil más extendido, ya no solo en iniciativas de Desarrollo de Software, si no en cualquier iniciativa de cualquier departamento, industria o incluso en cualquier aspecto de nuestras vidas, que tenga como finalidad generar valor a través de soluciones adaptables para problemas complejos.

Publicación de la nueva Guía de Scrum (Noviembre 2020)

¿Buscas convertirte en un mejor Scrum Master o Agile Coach? Aquí tienes en qué enfocarte! Te damos 5 habilidades esenciales para un Scrum Master o Agile Coach.

Así que ya sabes Scrum. Ok, ¿qué sigue?

Antes de comenzar - evalúate honestamente. ¿Realmente conoces Scrum?

Este artículo asume que has llegado a un nivel básico de excelencia como Scrum Master/Agile Coach. ¿Pero lo has logrado realmente? ¿Cómo te evalúas? Idealmente, estás siendo asesorado por un mentor con más experiencia y con credenciales comprobadas. Pero se necesitan años de experiencia y práctica para llegar al nivel de maestría necesario para mentorear profesionalmente, y puede que no tengas a tu disposición un mentor adecuado. Si no tienes mentor, o si tienes dudas sobre su experiencia, no lo hagas solo. Únete a un programa de coaching y mentoreo de Advanced Certified Scrum Master de Agilar y recibe acreditación profesional de tus habilidades por parte de algunos de los mejores expertos de agile del mundo.

Como Scrum Master, tu equipo mira hacia ti para consejos sobre cómo auto-gestionarse de manera efectiva. La práctica más importante que puedes ofrecerle a tu equipo son buenas técnicas de Visual Management. Enséñales a visualizar su trabajo de una forma que funcione - para ellos y para tí. Experimenta con distintas configuraciones de taskboard o de herramientas digitales - no hay una única buena forma de hacerlo. ¿Cuántas columnas queremos visualizar? ¿Qué niveles de granularidad necesitamos para representar nuestro trabajo? (epics, stories, tasks, etc...). ¿Cómo visualizamos interrupciones u otro tipo de trabajo no planeado? ¿Cómo vemos quién trabaja sobre qué? Tu objetivo como Scrum Master es ayudar a tu equipo a utilizar el Visual Management eficazmente para poder responder preguntas como “en qué estamos trabajando” y “quién está haciendo qué” con facilidad. Como extras, agrega radiadores de información que respondan preguntas como “estamos yendo lo suficientemente rápido” y “qué impide nuestro progreso”. 

2. Facilitación avanzada de reuniones, workshops y trainings

Como Scrum Master, has llegado a un nivel básico de excelencia en facilitación de talleres. Ahora es momento de llevarlo al próximo nivel. Continúa practicando e invirtiendo en tus habilidades de facilitación. Prueba nuevas técnicas, experimenta, practica. Un excelente facilitador creará experiencias y resultados que deleiten a los asistentes a un taller y los dejen queriendo volver. ¿Alguna vez escuchaste hablar de gente que quiera que una reunión dure más, porque es interesante, relevante y se están divirtiendo? Este es tu objetivo. Los grandes facilitadores regularmente obtienen puntajes de NPS de 50% o más en sus talleres y puntajes de ROTI de 4 o más en sus reuniones. Algunos buenos libros para leer sobre este tópico son:  “Facilitator’s guide to participatory decision making”; “Gamestorming”; e investiga  Liberating Structures. Para mejorar tus habilidades de formación, desarróllate con la serie de Sharon Bowman, “Training from the Back of the Room”.

Capaz hayas escuchado “no tienes que ser un experto técnico para ser un buen Scrum Master”, y es verdad. Pero definitivamente ayuda. Si quieres ser un gran Scrum Master, necesitas construir una relación profunda con tu equipo, y si entiendes el trabajo que hacen esto será mucho más fácil. Además, hay muchas ideas que le pueden estar faltando al equipo, y puede que seas capaz de contribuir más que sólo coaching. Los consejos concretos sobre este tema dependen de tu área de especialización, pero si trabajas en el área de desarrollo de software definitivamente deberías estudiar XP (Extreme Programming) y Devops (lee Continuous Delivery y The Phoenix Project) para inspirarte.

Ninguna práctica  de coaching ágil está completa sin una buena comprensión de los fundamentos de Lean Thinking y del Sistema de Producción de Toyota. Aunque la adaptabilidad al cambio y la centralidad del cliente se llevan todos los títulos, la agilidad es descendiente directo de Lean y no puedes llevar a un equipo hacia el alto rendimiento si no conoces los fundamentos de la excelencia operacional, el manejo total de calidad y los marcos de mejoramiento continuo. Invierte en aprender y practicar los fundamentos básicos de Lean para aumentar tus capacidades. Hay una vasta cantidad de recursos que puedes explorar, pero nos gusta recomendar los básicos: Taiichi Ohno, Lean Thinking, The Toyota Way. Mientras kanban con una “k” minúscula forma parte del Lean clásico, el método Kanban es un framework ágil moderno que también es un buen punto de entrada a este área de conocimiento. Un curso certificado de Kanban ofrecido por una compañía respetada también es una opción. Finalmente, el método ágil LeSS (Large Scale Scrum) se apoya fuertemente en las bases del Lean & Systems Thinking así que un curso o libro de LeSS también puede ser un buen punto de entrada al Lean, además de enseñarte uno de los enfoques más importantes para acercarse a grandes iniciativas y grandes organizaciones.

5. Crear relaciones con el liderazgo y “el negocio”

Cualquier persona que haya introducido prácticas ágiles en el departamento de servicios técnicos de una organización clásica (grande) ha escuchado que uno de los logros más fáciles y rápidos es el “aumento de colaboración entre negocio y servicios técnicos”. Pero hay una diferencia grande entre los logros rápidos iniciales que observas en una revisión del sprint y el impacto transformacional que puede traer una verdadera relación con el liderazgo. La próxima frontera de Agile es hacer coaching de la organización ágil y crear líderes ágiles, y para lograr esta ambiciosa meta necesitamos Agile Coaches más fuertes y maduros. Un coach moderno no solo necesita ser buen coach, sino un buen entrenador y un gran consultor. Tienes que ser capaz de hablar con cualquier actor a cualquier nivel y dar explicaciones claras y concisas de lo que realmente significa Agile (tip: no es un proceso ni una metodología), de cuáles son los beneficios, los riesgos, por qué es urgente, y qué se necesita hacer para comenzar una transformación ágil hoy mismo. Este no es un trabajo fácil: los líderes tienen poco tiempo y paciencia y “el negocio” (los colegas de distintas áreas operacionales o funcionales de la compañía) están saturados del trabajo del día a día (BAU o Business as Usual), además de que suelen pensar que esto no les aplica. Se necesita un muy buen Scrum Master para liderar el cambio en este tipo de ambiente. Un buen libro para acercarle a un líder para despertar su interés es Doing Agile Right de nuestros amigos en Bain & Co.

5 habilidades esenciales a desarrollar para un Scrum Master o Agile Coach

Los empleados de primera línea a menudo son subestimados en una transformación ágil, pero pueden ser la clave para un enfoque verdaderamente exitoso.

 Al liderar la segunda fase en una transformación ágil, nos concentramos en transformar el negocio a un enfoque ágil– lo que, usualmente, se traduce en introducir formas de trabajo colaborativas y basadas en el Design Thinking en nuestros ciclos de vida de desarrollo e innovación de productos. Introducimos técnicas como la Experiencia del Cliente, los Mapas de Empatía y  entrenamos a nuestros Product Managers para que sean eficientes Product Owners. Incluso podemos llegar a traer a verdaderos clientes  a nuestros talleres intensivos – pero esto raramente ocurre, e incluso cuando sucede, los clientes acarrean una responsabilidad muy grande, ya que son efectivamente “personas” que tienen como tarea representar fielmente la totalidad de los deseos del segmento al que pertenecen.

 Si bien estas ideas y técnicas funcionan correctamente, nada puede reemplazar el feedback honesto y directo que los clientes reales brindan de manera regular– y ningún Product Owner puede realmente capturar esto como lo hace el personal de primera línea. 

 El personal de primera línea representa a las personas en tu organización que tienen un contacto directo, y muchas veces corto y estandarizado, con los clientes de manera diaria. Puede ser un representante de servicio al cliente, un vendedor, o un técnico de mantenimiento que, en muchas organizaciones, no es tenido en cuenta por “el negocio” cuando se habla de innovación y desarrollo de producto.

 Aprende a escuchar a tus clientes – constantemente. Los métodos formales de feedback del cliente (encuestas de satisfacción del cliente, focus groups, talleres intensivos de Design Thinking, etc) son geniales – pero incluso es mejor cuando los combinas con un flujo constante de comentarios informales. En una organización ágil, se alienta a los empleados de primera línea a establecer regularmente relaciones estrechas, no supervisadas y saludables con los clientes finales para brindarles un mejor servicio, pero también para capturar sus pensamientos y comentarios. Esta cercanía proporciona un flujo constante de comentarios informales y no estructurados que resulta más eficaz para capturar los cambios de ánimo de los clientes en comparación con los métodos más formales.

 Imagina que todos los productos y servicios de tu compañía se venden en Amazon.com – piensa en la cantidad y calidad de feedback que recibirías a través de las reseñas. Eso es lo que estamos buscando. Y no es nada fácil si lo que vendes son seguros, automóviles o educación, por lo que necesitarás de la participación de tu primera línea de empleados. 

 Empodera a tu personal de primera línea. Una de las características más fuertes de una organización ágil innovadora es el empoderamiento y la auto-organización que el personal de primera línea exhibe en el día a día. Esto es así, ya que actúan sobre el feedback que reciben de los clientes sin ser bloqueados por la burocracia ni tener que pedir permiso a nadie y toman riesgos en pos del cliente, saliéndose de su camino para poder otorgarle al mismo lo que necesita (dentro de lo razonable); sin embargo, esto puede significar cualquier cosa, desde proveer un extraordinario servicio al cliente hasta pasar solicitudes de funcionalidades importantes a un Product Owner.

 Autonomía y empoderamiento no significan “haz lo que quieras”. Un error común es crear una cultura de la autonomía, sin poner en su lugar los circuitos de feedback internos necesarios para capturar ese feedback crítico. Nada es más desmotivante que saber lo que tu cliente necesita, pero no ser capaz de redirigir dicha información a la persona indicada. Esta es la razón por la que las organizaciones ágiles exitosas tienen un enfoque disciplinado para compartir los valiosos comentarios que los trabajadores de primera línea obtienen con los Product Owners adecuados. Además los Product Owners comunican nuevas funcionalidades, Roadmaps y Product Backlogs con honestidad y transparencia. ¡Asegúrate de que estos mecanismos estén en su lugar antes de emocionarte y empoderar a tu personal de primera línea!

Agilidad en los empleados de primera línea – el eslabón perdido hacia la verdadera innovación y el enfoque en el cliente 

Imagínate como el  Scrum Master de un Scrum Team. Recuerda la última vez que el equipo acudió a ti con algún problema o inconveniente y, como coach del equipo, hiciste lo correcto: no los aconsejaste; en cambio, les hiciste preguntas para guiarlos a solucionar el problema por su cuenta.

Ahora piensa en esas preguntas que les hiciste… ¿Eran preguntas tendenciosas? ¿Estabas haciendo preguntas lo suficientemente imparciales, dejando de lado todas tus ideas y juicios de valor? ¿O sutilmente ocultaste la solución a sus problemas dentro de una pregunta esperando que la otra persona capte el consejo y trabaje sobre eso?

No te sientas mal, es muy fácil caer en la trampa. Pero ahora que lo sabes ya puedes empezar a evitar estas preguntas tendenciosas. Cada vez que hacemos una pregunta tendenciosa, apartamos a nuestros equipos de estar más cerca de la autogestión; los apartamos de la excelencia.

Una pequeña pregunta tendenciosa es una de las tantas formas de control que aleja a los grupos de la autogestión de trabajo. Una vez que entendamos esto, estaremos listos para dar un paso más hacia convertirnos en mejores coaches, mejores Scrum Masters y en grandes agentes de cambio para estas organizaciones.

La responsabilidad del Scrum Master se basa en dar servicio al Scrum Team, al Product Owner y a la Organización como un todo. Para esto, resulta indispensable tener un conocimiento sobre Agilidad y Scrum. El coaching y la actitud de liderazgo del Scrum Master trabajan como un catalizador de cambios en el trabajo del equipo.

Así, una de las principales funciones que se le atribuyen al Scrum Master es la de ayudar al Scrum Team a gestionarse de manera autónoma.

Para el Scrum Team la autogestión consiste en tener la responsabilidad de, y saber elegir cómo administrar y llevar a cabo el trabajo que le ha sido designado sin depender de alguien que los gestione. 

Está comprobado que las personas más cercanas al trabajo saben bien qué hacer, y dadas las mejores condiciones del ambiente de trabajo y del equipo, son quienes, al final del día, obtienen mejores resultados en menos tiempo.

Las condiciones adecuadas del trabajo en equipo

Las mejores condiciones de los equipos para la autogestión son las siguientes:

El equipo debe ser multifuncional: cada miembro cuenta con distintos conocimientos, habilidades y experiencias distintas. El Scrum Master puede trabajar con el Scrum Team para potenciar las habilidades y las capacidades en su conjunto, buscando vacíos y oportunidades de crecimiento ligadas a las competencias necesarias para que el equipo logre trabajar de manera independiente.

Para un mejor flujo de comunicación y de colaboración los grupos deben ser pequeños, de hasta un máximo de diez personas.

Los equipos permanentes obtienen un mejor desempeño. De hecho, los cambios en los equipos provocados por decisiones de la organización son un gran obstáculo para la autogestión.

 El Scrum Master debe ser el agente de cambio de la organización para crear las condiciones necesarias para que existan equipos capaces de la autogestión.

Con un poco de suerte, tu organización estará lista para llevar a cabo un cambio integral, ya sea empezando poco a poco, con una prueba piloto o a partir de una fase más avanzada. De cualquier forma, es probable que no tengas un equipo multidisciplinar, pequeño o  permanente desde el principio; pero es un trabajo continuo para crear las condiciones adecuadas de trabajo.

Las condiciones adecuadas del ambiente de trabajo

El mejor ambiente de trabajo es el ambiente donde no es necesario decirle al equipo lo que tiene que hacer.

Como nadie le indica al equipo lo que tiene que hacer, el propio equipo de desarrollo va a tener que idear un plan de trabajo. Lo más probable es que fallen y aprendan de sus errores: tendrán que buscar un nuevo enfoque y realizar ajustes permanentemente. Los ambientes de trabajo en donde se confía en que los equipos aprendan de sus fracasos son ambientes de constante aprendizaje y, al fin y al cabo, de innovación y excelencia.

Tener presente el enfoque, los ajustes y los resultados finales va a motivar al equipo y los hará estar más concentrados, interesados y comprometidos con el trabajo. Con el tiempo mejorarán su estado de ánimo y, como resultado, presenciarán un incremento de la productividad. El Scrum Master debe asegurarse de que el Scrum team se empodere para gestionar el propio trabajo (el cómo).  

El Scrum Master es el principal responsable de abolir la cultura del comando y del control para mejorar la organización de aprendizaje. Sobra decir que se trata de un cambio cultural y, como tal, no ocurre de la noche a la mañana; el Scrum Master debe establecer un ejemplo al ser consciente del impacto de su propio comportamiento.

Cómo una pregunta tendenciosa puede entorpecer la autogestión de tu equipo