Agile coaching: los 12 puntos que centran la atención de los entrenadores

“Hacer agilildad” no es lo mismo que “ser ágil”. Una cosa es desarrollar de forma iterativa e incremental y otra, que personas motivadas y comprometidas aporten de forma continua y sostenible el mayor valor posible a los productos o servicios que desarrollan.

Incorporar prácticas ágiles no garantiza la agilidad.
Si el equipo, el cliente y la dirección de la empresa no tienen una mentalidad ágil (agile mindset), lo que consiguen es “hacer agilidad”, lo que en términos académicos se denomina: ingeniería concurrente.

El departamento de Ingeniería del Sofware de la Universidad Leibniz de Hannover, ha realizado un estudio (1) entrevistando a nueve entrenadores ágiles (agile coaches) de Alemania y España. El estudio identifica los 12 factores —que según ellos— se deben gestionar adecuadamente para desarrollar una mentalidad ágil.

El factor más importante es al mismo tiempo el más difícil de modelar: tener mentalidad ágil, tanto a nivel personal, como de cultura organizacional; porque las prácticas de trabajo se pueden implantar, pero no se puede hacer lo mismo ni con la mentalidad de las personas, ni con la cultura de la empresa.

Un entrenador ágil no es sólo un formador. Incorporar métodos ágiles es la mitad de su trabajo. La principal tarea de los entrenadores ágiles es el desarrollo de los equipos. Los entrenadores deben tener habilidades y responsabilidades específicas para facilitar las prácticas y supervisar que se realizan de forma correcta.

A menudo, además de imbuir los valores adecuados, el entrenador tiene que entender el contexto en el que se van a emplear métodos ágiles y adaptarlos de forma adecuada.
Para este cometido, necesitan habilidades de liderazgo, que incluyen habilidades de comunicación y comprensión de las dinámicas de grupo. Deben ser capaces de resolver conflictos y saber “crear equipo”.
También necesitan habilidades de gestión de proyectos: gestión del cambio, gestión del riesgo y gestión del conocimiento.

El estudio agrupa los factores claves para el desarrollo de la agilidad en tres dimensiones: el equipo, el propio entrenador ágil y la organización.

Áreas de foco de los agile coaches

EQUIPO

El entrenamiento debe analizar los aspectos relacionados con el equipo: los caracteres y las actitudes de cada miembro, así como los que afectan al conjunto y provienen de un nivel superior.

Agile Coaching: el equipo

Prerrequisitios y actitudes personales

Una mentalidad ágil requiere la voluntad de aprender continuamente, de reflexionar sobre el comportamiento propio y las ideas aprendidas.
Exige saber extraer conclusiones para mejorar el modo de trabajo. Conclusiones que muchas veces implican cambios personales, por lo que se necesita tener una mentalidad abierta.

Si las personas no están abiertas a la incorporación de nuevas prácticas, no tendrán interés en cambiar.
No basta con la apertura a nuevas formas de trabajar, cada persona debe estar abierta a las demás, incluidas sus actitudes y opiniones.

La agilidad facilita trabajar en situaciones con información insuficiente. Esto requiere, muchas veces reconsiderar la propia opinión y estar dispuesto a ajustarla si es necesario.

La falta de voluntad al cambio es un factor en el que el entrenador difícilmente puede influir.

Lo que el equipo tiene que aportar para la colaboración con el entrenador

La colaboración entre el coach y el equipo debe contar con la voluntad de ambas partes.
El equipo debe participar activamente en la incorporación de la agilidad, tanto a nivel de prácticas como de mentalidad. En definitiva tiene que querer “entrenar”.
Esta voluntad bidireccional implica que, por un lado el equipo debe seguir las indicaciones de entrenador, y por otro que debe pedir al entrenador pistas e ideas y darle feedback de lo que necesita para la mejora de equipo.

Problemas del equipo

Problemas personales, en el equipo o con entidades externas como la dirección de la empresa u otros equipos.
Las dificultades personales de miembros del equipo, suelen ser consecuencia de actitudes propias de la personalidad, o de la resistencia al cambio. La personalidad individual puede causar problemas. Ocurre, por ejemplo con el miedo al fracaso, porque no es compatible con un entorno de trabajo ágil, donde “fracasar rápido” es, a grandes rasgos, una de sus características.
Los problemas que causan determinadas improntas personales afectan sólo a la propia persona; pueden causar conflictos internos en el equipo.

Entre los posibles problemas del equipo también se debe contemplar si faltan flujos de información. Por ejemplo entre el equipo y la dirección. Si el equipo no percibe el apoyo de la dirección o si no conoce cuál es su visión y por qué apuesta por la agilidad, pueden surgir problemas, porque la falta de información reduce el compromiso del equipo.

Las necesidades del equipo

Esta categoría recoge los factores que necesita el equipo para que sea posible la transformación, incluida la adopción de una mentalidad ágil.
Uno es la participación en el proceso. El equipo debe participar en cada paso, para identificarse con los nuevos modos de trabajo.
Incluir facetas ya existentes y conocidas, suaviza la transición.
El equipo debe conocer y entender la visión de la dirección. Sin esta comprensión, es difícil que las personas se identifiquen con la nueva forma de trabajar y posiblemente rechazarán los cambios.
Es importante que la decisión para la transformación ágil no sea una decisión importada por el entrenador. Debe ser una decisión interna de la empresa; motivada, bien por el propio equipo (enfoque ascendente) o bien por la dirección de la empresa (descendente).

Otro factor clave es que la cultura organizativa permita a las personas desarrollar ideas, experimentar e incluso fracasar con nuevos enfoques. Esto requiere que la organización confíe en el equipo. El ambiente de confianza lo deben percibir las personas para ahuyentar el miedo al fracaso.

La confianza también incluye que el entrenador y la organización acepten las actitudes personales. Por ejemplo, si un desarrollador se da cuenta de que su actitud y su idea de trabajo no ese ajustan al nuevo enfoque de desarrollo, entrenador y dirección deben aceptar esta decisión y buscar soluciones, junto con el desarrollador.

También es importante que el entrenador se adapte a las características específicas del equipo. Debe ser flexible y ágil para reaccionar ante nuevas situaciones y cambios.

El equipo debe conocer y comprender por qué se decide implantar la agilidad. En definitiva, entender la razón de ser de las prácticas que está aprendiendo —en especial si parece que sólo consumen tiempo con nuevas reuniones—.

Lo que el equipo debe aprender

Lo que el equipo necesita no sólo aprender, sino interiorizar.

Tiene que aprender a cuestionar y “desaprender” lo conocido. A reflexionar sobre los conocimientos previos y ajustarlos si lo considera necesario. La autorreflexión es importante y se debe interiorizar en el proceso de la transformación ágil.
Aprender a aceptar los problemas y resolverlos.

ENTRENADOR ÁGIL

El entrenamiento también debe tener en cuenta aspectos relacionados con el propio coach. En el modo en el que puede apoyar al equipo y lo que debe hacer para crear una atmósfera que facilite el aprendizaje.

Agile coach

Observar y comprender

El entrenador debe observar al equipo y adquirir un conocimiento implícito del mismo: de las percepciones de las que las personas no hablan.

Se debe interesar en conocer la carrera profesional, experiencia y actitudes de sus miembros, incluidas las posibles dudas o reservas de algunos contra la nueva forma de trabajar. Este conocimiento le permite desarrollar soluciones adecuadas, en colaboración con el equipo.
Para lograr un desarrollo flexible de la agilidad, debe comprender la forma de trabajo existente, los procesos, la motivación y necesidades del equipo.
Por la importancia de los aspectos sociales entre los integrantes, también debe observar el comportamiento interpersonal y detectar posibles problemas en las relaciones, que puedan ir incluso más allá del ámbito laboral, porque pueden entorpecer la colaboración.
El grado de autoorganización y autorresponsabilidad del equipo es importante. El entrenador debe observar el ámbito de libertad definido por la organización.

Actividades del entrenador

En general, son más conceptos que métodos concretos y deben ajustarse al equipo, en función de sus características específicas y sus aspectos sociales.
La mayoría de estos conceptos surgen de las necesidades y problemas que afronta el equipo, de manera que una de las actividades del entrenador es colaborar con él para encontrar soluciones a problemas específicos, de los que incluso el equipo puede no ser consciente. Esta es una situación difícil para el entrenador porque, por un lado no debe crear problemas artificiales y por otro, debe llamar la atención sobre los impedimentos que están entorpeciendo el trabajo y están pasando desapercibidos.

“No voy a decirle a un equipo que tiene un problema si eso es lo que siento […] Si noto que hay una discrepancia, puedo intentar aclararlo primero para mí con preguntas, y luego hago que la gente sea consciente de que tal vez sea un tema en el que podamos trabajar”.

Otra actividad clave del entrenador es ayudar a vivenciar los valores y la mentalidad ágil.

“Siempre intento en las situaciones en las que los afectados podrían comportarse mejor, salir adelante con un buen ejemplo que pueda ser experimentado”.

Los entrenadores no suelen emplear simulaciones ágiles, porque son más apropiadas para colaboraciones breves en las que se requiere experimentar la agilidad en poco tiempo —por ejemplo en cursos o talleres—.

Otra actividad propia del entrenador, en este caso más concreta, es transmitir el conocimiento teórico de las prácticas ágiles utilizadas, para que el equipo pueda comprender cada técnica empleada y su razón.

No es raro que el equipo experimente incertidumbre y sobrecarga durante el periodo de entrenamiento. Si ocurre, debe estar al tanto y gestionar adecuadamente las circunstancias e información para ayudar a superarlo.

El entrenador debe transmitir expectativas realistas, tanto al equipo como a la organización, sobre el modo de trabajo ágil.

Hacer tangible la agilidad

El entrenador debe trabajar con mentalidad ágil y hacer que el equipo experimente los valores ágiles. Las simulaciones pueden ayudar en esta tarea.

Percepción de la agilidad por parte del entrenador

El entrenador debe percibir el grado de agilidad del equipo. Aquí es importante constatar que un trabajo completamente ágil sólo consigue en equipos autoorganizados.
Si un equipo está totalmente autoorganizado, la forma de trabajo ágil le resulta intuitiva —si tiene la agilidad interiorizada—.

Experiencias del entrenador
Experiencias que resultan útiles a los entrenadores ágiles.

A los coaches externos a la empresa les resulta más fácil que a los internos, percibir de forma objetiva y neutral el estado de la organización.

… los principales retos que teníamos como coaches ágiles dentro de las empresas es que muy fácilmente te intoxicas con la misma cultura. Eres una voz que tiene un color y no todo el mundo te ve como una entidad neutral que puede ayudar a toda la empresa. Así que salir fuera y poder ser considerado como una voz neutral que ayuda a todo el mundo ha sido algo muy útil para nosotros”.

Equipos diferentes se enfrentan a menudo a problemas similares. Sin embargo depende de cada equipo cómo resolver los propios. Aunque pueden ser similares entre sí, la solución siempre tiene que ajustarse a las características particulares. No existe una solución universal para un problema.

Los entrenadores experimentan dificultades con las improntas contra la adaptación de la mentalidad. En estos casos la falta de apertura dificulta el progreso.

Además es importante que la organización apoye al equipo en la evolución. Por ejemplo, llevar a cabo experimentos que pueden fracasar sólo se debería considerar cuando el equipo sabe que la organización apoya esta forma de ensayo y error.

ORGANIZACIÓN

El entrenamiento debe cubrir también aspectos relacionados con el modelo organizativo de la empresa y apoyo de la dirección

Agile coach: organización

Colaboración entre el entrenador y la dirección

La colaboración entre el coach y la dirección es de especial importancia. El primer contacto del entrenador con la empresa, suele y debe tener lugar con la dirección de la misma. Este primer contacto permite a la dirección compartir con el coach los objetivos que quiere alcanzar.

El compromiso de la dirección es imprescindible desde el primer momento e debe incluir una comunicación adecuada entre la dirección y el equipo.
Los entrenadores comparten con la dirección los problemas que no son endógenos del equipo pero que le afectan y debe asegurar que la dirección no adopta una actitud de rechazo, porque en ese caso no será posible solucionarlos.

Conceptos erróneos y obstáculos

En esta categoría se encuentran los conceptos erróneos y los obstáculos, relacionados con la gerencia, que pueden surgir durante el proceso de transformación.

Uno de los conceptos erróneos más frecuentes es el significado de “ágil”. Es habitual considerar que se trata de una palabra de moda y se malinterpreta pensando que sólo afecta a los equipos de desarrollo. Este conocimiento distorsionado de la agilidad produce una motivación ficticia de la empresa para su implantación.

Otro obstáculo habitual son los juicios erróneos. Es frecuente que la dirección extraiga conclusiones erróneas porque la información que tiene está sesgada por problemas de comunicación con el equipo.

Y por supuesto un obstáculo importante —quizá infranqueable— es una cultura incompatible con los valores de la agilidad.

Juan Palacio Bañeres – Navegapolis

(1) Jil Klünder, Felix Trommer, Nils Prenner – cc-by 2022 – How agile coaches create an agile mindset in development teams: Insights from an interview study.

Vídeo: las 3 dimensiones del mundo empresarial

En su libro La Revolución del Sentido, Fred Kofman explica el mundo empresarial como un espacio tridimensional, compuesto de «eso», «nosotros» y «yo». Es decir: una dimensión impersonal, una interpresonal, y una personal.

Cita completa en YouTube:

Los resultados de la dimensión “Eso” son necesarios, pero no son suficientes para motivar a las personas: las organizaciones humanas trascienden esta dimensión. 

Desprovistos de las otras dos dimensiones, los negocios se convierten en una actividad puramente mecánica en la que el éxito ey el fracaso dependen exclusivamente de la gestión racional de agentes racionales. Pero en la realidad tridimensional en la que vivimos y respiramos, el éxito de una empresa depende del compromiso de seres apasionados a los que su trabajo les importa muchísimo. 

Este es el motivo por el que es útil comprender las otras dos dimensiones, muy reales e igualmente esenciales: Nosotros y Yo. 

Fred Kofman, La Revolución del Sentido
Continuar leyendo «Vídeo: las 3 dimensiones del mundo empresarial»

Scrum Master 3.06

La última versión del temario troncal I (Scrum Master 3.06) actualiza el tema de estimación ágil, reflejando algunas de las críticas y alternativas más frecuentes al uso de puntos de historia. Éstos siguen formando parte del temario que explica el marco estándar de scrum, y las alternativas se han incluido entre las «Prácticas para flexibilizar scrum», en dos apartados:

  1. Estimación sin puntos de historia.
  2. #NoEstimates.

En ambos casos se destacan ventajas e inconvenientes, explicando en qué contextos pueden resultar más adecuados.

Versión actualizada

Estimación sin puntos de historia

La estimación con puntos de historia ha recibido críticas por la tendencia a malinterpretar su función. Cuando se usan para medir la velocidad de varios equipos en una empresa, por ejemplo, pueden causar tensiones. Los puntos de historia no son una buena medida de productividad: son relativos y dependen del contexto de cada equipo. Un número mayor de puntos no implica mayor esfuerzo ni calidad, pero esto no es necesariamente intuitivo. Los equipos pueden empezar a inflar estimaciones y a mover historias a la pila del sprint no por prioridad sino para acumular puntos. Bien para mantener la que consideran su velocidad media o para competir con otros. Todo esto funciona en detrimento del proyecto e inhibe la colaboración.

Hay alternativas para poder estimar evitando estos problemas:

• Tallas de camiseta: un sistema de estimación intuitivo y que mantiene cierto nivel de detalle, en el que se indica en la historia si su tamaño es XS, S, M, L, o XL. 

• Ricitos de Oro: usar sólo tres medidas para las historias: demasiado grande, demasiado pequeño, o tamaño adecuado. 

Ambos requieren tomar medidas alternativas para sincronizar el ritmo de trabajo entre equipos e identificar cuellos de botella y otros impedimentos con antelación. Pero permiten priorizar de manera intuitiva y detectar historias que requieren más análisis antes de pasarlas a producción.

#NoEstimates

Ésta es otra de las reacciones al mal uso de las estimaciones en agilidad: renegar por completo de ellas. En algunas ocasiones, en equipos de alto rendimiento acostumbrados a trabajar de forma ágil y que mantienen un flujo de trabajo continuo, puede tener sentido no estimar. Ayuda por ejemplo a prevenir la Ley de Parkinson, que dice que «el trabajo se expande hasta llenar el tiempo disponible para que se termine». 

Al igual que ocurría con los sistemas de estimación alternativos a los puntos de historia, esta manera de trabajo supone encontrar otras maneras de sincronizar entregas. 

Scrum Level versión 3.2

Scrum Level

Los cambios de esta versión afectan sobre todo a la presentación y redacción de los materiales, con una excepción: Se ha ampliado la explicación del principio 8 de la agilidad operativa (Personas sobre procesos) gracias al feedback de los últimos talleres de Scrum Level, por tratarse de un principio fundamental para la agilidad y de evaluación compleja, que requiere especial atención y detalle.

  1. Cambios formales: 
    1.1. Títulos más breves en algunas secciones.
    1.2. Eliminación de las tablas 5, 8 y 10 por redundancia.
    1.3 Corrección de erratas.
  2. Ampliaciones sobre el principio 8 de la agilidad operativa.

Actualización de la Guía Scrum Master de la versión 3.04 a la 3.05 para unificar términos y criterios

Guía Scrum Master

Para unificar términos en la comunidad scrum hemos actualizado la denominación de «equipo de desarrollo» a «desarrolladores» que ha incorporado la guía editada la semana pasada por Ken Schwaber y Jeff Sutherland, de manera que en la descripción del marco estándar de scrum de nuestra guía de formación: 

  • La denominación anterior «equipo scrum» se mantiene para referirse a equipo formado por los roles del marco: scrum master, product owner y equipo de desarrollo.
  • La denominación anterior «equipo de desarrollo» se ha cambiado a «desarrolladores». El cambio se ha realizado tanto en la descripción del ciclo scrum (pág 27) como en todas las apariciones de la guía en la que la descripción «equipo» o «equipo de desarrollo» pudiera dar lugar a confusión con «equipo scrum».

En cuanto a las consideraciones por la introducción del concepto «objetivo del producto» y los compromisos asociados en los artefactos: pila del producto, pila de sprint y definición de «hecho»:
son conceptos que nuestra formación ya contempla con el concepto de «visión» del propietario de producto y la importancia de compartirla con el equipo de desarrollo (ahora desarrolladores 🙂 así como el papel de ser el referente de alineamiento del equipo. En este sentido, nuestra guía, al cubrir más allá de la descripción del ciclo estándar ya lo trata transmitiendo la importancia de la visión del producto por parte del propietario del producto, cuyo valor debe comprender y compartir todo el equipo y hacia el que se deben alinear los esfuerzos.
Para mejorar la comprensión de los objetivos y compromisos que esto implica en los artefactos: pila del producto, pila del sprint e incremento, se han añadido respectivamente:

  • Pila del producto: El objetivo de la pila del producto es describir el estado que tendrá el producto en el futuro y que dibuja la visión compartida por el equipo para planificar.
  • Pila del sprint: La pila del sprint debe servir para definir y estar alineada con el objetivo del sprint, que marca un hito en el avance hacia la visión del producto.
  • Incremento: El incremento debe cumplir con las medidas de calidad que requiere el producto. La «definición de hecho», debe ser conocida y compartida por todo el equipo, y el incremento no se considera terminado hasta que no se alcanza.

Y por último sobre la preferencia del término de equipos autogestionados frente a autoorganizados que usa en versiones anteriores la guía de  Schwaber y Sutherland:
parece que remarca que el grado de autonomía del equipo scrum debe ser amplio, aunque sin dar mayor concreción. En este punto nuestra formación expone igualmente el concepto de equipos autoorganizados o autogestionados, sin profundizar en la guía de Scrum Master, donde posiblemente exceda el objetivo como enseñanza dirigida a equipos ágiles. En la guía troncal 2 (Scrum Level) al estar dirigida a la agilidad desde la perspectiva de la organización, la exponemos con una concreción más apropiada al tratar el principio de estructura desjerarquizada en la dimensión estructural de la empresa, marcando 4 niveles de autonomía posibles para equipos (equipos dirigidos, equipos autogestionados, equipos autodiseñados y equipos autogobernados).

Guía Scrum Master 3.05: Página de descarga.

Gestionar planes o ideas

Este vídeo ilustra con dos ejemplos la diferencia clave entre gestión predictiva y gestión ágil: la primera gestiona trabajos que tienen plan detallado desde el principio, mientras que la segunda lo va desarrollando al tiempo que lo ejecuta.

Cuando se sabe con detalle cómo debe ser el resultado final, lo más adecuado es programar un plan de acción con todas las tareas necesarias y ejecutarlo tal y como se ha previsto.

Sin embargo cuando se prefiere comenzar desde una idea general y hacerla crecer, analizando su evolución para tomar en cada momento las mejores decisiones, lo mejor comenzar con un esbozo e incrementarlo y mejorarlo de forma continua.

Manual de historias de usuario

Libro Historias de usuario de Scrum Manager

La agilidad da la bienvenida a los cambios durante el desarrollo porque aportan mejoras a la idea previa.

Las historias de usuario son un buen formato para gestionar requisitos en evolución y este manual de Scrum Manager, es sin duda uno de los mejores 😉

Esperamos que os resulte útil y con ese fin lo ponemos a disposición de todos a los que os pueda ayudar.

Los autores.

Scrum no sirve…

Scrum no te sirve si lo que buscas es una metodología para implantar agilidad.

Si quieres una metodología ágil y piensas en scrum… deberías reconsiderar si lo que andas buscando existe, porque la mejor metodología ágil es la «no metodología».
Los equipos y empresas ágiles no lo son por emplear metodologías o prácticas ágiles, sino por trabajar con principios y paradigmas culturales ágiles.

El marco estándar, el denominado scrum oficial no es una meta para alcanzar la agilidad, sino un punto de partida.

Siguiendo el concepto japonés «Shu Ha Ri» que muestra la trayectoria del aprendizaje a través de etapas, desde los primeros pasos o «Shu» hasta la maestría o «Ri«, el marco oficial es la etapa «Shu«. Es lo que denominamos scrum técnico, que sirve para aprender a dar las primeras «pedaladas» ágiles, manteniendo el equilibrio.

De igual forma que el conocimiento del lenguaje y su gramática es el punto de partida para llegar a ser escritor, el conocimiento de prácticas y marcos ágiles, es necesario para quien quiere ser ágil; pero al aprender las técnicas no hay que olvidar que al igual que la literatura no se consigue simplemente por aplicar las reglas gramaticales, la agilidad tampoco se logra sólo por emplear prácticas ágiles.

El marco de scrum técnico es perfecto para empezar, pero no te quedes en él 😉

Acerca de las certificaciones profesionales Scrum Manager

Calidad profesional

Las certificaciones profesionales Scrum Manager, acreditan que su titular además de haber superado los exámenes de certificación académica, desempeña su actividad profesional con un alto nivel de reconocimiento.

Si trabajas como profesor, consultor o coach de agilidad organizativa, con solvencia reconocida por tus clientes, colaboradores o alumnos.

Si dispones de la certificación académica de Scrum Manager, puedes solicitar la certificación profesional correspondiente aportando información curricular con referencias que acrediten el ejercicio profesional y la experiencia necesaria para el tipo de certificación que solicitas(1).

Scrum Manger verifica anualmente la vigencia de la información avalada por la certificación, por lo que cada año:

  • Debes confirmar que continúas ejerciendo la actividad y deseas mantener la certificación.(2)
  • La media de las valoraciones de calidad recibidas en Scrum Manager de clientes, colaboradores o alumnos sobre tu desempeño profesional(3) debe ser de al menos 8 sobre 10.
  • Se comprueba la vigencia de la certificación académica(4).

Acerca de
Scrum Manager Trainer | Scrum Manager Agile Consultant | Scrum Manager Agile Coach

(1) Información y alta Scrum Manager Trainer | Scrum Manager Agile Consultant | Scrum Manager Agile Coach
(2) La solicitud de renovación se realiza desde el área personal de scrummanager.com.
(3) Desde tu página de perfil público profesional de scrummanager.com.
(4) Las credenciales de las certificaciones académicas tienen una vigencia de 5 años desde el último examen realizado.

Aplicación web para «auscultar» la agilidad de los principios y valores de la empresa

eval.scrumlevel.com es una aplicación web que ayuda a determinar el grado de agilidad de los principios y valores claves de la empresa.

Se basa en Scrum Level y en su premisa de que la agilidad de una empresa no se debe a prácticas y comportamientos, sino a los principios y valores que hay tras ellos. Emplea los cuestionarios del protocolo OKs de Scrum Level para identificar cuáles son los principios y valores mejor alineados, junto con los que requieren especial atención.

Es de acceso libre a los miembros de Scrum Manager, con o sin certificaciones académicas, para formación y evaluación de la herramienta; y de uso libre para cualquier fin, incluidas las actividades profesionales, para miembros de Scrum Manager con certificación profesional.

Información relacionada: