No me voy más lejos, durante una serie de conversaciones de hace un par de semanas, en el contexto de ayudar a una organización a mejorar su proceso siguiendo principios ágiles, concretamente un equipo distribuido por varios países, y la pregunta típica… “Javier, ¿crees que la distancia física entre los miembros del equipo impacta en el rendimiento del mismo?”
Ya sabéis, aquello de que el desarrollo software, que la ingeniería de software, que, en general, hacer cualquier trabajo del conocimiento, que todo aquello se realice por completo e íntegramente en el mismo lugar, todos juntos, en un único edificio de oficinas, pasó a la historia.
Sí, sí, se que aún hay sitios más tradicionales, más clásicos, que aún se pueden permitir que todo el mundo trabaje de 9:00 a 18:00 en la misma sala, juntos, pero veremos en unos años cuantos quedan… o cuantos aguantan trabajando así… o cuanta gente aguanta trabajando así (me vuelve a la cabeza aquello de horas en la oficina vs ideas y conocimiento aportado).
Sin embargo, la distancia en la ingeniería de software, y prácticamente en cualquier trabajo del conocimiento, ha tenido de siempre un enorme impacto en los equipos: La distancia importa.
A más distancia más problemas suele haber y por ello más cuidado debemos tener a la hora de cuidar la comunicación. Y no estoy hablando de separaciones de miles de kilómetros, la misma persona de la conversación que te comentaba al comienzo del post, y que inspira este texto, ya me comentaba que “-incluso el que miembros del equipo estén en plantas diferentes del edificio está impactando en que los equipos lleguen a ser verdaderamente multifuncionales, ya que muchas veces lo de tener que moverse por el edificio hace que se reduzca la comunicación-“
Y la comunicación, como facilitarla y hacerla lo más eficiente posible, es otra de esas cosas (al igual que le pasa a los entornos físicos, las interrupciones, etc.) que impacta mucho y se cuida poco. Fíjate que de hecho Dewayne Perry (aquí el artículo) y sus colegas hicieron hace ya sus años un estudio en el que observaron que los desarrolladores pasan más de la mitad de su tiempo en actividades que incluyen “algún tipo de interacción con otras personas”.
Hay una popular gráfica de Alistair Cockburn (te dejo la entrevista que tuve la suerte de hacerle hace un tiempo), que muestra los efectos de la distancia en referencia a los medios de comunicación usados: lo más eficiente es estar todos físicamente frente a una pizarra. De hecho Cockburn sugiere que “el equipo debe estar sentado con una separación no superior a la longitud de un autobús escolar”.
Otra popular curva sobre el tema es la curva de Allen, de 1977, que muestra que cuando las personas se separan a una distancia mayor a 10 metros la probabilidad de que se comuniquen al menos una vez a la semana cae al 10%.
Aunque la gráfica es antigua, y en aquellos tiempos no había la tecnología de ahora, Allen comentaba que en los últimos años la tecnología no ha podido hacer que esto mejorase mucho más.
Y es lo que también argumenta uno de los patrones Scrum, el Collocated Team, que habla de cómo si los miembros del equipo que están separados físicamente las cosas pueden funcionar de manera menos efectiva.
Dicho esto, y ya siendo conscientes y sabiendo que “sí”, que la distancia importa, que tiene impacto, lo ideal… que el equipo esté junto, lo más próximo que puedas, y que si no puede ser, al menos, que seas consciente del impacto de la distancia y que por ello pongas especial atención en como mejorarla y fomentarla.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024