Esta semana he comenzado la lectura del libro “Por un Scrum popular” de Tobias Mayer y me he encontrado con un capitulo que he vivido muy de cerca en mi ultimo proyecto.

 

Su titulo era: “Los equipos distribuidos no son equipos” y  solo con verlo ya me llamo la atención. Y eso que comienza con una afirmación con la que no llego a sentirme cómodo. Como introducción comenta una situación con la que muchas veces nos topamos, en la que un grupo que pretende empezar a aplicar Scrum justifica tener el equipo deslocalizado diciendo que aunque Scrum nos indica que el equipo tiene que estar junto , “… en el mundo real no siempre se puede …”. El afirma que esto no es asi puesto que es una decisión propia. Aun estando de acuerdo con que siempre se puede buscar una alternativa y en general siempre tenemos la libertad de escoger ( siempre ha sido así en mi caso ), no se si todo el mundo tiene esa libertad.

Mi resumen del articulo ( ya aviso que es mi resumen, no creo siquiera que coincida con la intención de Tobias al escribir el articulo) es que los equipos distribuidos no son mas que un grupo de personas que se comunican con mayor o menor frecuencia.

Y eso nos lleva a distinguir entre comunicarse y colaborar.Y es que para colaborar efectivamente se necesitan de los cinco sentidos, no es fácil sustituir una palmada en la espalda , una mueca en una reunión o una broma entre el equipo mediante comunicación vía mail , videoconferencia o similares.

Ademas , dicha comunicación requiere de coordinación y administración con el fin de ser efectiva (algo que no hay que ser muy espabilado para notar que huele mal)

Pero , ¿cual es entonces el objetivo de tener un equipo distribuido?.Para Tobias este no es mas que tener proveedores baratos con los que obtener grandes margenes.

Tras el articulo (y al igual que en todo el libro) aparece un anexo de Alan Cyment en el que explica su punto de vista y que para mi aporta una distinción importante. Alan distingue entre el equipo distribuido por decisión propia y el equipo distribuido impuesto.

En el primer grupo tendríamos un grupo de desarrolladores , generalmente comprometidos y talentosos que deciden trabajar separados en pos de calidad de vida.Este caso podríamos considerarlo como ligado al tema de la libertad de elección y claramente consigue un entorno con un equipo mas feliz , lo que debería repercutir en un mejor trabajo , que no olvidemos es el objetivo final.

En el segundo nos encontraríamos con el típico caso de las “software factorys” cuya alta rotación, poco compromiso y localización impuesta tiene como objetivo una reducción de costes.En este caso se hace necesario un control que solo se consigue mediante la introducción de una figura, impuesta desde fuera del equipo que, con el tiempo ,pasara de ser necesario (al principio es quien sirve de guía al equipo por sus conocimientos ) a ser un lastre.

Alan establece que existen una serie de problemas que irán apareciendo: Reuniones a distancia, distintos husos horarios, problemas técnicos, dominio del idioma…

A todos estos , y por experiencia propia yo añadiría las diferencias culturales , que sin ser malas “per se” (al contrario), mal gestionadas pueden provocar problema que acaben por minar al equipo.

En definitiva , un mas que interesante articulo que me ha hecho pensar bastante (lo suficiente como para escribir una reseña) y que creo que esta bastante en boga en estos tiempos.

Agradecería vuestros comentarios.

¿Equipos? distribuidos
Etiquetado en:    

Deja un comentario

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