Cuándo un equipo, de menos de 10 personas, es aún grande

La parte «fácil» es que, aunque la idea es muy antigua, hoy casi todos tenemos interiorizado el problema (a) de los equipos grandes, con muchas personas, y el (b) problema, que suele acompañar al anterior, de los equipos «silo» (son dos problemas diferentes). La idea general, para minimizar los problemas de los anteriores es, esencialmente, la idea de equipos pequeños multifuncionales.

De nuevo, la parte fácil, en lo que refiere al tamaño, es guiarse por la vieja regla de 7 más menos 2 miembros (¿Cuál es el tamaño ideal de un equipo? Una revisión de estudios).

Ahora viene lo difícil, tomando como referencia el tope de 10 personas por equipo… ¿mejor dos equipos de 5? ¿y qué tal uno de 4 y otro de 6? ¿o mejor uno de 10? Ya sabes lo que te voy a decir ahora, no hay una regla definitiva, pero, esta es la buena noticia, si algunas guías, Patrones, que pueden ayudarte, luego ya sabes, te toca a ti… «Concéntrate en el momento, siente, no pienses, usa tu instinto”.

Holistic Diversity Pattern

Hay un viejo Patrón (ya sabes, Patrón de toda la vida, una buena solución, a un típico problema en un contexto) de equipos que se llama «Holistic Diversity Pattern» (esto puedes saltártelo, pero, salvo que alguien me de otra referencia, que se agradecería, creo que es del año 94, aquí la referencia página 345), que hablaba sobre la creación de equipos multifuncionales.

Concretamente, el Patrón recomendaba, allá en aquellos años, que para cada función o conjunto de funcionalidades similares (que no fases del desarrollo o partes de la aplicación) se creara un pequeño equipo multifuncional (de aproximadamente 5 personas) responsable de entregar esa función.

Si el Patron se lleva al exceso podrían observarse los siguientes síntomas:

  • Si el equipo es demasiado pequeño, imagina 2 personas, por poner un ejemplo, cada persona tiene que hacer muchas cosas diferentes, lo que lleva a muchos cambios de contexto.
  • Si el equipo es demasiado grande, imagina, 12 personas, se incrementan los canales de comunicación y coordinación y generarán perdidas de tiempo, desperdicios.

Equipos dentro de un Equipo

Hay otro Patrón, menos «popular» (como si el anterior lo fuera) y más reciente que es el «Equipos dentro de un Equipo» (puedes encontrar una referencia en el blog de Duarte).

El patrón habla de que si el equipo es muy grande, por ejemplo 10 personas, puede que el propósito común se diluya, que veas limitado el trabajo en conjunto, que la comunicación sea difícil.

Algunos síntomas de que un equipo es muy grande

Aparte de los que ya te he mencionado, típicamente se habla de que si los Daily se alargan, si los Planning se alargan, etc., puede ser síntoma de que el equipo es grande.

Pero si teniendo un equipo de menos de 10 personas los eventos se alargan… la razón no solo puede venir de que el equipo es grande, también puede ser de que los eventos no estén bien facilitados. Por lo que aquello de que los eventos se alarguen… no es del todo concluyente para justificar que un equipo es grande.

Yo suelo hacer uso de otro síntoma más, que me parece muy interesante, independientemente de si se alargan los eventos o no… si la gente se aburre en los eventos (Dalilys, Plannings, etc.). De nuevo, tampoco es concluyente, si en un Daily, por ejemplo, mientras unos hablan otros se aburren (en los Daily hay gente que se aburre) puede ser porque nos da igual lo que cuentan los compañeros, y, de nuevo, el problema puede ser de no haber trabajado la idea de equipo, el Swarming (léete este post sobre el Swarming y este de el secreto de los Dailys en equipos de alto rendimiento), las competencias en T, etc.

Pero si llegas a la conclusión de que hay Swarming por subgrupos, que es imposible extenderlo a todo el equipo, que hay sentimiento y uso de competencias en T, pero que estas no se pueden extender más, quizá, ahora sí, tengas que pensar en dividir el equipo.

Terminando…

Antes de terminar, que no se me pase, otro consejo para guiarte sobre si el equipo es grande: pregúntale al equipo.

Un temor de los Managers cuando se divide un equipo es si ello conlleva más Scrum Masters, más Product Owners. Sin ser lo ideal, o quizá sí, yo probaría primero con que el Scrum Master del anterior equipo grande ahora sea de los, por ejemplo, nuevos dos equipos más pequeños, a ver cómo evoluciona la cosa (en este post te dejé más sobre este tema Scrum master… ¿a tiempo completo?). Y lo mismo con el Product Owner.

Javier Garzás

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba