Transición de Equipos Scrum a Squads

Ya llevamos más de 4 años trabajando como offshore para el mismo proyecto.

Aunque ha habido rotaciones de la gente involucrada en el proyecto, hemos continuado y mejorado los procesos con los que empezamos, hemos dado un paso más en las retrospectivas para hacerlas más dinámicas a la vez que efectivas, se ha dado un gran paso en automatización de tareas repetitivas y rutinarias, y la calidad resultante del código y de producto es enorme y muy valorada por los clientes finales.

En resumen, la esencia y la cultura de Solid GEAR sigue estando muy presente y nos gusta iterar.

Durante todo este tiempo, nuestro equipo siempre se ha caracterizado por trabajar con metodología ágil Scrum y ser un equipo totalmente multidisciplinar.

Somos responsables de proporcionar a nuestros clientes una gran variedad de funcionalidades en un período corto de tiempo -no llegamos a desplegar diariamente, pero nuestros clientes reciben sus funcionalidades cada dos semanas, lo que hace que el despliegue continuo tenga sentido- y de esta forma, podamos cumplir con un roadmap trimestral hecho a medida para los clientes.

Ellos saben de antemano cuándo van a recibir sus funcionalidades y la satisfacción, confianza y retroalimentación por parte del cliente es cada vez más estrecha y mejor.

Hemos superado grandes obstáculos tales como la comunicación a través de dos -e incluso tres- zonas horarias diferentes, cambios drásticos de cultura, acuerdos sobre los procesos a seguir, rotación de gente, procesos de calidad, definir un producto mínimo viable para un cliente que no conoces,…

Este equipo que ha superado tantas adversidades, lo componen 12 personas (9 desarrolladores y 3 QAs).

Equipos Squads

Trabajar en un equipo tan grande con metodología Scrum tiene sus ventajas e inconvenientes, y aunque los resultados que obteníamos eran muy buenos, llegó un momento en el que 12 personas para un equipo Scrum era algo más que inmanejable, y siguiendo los guidelines de Scrum, decidimos dividir el equipo en 3 grupos más manejables de 4 personas (3 desarrolladores + 1 QA) llamados Squads.

La primera vez que oí hablar de Squads fue en el video en el que Spotify enseña su cultura ágil de ingeniería interna.

Nos pareció una muy buena idea y decidimos hacer una transición de un equipo grande a 3 pequeños.

La transición no ha sido tan dura como se esperaba, tal vez por el nivel de confianza que tenemos o por el nivel de profesionalidad, pero sinceramente, creo que el cambio ha sido para mejor.

Estos son los cambios que hemos llevado a cabo ahora que trabajamos con Squads:

  • Sprint propio para cada equipo con sus historias de usuario.
  • Épicas para cada equipo lo que implica que seamos expertos en ciertas áreas.
  • Conocimiento más profundo de las funcionalidades que se desarrollan en cada equipo.
  • Mejor comunicación interna
  • Mayor foco y especialización de cada uno de los equipos

Por contra, si que nos hemos encontrado que se ha perdido un poco de “transparencia” en cuanto a que ahora un equipo no sabe lo que hace el otro al 100%, por lo que hacemos un gran esfuerzo en colaborar -si es necesario- y en estar alineados con los demás.

De ahí viene el hacer una daily standup común en la que todos los equipos están presentes y están al día de lo qué está ocurriendo en otros equipos, e incluso aportar ideas o soluciones a los demás.

La calidad de producto

Como ingeniero de QA, me han preguntado infinidad de veces: “¿Qué es para ti la calidad de producto?”.

Mi respuesta es siempre clara y concisa: “La calidad de producto es aquello que hace al cliente 100% feliz y satisfecho. De nada sirve darle un Ferrari si quería un Escarabajo.”. Bajo esta premisa, seguimos teniendo retrospectivas comunes, porque aunque hay ciertos aspectos que afectan directamente a un equipo, nuestro fin es que el cliente final esté satisfecho y que nosotros mejoremos y rememos en la misma dirección.

2 comentarios en «Transición de Equipos Scrum a Squads»

  1. Hola Javier,
    Nuestro equipo cuenta con 3 tracks
    1) 8 desarrolladores y 3 QAs
    2) 3 desarrolladores 1 QA
    3) 4 desarrolladores y 1 QA
    Cada uno tiene un Scrum Master, actualmente hacemos el Daily unidos, pero próximamente van a ingresar 1 desarrolladores más, Recomiendas hacer el Daily por separado? o lo divido. me preocupa el no saber que est’an haciendo y perder el foco.
    Todos usan el mismo Core o Base de datos de una misma aplicación.
    Me encantaria pudieras ayudarme

    Responder
    • Buenos días Airan.

      En primer lugar, espero que esta entrada te haya servido de ayuda y encantado de contestarte y poder ayudarte.

      Voy a trabajar bajo el supuesto de que los 3 tracks estáis trabajando para el mismo producto de forma conjunta.

      Desde mi experiencia, en nuestro caso nos pasaba igual, aunque éramos 3 tracks (3 Devs + 1 QA / track) con 12 personas en total. Hacíamos la daily conjunta porque veíamos muy importante el seguir estando alineados con el producto y con su desarrollo paralelo entre los 3 tracks. Nos funcionó muy bien la verdad, y aunque algunas veces lo que hacían los demás tracks no afectaba al desarrollo de los demás tracks, conocíamos la dirección que llevaba el producto, podíamos ver posibles dependencias entre las funcionalidades, riesgos y cómo mitigarlos e incluso identificar impedimentos.

      Yo probaría un tiempo así, y si lo veis ineficiente/inmanejable por la cantidad de gente que sois, tal vez podéis comprobar al inicio de cada sprint (en el sprint planning) si existen User Stories dependientes unas de otras y que se encuentren en tracks diferentes, y si es así, tal vez tenga más sentido el poder hacer dailies independientes, aunque repito, en mi opinión, si el supuesto es que los 3 tracks trabajáis para el mismo producto, yo la haría conjunta.

      Un saludo y si necesitas cualquier otra cosa, ¡no dudes en comentarla!

      Responder

Deja un comentario

¿Necesitas una estimación?

Calcula ahora