Este lunes 24 de junio tuvo lugar la última reunión de Scrum Masters de Kaleidos, muchos (cientos, millones de fieles seguidores) os habréis dado cuenta de que el mes pasado no hubo post, os pido disculpas pero una mezcla de carga de trabajo, procrastinación y astenia primaveral pudo conmigo, no volverá a suceder :).
Esta vez tampoco teníamos un orden del día claro antes de la reunión (uno de los puntos en los que estamos trabajando), tener un orden del día permite que la gente pueda pensar en los temas a tratar y que estos sean mucho más productivas. La sesión se centró fundamentalmente en hacer una retro sobre nuestras propias reuniones y salieron varios puntos interesantes:
Relación entre Scrum Masters y Agile Coach
Una de las acciones que fijamos en la reunión anterior fue que el el Agile Coach hiciera una revisión por sprint con el Scrum Master de cada equipo. No se trata de una comprobación exhaustiva, es más un levantamiento de banderas a tiempo cuando algo “huele mal”, se comprueba por ejemplo si el backlog está razonablemente sano, el visual management, si las gráficas están actualizadas, a veces pega la oreja durante el Daily.
Los equipos y los Scrum Masters lo han recibido estupendamente y nos está siendo muy útil. Con el número de equipos que tenemos activos (cuatro actualmente) y el poco tiempo extra que le consume al Agile Coach está siendo un #win total
Reuniones de Scrum Masters VS Coaching de equipos
El formato de nuestras reuniones va a cambiar ligeramente. El número de asistentes a las reuniones estaba cerca del 50% de Kaleidos y hemos decido que únicamente asistan los Scrum Masters. Esta medida la disparó uno de nuestros equipos que cuenta con cuatro miembros de back con tres de ellos asistiendo a las reuniones. Con esto esperamos reducir el lucro cesante que tienen los equipos y agilizar un poco más las reuniones, por contra vemos el riesgo de que se pierda información de calidad, tendremos que ver cómo evoluciona.
Agile Coach en las retros de sprint
Esta medida surgió a raíz de un proyecto del tipo cliente pro-anti-scrum: “pro” porque en el proyecto Scrum era un requisito y “anti” porque es incapaz de seguir el ritmo que intentamos fijar. El equipo está trabajando sobre todo en la vía de hacer visible y medible la situación, tiempos de bloqueo, tiempo gastado “en B”, reuniones que agendan reuniones que agendan reuniones para tener otras reuniones… el objetivo es conseguir un cambio de actitud que se resiste a aparecer.
Un punto muy positivo fue cuando el Agile Coach asistió al último fin de sprint y pudo ver la situación en directo. Ayuda mucho el que una persona con autoridad ajena al equipo y al cliente ponga las cartas sobre la mesa, de un golpe de realismo y hable de lo que se está haciendo mal.
El resto de Scrum Masters están de acuerdo en que el Agile Coach pueda asistir cuando quiera a sus fin de sprints y que se sienta libre de opinar y de afirmar lo que vea, nadie lo interpreta como una amenaza o como un ruido innecesario sino todo lo contrario.
Scrum en equipos “grandes”
Lo que arrancó como un posible problema de equipos grandes autogestionados mutó en una necesidad de cambio de mentalidad. Por poneros en contexto ahí van unas pequeñas pinceladas sobre cómo son y cómo funcionan los equipos en Kaleidos:
- Los proyectos que tenemos actualmente en marcha son fundamentalmente web
- Los tiempos de sprint son cortos, normalmente de dos semanas. A veces hay user stories que se maquetan y programan a la vez.
- Hay un único perfil de maquetador “puro” por equipo
- Hay entre cuatro y seis perfiles de backend por equipo
- UX y Diseño van ligeramente adelantados al sprint en curso (además tenemos el handicap de que no son miembros de Kaleidos sino que normalmente son nuestros amigos de Secuoyas)
La discusión vino sobre si era posible o no en Kaleidos tener un equipo de ocho personas operativo. Después de hablar sobre ello lo que detectamos es que la situación actual es que el maquetador suele estar ahogado porque intenta alimentar al resto del equipo de back. Lo que vimos es que si el equipo tuviera un cambio de mentalidad podríamos no solo tener equipos más grandes sino hacer que los maquetadores vivan mejor en los equipos que ya están funcionando. El problema es que muchas veces la gente de back intenta estar lo más alejada posible del html y del javascript, esto para nosotros es un error, como hemos dicho la mayoría de nuestros proyectos son 100% web, no podemos estar lejos del html, todo lo contrario, tenemos que estar cerca por definición. La progresión de nivel de javascript en los proyectos va creciendo de manera exponencial, aparte del clásico jQuery nuestros proyectos tienen backbone, epoxy, angular, parsley, grunt…y el enfoque clásico de: “si se ejecuta en el navegador es front y por tanto maquetación”, ya no es válido. Sí que tenemos equipos en los que las tareas de maquetación y programación de javascript están diluidas entre los miembros del equipo y en los que el rol “maquetador puro” es más una guía y no un cuello de botella pero parece que este mensaje tiene que fluir a todos los equipos.
Y poco más, ¿qué os parece?, ya sabéis que todo el feedback que nos deis será bien recibido :-)