Cuando un grupo de personas se une para trabajar en equipo, pasan por una serie de dinámicas grupales conocidas como "Formación, Enfrentamiento, Normalización, Desempeño" (según Tuckman). Al equipo le lleva tiempo pasar por cada una de estas etapas. Progresan, tienen retrocesos, discuten y se llevan bien. Con el tiempo, a menudo varios meses, y con el apoyo adecuado, el equipo logra conocerse y trabajar bien juntos. El equipo sobresale. La productividad aumenta. Hacen un trabajo increíble. ¿Qué se necesita para lograr este nivel de productividad?
El equipo tiene que asumir una responsabilidad conjunta por su trabajo. Los miembros del equipo necesitan pensar en el resto del equipo como "nosotros", no como "ellos". Si un miembro nota que necesita hacerse algo, asume la responsabilidad aunque no sea su especialidad: hace el trabajo, busca a alguien para que lo ayude, o recluta a alguien más para que se ocupe.
Entonces, los miembros del equipo necesitan confiar entre ellos para ayudarse. Cuando un miembro del equipo encuentra una pregunta que no puede responder, no duda en preguntarle a quien conoce la respuesta. A veces estas preguntas rápidas se convierten en sesiones más largas trabajando en pareja.
La confianza es esencial para que el equipo logre un buen desempeño. Se necesita confianza para que tomarse tiempo en ayudar a otra persona no nos haga ver improductivos. Se necesita confianza en que seremos tratados con respeto cuando pedimos ayuda o no estamos de acuerdo con alguien.
La organización también necesita confiar en su equipo. Al principio Extreme Programming (XP) es diferente y extraño. No tiene los indicadores normales de progreso que los gerentes están acostumbrados a ver. Se necesita confianza para que crean en el equipo y en su capacidad de entregar un resultado exitoso.
La confianza no aparece por arte de magia - hay que trabajarla. A continuación veremos algunas estrategias para generar confianza en un equipo XP.
Estrategia #1: empatía Cliente - Programador
Muchas organizaciones están luchando con una actitud "nosotros contra ellos" entre clientes y programadores. Los clientes a menudo sienten que a los programadores no les importa sus necesidades o fechas de entrega, algunas de las cuales podrían costarle su trabajo. Los programadores a menudo se sienten forzados a comprometerse a objetivos que no pueden cumplirse, afectando su salud y relaciones.
A veces este enfrentamiento es tan intenso que los grupos empiezan a actuar justo como el otro teme: los programadores reaccionan inflando las estimaciones y enfocándose en juguetes técnicos afectando las características necesarias; los clientes reaccionan ignorando las estimaciones de los programadores y ejerciendo presión sobre la planificación. Esto puede ocurrir aunque no se presencie una hostilidad cara-a-cara.
Todo esto es una situación difícil sin una respuesta fácil. Lleva mucho tiempo reconstruir relaciones tan dañadas. Como ningún grupo puede forzar al otro a construir el puente, lo mejor es enfocarnos en cambiar nuestra propia actitud.
En esta situación, el componente faltante más importante es la empatía por la posición del otro grupo. Programadores: recuerden que los clientes tienen jefes que les demandan resultados. Los bonos, las promociones, e incluso la seguridad laboral dependen en las entregas diarias, y estas demandas no siempre son razonables. Los clientes tienen que entregar resultados de todas formas.
Clientes: recuerden que ignorando las recomendaciones profesionales de los programadores sobre las fechas de entrega a menudo lleva a consecuencias serias para los programadores. "Los equipos en proyectos comprometidos son la norma, no la excepción... Estos equipos a menuda trabajan 13-14 horas por día, seis días a la semana... en los peores proyectos, no es raro ver que uno o dos miembros del equipo caigan exhaustos, sufran úlceras o colapsos nerviosos, o se divorcien" (según Yourdon). Lo común de estas experiencias hace que los programadores sientan apatía y cinismo sobre las planificaciones y los compromisos.
Sentarse juntos es la forma más efectiva de construir empatía. Cada grupo puede ver en qué los demás están trabajando tanto como ellos. Las retrospectivas también ayudan, si se logra que los equipos no se hechen la culpa. Los programadores pueden ayudar siendo respetuosos de los objetivos del cliente, y los clientes pueden ayudar siento respetuosos de las estimaciones y recomendaciones técnicas de los programadores.
Estrategia #2: empatía Programador - Tester
También existe una actitud "nosotros contra ellos" entre programadores y testers, aunque no sean tan común ni fuerte como el problema Cliente - Programador. Cuando ocurre, los programadores tienden a no respetar las habilidades de los testers, y los testers creen que su misión es romper el trabajo de los programadores.
Al igual que con Cliente - Programador, la empatía resulta clave para mejorar las relaciones. Programadores: recuerden que el testing necesita de habilidades y trabajo cuidadoso, igual que la programación. Aprovechen las habilidades de los testers para encontrar errores que nunca se pensaron, y denles las gracias por ayudarlos a prevenir que estos problemas le lleguen al cliente y a los usuarios. Testers: enfóquense en el objetivo compartido del equipo: producir un gran producto. Cuando encuentran errores, no es motivo de celebración ni éxito. También recuerden que todos cometen errores, y que los errores no son un signo de incompetencia o pereza.
Estrategia #3: comer juntos
Otra manera de mejorar la cohesión del equipo es comer juntos. Las comidas ayudan a bajar las barreras y fomenta la cohesión del equipo. Pueden probar con un almuerzo gratis por semana. Si traen el almuerzo a la oficina, pongan la comida en una mesa "estilo familia" para que las personas no se lleven la comida a sus escritorios. Si salen a comer afuera, pidan una única mesa grande en vez de mesas separadas.
Estrategia #4: continuidad del equipo
Usualmente, cuando un proyecto termina el equipo se desarma. Se pierde entonces toda la confianza y cohesión que el equipo formó durante ese tiempo. El próximo proyecto empieza con un equipo nuevo, y tienen que volver a pasar por las cuatro etapas de la formación de equipos otra vez.
Se puede evitar este desperdicio si se mantiene a los equipos productivos juntos. La mayoría de las organizaciones piensan en las personas como "recursos". En cambio, deberían pensar en los equipos como recurso. En vez de asignar personas a los proyectos, debemos asignar equipos a los proyectos. Hagamos que las personas se unan a los equipos, y mantengamos este equipo formado por múltiples proyectos.
Algunos equipos serán más productivos que otros. Aprovechemos esto usando a estos equipos más efectivos como área de entrenamiento para los otros equipos. Podemos rotar a miembros junior hacia estos equipos para que puedan aprender del mejor; podemos rotar a miembros experimentados para que lideren sus propios equipos. Si hacemos esto de forma gradual, mantendremos intacta la cultura de equipo y la confianza.
La continuidad de equipo es una práctica avanzada: no porque sea difícil de lograr, sino porque desafía las estructuras organizacionales normales. Aunque la continuidad del equipo es muy valiosa, no es necesaria para tener éxito.