Las alegrías del Scrum Master

Las alegrías del Scrum Master

Recientemente tuve el honor de acompañar como Scrum Master a 4 equipos de Scrum de Latinoamérica para un proyecto de desarrollo de software para un cliente en Estados Unidos.

Me encantan este tipo de desafíos ya que sacan a relucir un montón fortalezas y debilidades que tenemos en la región y que muchas veces no vemos cuando trabajamos para clientes locales.

En el presente artículo voy a compartir algunos detalles de tan rica experiencia.


En total había personas de 11 países de Latinoamérica y cada equipo estaba conformado por 6 desarrolladores y 2 QA.

El objetivo era hacer migraciones, mantenimientos, fixeo de bugs y desarrollar algunas mejoras en la aplicación.

Los equipos eran 100% remotos, con ambientes de desarrollo del cliente inestables, poca colaboración con otros equipos de US e India y mucha presión por obtener resultados rápidamente.


Con el primer equipo conectamos desde el primer día, era un equipo maduro, autoorganizado y que ya se conocía.

Sin embargo, con el segundo equipo fue muy difícil generar confianza, nos costó mucho conocernos y entender la aplicación. Las personas faltaban, no entraban a las dailies y rotaban frecuentemente.

A la semana comenzaron los problemas cuando uno de los desarrolladores desapareció por 3 días sin avisar, en otra ocasión me percaté que uno de los testers no entraba a las dailies y en su lugar entraba un amigo suyo que se hacía pasar por él!

En general el cliente se quejaba de las siguientes cosas:

  1. Mal inglés (what?)
  2. Mala conexión a Internet (WHAT?)
  3. Poco compromiso con las fechas asumidas (“the mañana culture ..”)
  4. Mala gestión de proyectos (incluida la mía!)
  5. Lentitud en resolución de problemas (el cliente me llegó a decir textualmente “Agustín: no les pago para pensar, les pago para hacer … so what?)
  6. Demasiadas quejas y pocas soluciones (te suena?)

Los equipos se quejaban de:

  1. Mucha presión por parte del cliente (pin pun pam!!!)
  2. Mucha presión por parte mía (y bueno, a mí me presionaba el cliente …)
  3. Poca documentación del sistema (producto funcionando sobre …)
  4. Mala arquitectura (equipo que gana no se toca)
  5. Código de baja calidad (spaguetti .. yami yami)
  6. Estimaciones realizadas por el cliente poco realistas (sí, el cliente estimaba los Features en T-Shirt size .. “Scrumfall?”)

Con el tercer equipo vinieron los ajustes y con el cuarto una remontada increíble. Como más adelante me supo confiar alguien: “hace 2 meses eramos el peor equipo, nadie daba 2 pesos por nosotros .. y ahora somos de los equipos más fuertes y todos nos vienen a hacer consultas técnicas y somos unos referentes” .. esa sensación fue indescriptible .. haber sido parte de esa evolución fue algo casi mágico .. habían pasado charlas de vestuario, arengas, discursos emotivos .. hubo que trabajar mucho la fibra del equipo .. trabajar la confianza a full .. hacer muchas sesiones de team building … pair programming y pair review .. matriz de competencias .. y sobre todo que el equipo se la creyera .. los resultados fueron increíbles .. pasamos de resolver 2 bugs por sprint a 8 y 2 PBIs.

Gracias a esos 4 equipos y 32 seres increíbles por hacerme volver a mi primer amor, el de Scrum Master, gracias totales!!!!  Agustín

Inicia sesión para ver o añadir un comentario.

Más artículos de Agustin Varela

  • Modelo iterativo e incremental

    Modelo iterativo e incremental

    Scrum tiene un enfoque iterativo e incremental para optimizar la previsibilidad, controlar el riesgo y ejecutar…

  • Historia y evolución de Scrum

    Historia y evolución de Scrum

    La historia de Scrum comienza en el año 1986 con el artículo de Takeuchi y Nonaka llamado "The New New Product…

    1 comentario
  • Mi experiencia como speaker en el Scrum Day Perú 2019

    Mi experiencia como speaker en el Scrum Day Perú 2019

    Había presentado el título “6 dinámicas poderosas para llevar a tu equipo a un próximo nivel”, gracias Miguel por…

    4 comentarios
  • Razones y beneficios de adoptar Agilidad

    Razones y beneficios de adoptar Agilidad

    Razones: De acuerdo al último reporte anual del estado de la Agilidad, la principal razón para adoptar la Agilidad es…

  • Cuándo usar Ágil y cuándo usar Tradicional

    Cuándo usar Ágil y cuándo usar Tradicional

    Cada proyecto es único y dependiendo del contexto tenés que definir si lo vas a ejecutar con metodologías tradicionales…

    3 comentarios
  • IKIGAI: Tu razón de vivir!

    IKIGAI: Tu razón de vivir!

    Tomate un tiempo y responde las siguientes preguntas: Te levantas todos los días con ganas de vivir? Cuál es la razón…

  • ¡BASTA DE TRANSFORMACIONES!

    ¡BASTA DE TRANSFORMACIONES!

    Sabías que según el siguiente informe, el 70% de las Transformaciones (digitales, ágiles, etc) fracasan? Te preguntaste…

  • Transformaciones culturales sobre tecnológicas

    Transformaciones culturales sobre tecnológicas

    Desde mi punto de vista, Perú es un país conservador, tradicional, aferrado a la jerarquía y por eso tiene tantas…

    2 comentarios
  • Reglas de juego en los equipos de desarrollo de scrum

    Reglas de juego en los equipos de desarrollo de scrum

    Quiero aclarar que cuando en este post menciono al equipo me refiero al equipo de desarrollo, el que genera el…

  • El factor cultural en Equipos de Scrum

    El factor cultural en Equipos de Scrum

    Un factor a tener en cuenta en este mundo globalizado son las distintas culturas e idiosincrasias de cada país o…

    2 comentarios

Otros usuarios han visto

Ver temas