Equipos autoorganizados: así funciona

La capacidad de autoorganizarse es fundamental en todas las metodologías ágiles, incluido Scrum. De hecho, los equipos autoorganizados son uno de los principios básicos del Manifiesto Ágil, que establece que "las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados".

Cuando se trata de cómo alcanzar mejor un objetivo deseado, algunos equipos optarán por dejar las decisiones sobre todas las cuestiones técnicas importantes a una sola persona del equipo.

Otros equipos optarán por dividir la responsabilidad de las decisiones técnicas según límites técnicos: el experto en bases de datos toma las decisiones sobre bases de datos y el programador con más experiencia en Python toma las decisiones sobre Python.

Otros equipos pueden decidir que quien esté trabajando en una funcionalidad determinada puede tomar la decisión, pero debe comunicar los resultados de esa decisión al equipo.

No todos los equipos ágiles se autoorganizan de la misma manera

Aquí hay dos puntos principales:

• No todos los equipos ágiles se organizarán de la misma manera y eso está perfectamente bien.
• Se podrá organizar mejor el trabajo cuando se utiliza el conocimiento colectivo del equipo, en lugar de depender únicamente del conocimiento de un solo gerente de personal.
  La ventaja de los equipos autoorganizados no es que el equipo encuentre una forma óptima de organizar su trabajo que un gerente no les haya mostrado. Más bien, la ventaja de permitir que el equipo se autoorganice es que el equipo se siente motivado a asumir la responsabilidad de completar su propio trabajo.

¿Podemos realmente esperar que los equipos ágiles sean autoorganizados?

Una crítica muy extendida a los equipos autoorganizados es: "No podemos simplemente juntar a ocho personas al azar, decirles que se autoorganicen y luego esperar un resultado positivo".

Bueno, no estoy seguro de que no sea fundamentalmente problemático juntar a ocho personas al azar y esperar un resultado positivo, pero un equipo ágil no debería ser un grupo de personas reunidas al azar. De hecho, quienes en la empresa son responsables de iniciar un proyecto Scrum deberían seleccionar cuidadosamente a cada miembro del equipo.

La dirección ejerce un control sutil sobre la autoorganización

En el artículo original sobre Scrum, The New New Product Development Game, Takeuchi y Nonaka identificaron el "control sutil" como uno de los seis principios. Las decisiones de personal se mencionan como una de las principales responsabilidades de la dirección.

Seleccionar a las personas adecuadas para un equipo de proyecto y al mismo tiempo observar los cambios en la dinámica del grupo, así como agregar o retirar miembros del equipo cuando sea necesario, es una de las principales responsabilidades de la dirección.

"Incorporamos un miembro del equipo más veterano y algo más conservador si el equipo se vuelve demasiado radical", explicó un gerente de Honda. "Tras una cuidadosa consideración, seleccionamos con gran esmero a los miembros de nuestro proyecto. Analizamos las diferentes personalidades para determinar si pueden trabajar bien juntas."

Incorporar a las personas adecuadas en el equipo ágil

Si eres gerente de personal o de alguna otra manera influyes en la composición de los equipos en tu empresa, aquí hay algunas cosas que deberías considerar:

Considera todas las disciplinas necesarias en los equipos ágiles
Para los equipos interdisciplinarios es importante que todas las habilidades necesarias, desde la idea hasta la funcionalidad implementada, estén representadas en el equipo. Esto puede significar que el equipo sea inicialmente un poco más grande de lo deseado.

Mezcla de diferentes niveles de cualificación técnica en equipos ágiles

Cuando se trata del tamaño del equipo, siempre se debe intentar establecer un equilibrio entre los diferentes niveles de cualificación en el equipo. Si un equipo tiene tres desarrolladores senior y ningún programador menos experimentado, los desarrolladores experimentados también tendrán que programar funcionalidades menos importantes que quizás les aburran.
No solo un programador junior habría realizado ese trabajo con gusto, sino que seguramente también se habría beneficiado de la colaboración con el colega experimentado.

Equilibrio de conocimiento especializado en equipos ágiles

Además de un equilibrio en las habilidades técnicas, también debemos establecer un buen equilibrio entre los miembros del equipo que tienen un profundo conocimiento especializado y el problema que estamos tratando de resolver.
Esto no significa que nunca debamos tener un equipo compuesto completamente por expertos si tenemos la oportunidad. En su lugar, deberíamos considerar mejor los objetivos a largo plazo de la organización.
Uno de estos objetivos es ciertamente el desarrollo de experiencia especializada en la empresa. Lograr esto será difícil si todos los expertos están en el mismo equipo.

Diversidad en equipos ágiles

Diversidad puede significar muchas cosas: género, origen y cultura son solo algunos ejemplos. Igualmente importante puede ser cuán diferente es la forma en que los miembros del equipo abordan los problemas, cómo toman decisiones, cuánta información necesitan para tomar una decisión, etc.
Las investigaciones han demostrado que los equipos homogéneos alcanzan el consenso más rápido que los equipos heterogéneos. Sin embargo, lo logran solo porque no son capaces de considerar todas las opciones posibles.

Perseverancia al formar equipos ágiles

También los miembros de equipos ágiles necesitan tiempo para aprender a trabajar bien juntos. Por lo tanto, intenta mantener en el mismo equipo a los miembros que han trabajado bien juntos en el pasado. Si estás formando un nuevo equipo, piensa también en cuánto tiempo los miembros del equipo podrán trabajar juntos antes de que algunos o incluso todos tengan que atender otras obligaciones.

Objeciones comunes a los equipos autoorganizados

Existen algunas objeciones a la autoorganización de equipos:

1) Una persona dominante toma todas las decisiones

Un temor frecuente es que una personalidad dominante, por ejemplo el líder técnico, decida que autoorganización significa que él o ella toma todas las decisiones.

O bien una personalidad dominante impone su opinión al equipo antes de que este haya tenido la oportunidad de discutir el tema.

En cuanto observes algo así, deberías tomar aparte a esa persona y explicarle la problemática. Hazle entender que, aunque crea conocer la solución correcta, a veces debería contener su propia opinión y dar a otros la oportunidad de compartir sus ideas.

Pregúntale si cree que el equipo sería capaz de tomar la decisión correcta si formulara sus ideas más como una opinión que como una decisión inapelable.

Utiliza la ayuda de esta persona como mentor del equipo: su tarea no debería ser solo asegurar que se tomen las decisiones correctas, sino más bien que los miembros del equipo crezcan y puedan tomar las decisiones correctas también en futuros proyectos, donde esa persona quizás no esté disponible para ellos.

2) Mi equipo espera que el Scrum Master organice todo

Una segunda preocupación que muchos tienen es que el equipo es demasiado pasivo para la autoorganización y en su lugar espera que el Scrum Master o el coach tome la iniciativa y tome decisiones importantes por ellos.

Si esto sucede, asegúrate de que los miembros del equipo comprendan que el trabajo del Scrum Master es apoyarles, no tomar las decisiones por ellos. Si tú mismo estás en el doble rol de Scrum Master/miembro del equipo, por supuesto no tienes que reprimir siempre tu opinión y puedes expresarte libremente.

En cualquier caso, deberías buscar oportunidades de involucrar a otros y no tomar todas las decisiones solo. Por ejemplo, pregunta primero a los demás miembros del equipo antes de revelar tu propia opinión.

3) El equipo es demasiado inexperto para la autoorganización

Una tercera objeción a la autoorganización es a menudo que los equipos son demasiado inexpertos para organizarse solos.

Nunca he visto un equipo que fuera demasiado inexperto para la autoorganización. Si los miembros del equipo tienen suficiente experiencia para construir un producto de software, muy probablemente también tienen suficiente experiencia para descubrir cómo pueden trabajar de manera autoorganizada.

Si no es así, deberías apoyar al equipo con formación y coaching.

En la mayoría de los casos, esta objeción solo significa que no se confía en que el equipo sea tan autoorganizado como se desearía. ¡Qué lástima! Ejerce un control sutil sobre el equipo, a través de la composición del equipo y del objetivo que le asignas, y no a través del "cómo" del trabajo diario del equipo.