Alineando equipos técnicos
Porque no solo de programar viven los Coding Stones
Recientemente facilitamos un workshop cuyo objetivo fue alinear la visión de diferentes equipos técnicos, unificando criterios y tomando decisiones conjuntas que formaran el siguiente plan de acción a nivel de infraestructura y arquitectura web.
En este post os contamos cómo facilitamos este workshop en Roiback, empresa dedicada al sector hotelero, y qué dinámicas usamos, para que conozcáis de primera mano algunos de los tipos de consultoría técnica que estamos haciendo los Coding Stones. Junto con formación en Clean Code y eXtreme Programming, y otros cursos sobre testing, completan nuestro actual catálogo de productos, más allá del puro desarrollo de software.
1. See for yourself
Antes de poder ayudar a alinearse a nadie, y en especial dado que íbamos a ser parte activa y no sólo facilitadora de las propuestas de soluciones técnicas, era necesario “ver y tocar”, o “Genchi Genbutsu”, uno de los conceptos clave del Sistema de Producción Toyota, que inició el movimiento Lean.
Esto ya se había avanzado en parte por hangout, puesto que se nos habían transmitido los problemas actuales y soluciones a las que se querían llegar, pero nos pareció enriquecedor la posible conversación que pudiera surgir entre los asistentes al taller. Hablamos de unos 10 asistentes fijos a lo largo de todo el workshop, y otros que según su carga de trabajo asistieron parcialmente, alrededor de 18 personas de 7 equipos técnicos diferentes.
Efectivamente salió mucha conversación y sirvió como un buen calentamiento que nos permitió terminar de conocer todas las piezas de su infraestructura y arquitectura. Pero no íbamos a empezar por ahí, sabíamos que era necesario pasar por varias dinámicas de alineación previamente.
María, Scrum Master en Roiback, nos prestó su Time Timer para limitar en el tiempo las dinámicas. Sin duda mucho más gritón y visual que mi pequeño huevo pomodoro que traía yo desde Zaragoza para timeboxear.
¡Gracias María por tu ayuda en el workshop!
2. Alineación
Josep, CTO de Roiback, hizo una pequeña introducción transmitiendo su percepción sobre la necesidad de simplicidad. Y enseguida pasamos a algo fundamental que a veces se olvida… alinear las visiones de todos sobre el porqué nos hemos juntado. Porqué hemos sentido la necesidad de parar a hacer introspección y análisis.
“La asunción de consenso cuando no lo hay, es lo que mata muchos proyectos” — o porqué, IMHO, son necesarias estas dinámicas de alineación —
— Jonathan Rasmusson, en el libro “The Agile Samurai”
Hicimos el clásico “Why we are here”, pero mezclado con una dinámica de presentación para ir conociendo mejor a los asistentes al taller que aún no conocíamos, y que la gente se soltara un poco. Tener conversaciones “entre humanos” y dejar de lado lo técnico aunque sea por un minutico, siempre ayuda para estar más participativo posteriormente.
Aunque hubo una divergencia de opiniones y visiones, personalmente me sorprendió (respecto a otras facilitaciones que he hecho) que la divergencia todavía no fue especialmente grande, no hubo muchas sorpresas. En general, parecía que los equipos tenían bastante claro sus principales problemas y dolores. En este punto, se empezaron a formar dos posibles líneas de actuación diferenciadas: la que ya conocíamos directamente de las conversaciones previas al workshop, relativa a ir acercándose hacia el despliegue continuo; y la que llamamos “Governance técnico” (unificar criterios, homogeneizar procesos, etc).
Néstor y yo llevábamos un set relativamente amplio de dinámicas ya preparadas, cada una enfocada a conseguir unos objetivos concretos, para así poder adaptarnos sobre la marcha a las necesidades que aún no hubiésemos descubierto del cliente. Es decir, no llevábamos el workshop cerrado, sino que nuestra intención era adecuar su ejecución a lo que percibiéramos que más valor iba a aportar a nuestro cliente.
Dada la no excesiva divergencia surgida en los hangouts previos y estos “calentamientos”, decidimos concretar más haciendo un “Speedboat”, para afinar un poco sobre qué estaba frenando el avance de los equipos, y sus percepciones sobre qué les ayudaría.
Aquí emergieron inquietudes que no habían aparecido hasta ahora, desde la carga de trabajo por tareas manuales que podrían ser automatizadas, hasta otros relativos al alineamiento o la relación IT/Negocio que de una manera u otra afectaban a la productividad de los equipos técnicos.
Todavía estábamos en un punto de divergencia de ideas, pero antes de pasar a una fase de convergencia, queríamos abordar la parte de consultoría técnica propiamente.
3. El grosso técnico
Tras un descanso, venía nuestro fuerte. Néstor presentó el patrón “estándar” de Deployment Pipeline, que abre el camino hacia Continous Delivery, e invitamos a los asistentes del taller a pensar por grupos qué solución concreta implementarían en su contexto, y qué pasos darían para llegar a ella.
Dentro del debate generado alrededor de la exposición de las diferentes soluciones, nosotros también presentamos nuestra propuesta.
Otra de las ventajas de haber pasado por las fases previas del taller, en vez de escupir directamente nuestro rollo técnico presentando una propuesta ideal estándar y pirarnos, es que nos permitió destacar con conocimiento de causa en qué partes deberían centrarse, para obtener el mayor retorno del esfuerzo.
Tras la exposición de sus soluciones técnicas, el debate generado alrededor, y nuestra propuesta técnica concreta y enfocada, se tomaron decisiones técnicas que se plasmaron en tareas accionables.
Como el cansancio se empezaba a hacer latente y ya era hora, pedimos sushi a domicilio y nos fuimos todos juntos a comer a otra sala.
4. Tareas accionables
Tras la comida, para recuperar motor de nuevo, hicimos una dinámica de “Viaje al futuro”.
Con el ejercicio de imaginarse a 6 ó 12 meses vista del workshop, corroboramos lo motivados que estaban y las ganas que tenían de ponerse en marcha, y también salieron otros miedos, lo que nos permitió identificar qué partes se percibían más difíciles de ejecutar en su contexto organizativo.
También surgió la preocupación de poder demostrar el valor devuelto por estos esfuerzos técnicos, a nivel de negocio.
Ya habíamos sugerido pasos con alto retorno de inversión, pero sentimos la necesidad de terminar el workshop haciendo un cuadrante de tareas por ROI/esfuerzo.
Con la premisa de simplicidad en mente con la que Josep, el CTO, abrió el workshop, se hizo un último esfuerzo para volcar exclusivamente tareas accionables ordenadas por el esfuerzo y el valor que devolvían.
Se reflejó la preocupación de poder demostrar el valor de estos esfuerzos a nivel de negocio, en tareas relativas a medir con una serie de métricas que permitieran demostrar beneficios tangibles con el paso del tiempo.
Además del delivery de una lista de tareas accionables ordenada por la relación entre esfuerzo/valor portado, se decidió formar un pequeño equipo enfocado en poder implantar algunos los cambios más complejos, mientras que otros se intentarían asumir de forma orgánica por los diferentes equipos técnicos.
5. Seguimiento
Mes y medio después de la realización del taller, tuvimos una reunión de seguimiento, donde nos alegró saber que el delivery de tareas accionables se volcó a un backlog útil sobre el que se está trabajando activamente.
Se implementaron todas las mediciones de métricas y posteriormente se realizaron algunas de las mejoras pactadas, que entre otras cosas redujeron los tiempos de respuesta.
Y sobre todo, nos transmitieron cómo los equipos técnicos se sienten motivados por ver una dirección más clara de mejora continua, con decisiones técnicas que se decidieron en común.
