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.
Recomendado por LinkedIn
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:
- Mal inglés (what?)
- Mala conexión a Internet (WHAT?)
- Poco compromiso con las fechas asumidas (“the mañana culture ..”)
- Mala gestión de proyectos (incluida la mía!)
- 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?)
- Demasiadas quejas y pocas soluciones (te suena?)
Los equipos se quejaban de:
- Mucha presión por parte del cliente (pin pun pam!!!)
- Mucha presión por parte mía (y bueno, a mí me presionaba el cliente …)
- Poca documentación del sistema (producto funcionando sobre …)
- Mala arquitectura (equipo que gana no se toca)
- Código de baja calidad (spaguetti .. yami yami)
- 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