Una vez más ha tenido lugar la reunión de Scrum Masters en Kaleidos y una vez más intentamos sacar un post de todo esto para poder compartir los errores, ideas, etc… que de aquí salen.

De la mano de nuestro Agile Coach Antonio de la Torre ha venido el topic del día, un caso concreto que nos hemos encontrado en uno de los proyectos y que, sin duda, puede darse en otros muchos.

Subproyectos vs. Subconjuntos de historias

¿Qué pasa con aquellos proyectos que parecen un conjunto de subproyectos en sí mismos pero que el desarrollo pertenece a un mismo equipo de personas?

Un ejemplo puede ser aquel proyecto ya puesto en producción, se empieza fase 2 que tiene una serie de user stories de nueva funcionalidad pero, además, está el desarrollo de la aplicación móvil (n user stories).

Lo primero que se nos puede ocurrir es tener varios backlogs (uno para la nueva funcionalidad y otro para la aplicación móvil), pero esto solo nos valdría si cada backlog al completo tuviese una prioridad clara frente a los otros o si lo desarrollaran equipos de personas diferentes.

Si es un mismo equipo o en un mismo sprint nos encontramos user stories de nueva funcionalidad y de app móvil tendríamos un problema, con backlogs diferentes sería casi imposible priorizar, ver de manera clara la velocidad de sprint que ha tenido el equipo, planificar futuras releases y algo también importante, se perdería la visión global del proyecto.

Para estos casos hemos detectado en Kaleidos que lo mejor es mantener un único backlog pero identificando de manera clara, con etiquetas, aquellos subproyectos o conjuntos de funcionalidad. En el ejemplo concreto tendríamos una etiqueta para la app móvil. Los sprints se podrían definir como siempre, priorizando e incluyendo user stories de las diferentes etiquetas, tendríamos un cálculo fiable de la velocidad y mantendríamos la visibilidad global del proyecto.

Además si añadimos filtros por etiquetas podemos tener una muestra de aquellas user stories resueltas y pendientes de la app móvil (muy útil para resolver dudas del cliente respecto al avance, etc…).

Es una lástima que herramientas como Redmine no tengan etiquetas, por suerte en Kaleidos estamos desarrollando una nueva herramienta de gestión de proyectos que solucionará éstos y muchos otros problemas.

Nuevos proyectos nuevos equipos

Con el comienzo de nuevos proyectos hemos decidido crear nuevos equipos de trabajo. Llevábamos como un año con equipos estables y vemos muy positivo que la gente se acostumbre a trabajar con personas diferentes, que te aporten otra visión de las cosas, que detecten posibles vicios a corregir o empaparnos de los conocimientos de otros (quién no se ha puesto alguna vez en modo Zombie absorbiendo el cerebro de un compañero que sabe más de algo que tú).

Por este motivo los grupos de trabajo de Kaleidos han cambiado y con ello también la distribución de las personas en las mesas. Para nosotros es importante que los equipos trabajen juntos mental y físicamente, que se cree un espacio de equipo y, por supuesto, que no genere mucho ruido para no perturbar la paz de la oficina (si alguna vez la hubo).

Que no se me olvide mencionar las nuevas incorporaciones al grupo de Scrum Masters de nuestros compañeros Primitivo Cachero y Alejandro Alonso, que seguirán scrumizando a uno de los equipos de Grails y a uno de los equipos de Django respectivamente, en sus nuevos proyectos. ¡Estamos seguros que harán un gran trabajo!

Retrospectiva de las reuniones de SM

Detectamos la falta de una agenda de la reunión más clara y publicarla de manera anticipada, así podemos prepararnos los temas con antelación y pensar sobre ellos.

También tenemos que hacer seguimiento de las acciones, estamos algo relajados en esto (#mal).

Por otro lado aplaudimos el cumplimiento estricto del time boxing, el gran trabajo de nuestro Agile Coach y la enorme participación de todos.

Próximamente más y mejor, porque siempre esperamos mejorar, si no, ¡qué demonios hacemos!