En Junio de 2016 empecé como director de operaciones de una Software Factory en Kerala, India. Uno de mis retos principales fue el de establecer los mecanismos para que los equipos de Kerala pudieran trabajar conjuntamente con los equipos de nuestras oficinas onSite (que usaban Scrum).
En este artículo os explicaré los puntos clave que implanté para que los equipos de Barcelona y Kerala pudieran trabajar usando scrum en base a algunas lecciones aprendidas.
Cuando tienes equipos acostumbrados a trabajar todos juntos, existen micro-comunicaciones entre los desarrolladores que son muy útiles para poder tirar adelante el desarrollo. Cuando tienes un equipo distribuido (ya sea porque está en India o bien porque los miembros hacen teleworking) estas micro-comunicaciones tienen a desaparecer.
Esto, cuando el equipo ya está maduro, puede ser positivo porque estas micro-comunicaciones para unos en realidad son micro-interrupciones para los otros. Pero, ¿cómo podemos canalizar este "modus operandi" para evitar que los proyectos dependan de esto?
Otro aspecto interesante es la comunicación del estado del proyecto, hay veces en las que hay que comunicar el estado del proyecto (necesidad de realizar un esfuerzo, felicitar al equipo, ...), cuando esta comunicación es directa, normalmente te sientas en una sala y expones la situación. En un modelo offShore, ¿como puedes transmitir esta información?
El sentido común no es nada común
Posiblemente tengas respuesta para estos dos ejemplos, pero me di cuenta que son respuestas de sentido común. Y todo lo que cae dentro del sentido común por lo general requiere de unas normas de comportamiento porque como dijo Voltaire "El sentido común en realidad no es nada común". Como estos dos ejemplos, hay más temas de comunicación, para ello establecí una tabla donde explicaba las diferentes herramientas y cuando usarlas y una máxima: "Nunca dejes de comunicar ni de preguntar algo." pero como todo, no es tan sencillo, hay que seguirlo para que se implante porque la comunicación con distancias largas es compleja.
Una vez encarrilada la comunicación básica me puse a analizar cómo se estaba realizando el seguimiento y como este cuadraba con la daily de scrum. En este punto vi que teníamos varios stoppers que lo hacían inviable, ejemplo de estos stoppers eran el horario, la cultura, la inseguridad y el idioma. En paralelo, hay que tener claro que es necesaria una coordinación periódica porque es el espacio donde se resuelven las dudas.
El trabajo en equipo es la capacidad de trabajar juntos hacia una visión común. La capacidad de dirigir los logros individuales hacia los objetivos de la organización. Es el combustible que permite que la gente normal logre resultados poco comunes.
Una vez detectado el punto conflictivo, empezamos a probar cosas para evolucionar este punto, descartamos varias opciones como la de incluir a los developers en la daily o como hacer la daily en inglés en el equipo de España ... Al final, descartamos hacer la daily conjunta, pero también detectamos temas culturales que nos llevaron a identificar la necesidad de disponer de un punto único de contacto entre onSite y offShore. En estas pruebas que hicimos, también nos dimos cuenta que hagas los que hagas, siempre es necesario duplicar uno de los roles en el equipo offShore.
Entonces empezamos a duplicar los roles, intentamos duplicar el manager, el technical leader y el product owner. Aunque vimos ciertas ventajas duplicando el technical leader y el manager, lo que nos resultó más efectivo fue duplicar product owner a la par que compartir scrum master entre los dos equipos. El rol de product owner del equipo offShore lo llamamos Proxy Product Owner.
Entre otras muchas responsabilidades, el Proxy Product Owner debe coordinarse periódicamente con el Product owner. En el momento inicial del proyecto, esta periodicidad será diaria y después se puede relajar un poco más pasando a ser 2 veces por semana de forma gradual. En estos meetings, se podrá compartir la pantalla para mostrar resultados, revisar código o hacer un seguimiento de las tareas.
Otras reuniones scrum como la sprint review o las retrospectivas se recomienda hacerlas de forma conjunta sobretodo en el inicio del proyecto para poder mejorar los procesos.
La documentación era bastante variable en función del tipo de producto, por ejemplo, para desarrollar una aplicación con lógica de negocio necesitábamos trabajar con BDD, para desarrollar una web con los mockups gráficos muchas veces era suficiente, cuando los requisitos técnicos eran muy exhaustivos la documentación técnica debía estar acorde.
Somos lo que hacemos día a día. De modo que la excelencia no es un acto sino un hábito.
En este punto, dimos cierta libertad al manager, pero nuestro equipo de QA se encargaba de validar que la documentación recibida cubría las necesidades de desarrollo. Garantizar la calidad de la documentación es importante para anticipar problemas en el desarrollo y para poder garantizar la calidad.
Un punto que es relevante al inicio del proyecto es el establecer la herramienta que sirve de repositorio y explicar cómo se va a organizar y documentar el proyecto. También es importante que se escoja un idioma común entre todos los desarrolladores (típicamente el inglés).