Este post es la continuación del post ¿Qué motivos hacen que un equipo software fracase? Parte 1.
La semana pasada hablábamos de cómo el trabajo en equipo es un muy importante en el mundo del software, y qué aspectos a nivel personal pueden contribuir a que un equipo fracase.
El primer punto que tratamos la semana pasada es la falta de confianza, que sienta las bases de los siguientes puntos que voy a comentar hoy: miedo al conflicto, falta de compromiso, evitar responsabilidades y poca atención a los resultados.
Al final esto es como una cadena: la falta de confianza contribuye a tener miedo al conflicto, que provoca falta de compromiso. Esto hace que evitemos responsabilidades y en última instancia, no obtengamos los resultados esperados.
2 – Miedo al conflicto
Aquí como conflicto no me refiero a que el equipo se ponga a gritar entre sí, ni a discutir, ni que se pongan a pelear los unos con los otros. Aquí me refiero al conflicto sano, al ideológico, al poder debatir distintas opiniones sin miedo. Del encuentro de opiniones diferentes, salen las mejores ideas. Si no hay confianza en el equipo, es muy probable que haya ese miedo a los conflictos, y evitemos debatir las opiniones.
Seguro que has vivido la sensación de: “puff, no estoy de acuerdo con lo que dice este tío, pero si expreso mi opinión vamos a acabar discutiendo y nunca dará su brazo a torcer, porque no sabe escuchar y siempre tiene que tener la razón, así que no merece la pena, digo que sí y punto. Si esto sale mal, es lo que él quería”.
Créeme, que si algo es importante para un equipo, habrá conflicto de opiniones para hacer siempre lo mejor. Pero para esto la gente del equipo tiene que tener confianza, ya que si discutes con tu compañero, pero tenéis mucha confianza entre vosotros, sabes que tu interlocutor no está debatiendo porque te quiere dejar mal, ni por egoísmo. Simplemente debate y da su opinión contraria porque le importa el equipo, y le importa el tema que estáis debatiendo.
Un buen equipo tiene que ser capaz de llegar a un conflicto si lo necesita. Si de puertas para afuera todo va perfecto, pero por detrás las cosas no salen todo lo bonito que se esperaba…algo pasa.
Y lo que es peor, muchas personas se guardan el enfado si no pueden discutir algo con lo que no están de acuerdo. Y esa molestia puede salir después de cualquier manera, de forma descontrolada, cosa que es mucho peor.
¿Cómo podríamos evitar el miedo al conflicto en un equipo ágil?
Nuevamente creo que hay que dar ejemplo. Los líderes, managers, no tienen que fomentar una situación de miedo a expresarse y detectar cuando hay situaciones que frenan al equipo. Incluso es bueno que la propia gente tenga el valor de decir que algo no va bien.
Pero también tenemos que seguir un poco el sentido común: puede que un grupo de personas sin plena confianza, no se atrevan a contar sus problemas y sus opiniones delante de toda la empresa. Y por eso parezca que todo vaya bien.
En una charla, el autor de The five dysfunctions of a team, comentaba el caso de un CEO que pidió feedback anónimo sobre su forma de actuar a sus managers, y recibió feedback bastante negativo. Después, los reunió para comentar los resultados y fue preguntando:
– A ver, aquí pone que soy controlador, y no debería meterme en todas las cosas de la empresa, tengo que delegar más en mis managers que para eso están. ¿Quién piensa eso?
– Yo no, yo no, para nada…yo no…
Mmm…En este caso, alguien tuvo que poner eso, ¿no? Nunca salió quien lo puso y de esa manera nunca saldrá. A eso me refiero con sentido común.
3 – Falta de compromiso
Si en un equipo no hay confianza, y por lo tanto las decisiones no se han podido debatir, es muy probable que la gente no se comprometa al máximo, ya que no aprueba, ni se apasiona por las decisiones tomadas. No las siente como suyas, son impuestas.
¿Cómo podríamos evitar la falta de compromiso en un equipo ágil?
En la agilidad bien entendida, y en Scrum, se genera compromiso en el equipo, porque es el equipo el que da las estimaciones, el que junto con negocio establece qué historias de usuario van a entrar en el sprint, el que aprende y mejora en base a la experiencia.
Por otra parte, hay que asegurarse de que todo el mundo entienda las fechas límite, los estándares que se quieren conseguir, y que se dé ejemplo de ello.
Debemos dejar que el equipo participe en sus decisiones más directas.
En este punto me viene a la cabeza muestras reales de otro comportamiento que va en contra de la falta de compromiso: el juzgar sin saber de lo que se está hablando, y menospreciar el trabajo de la gente. Hablo de:
– ¡buah! ¿8 puntos historia de testing para este issue? ¡Que dices! Si eso en 2 horas haciendo cuatro tonterías delante de la pantalla se prueba.
– ¿Migrar esta tecnología a ésta 3 meses? – Sí, y tirando por lo bajo, ya que hay muchas dependencias y mucho código que refactorizar. – ¡Qué dices, no puede tardarse tanto! Pon que para dentro de 1 mes eso tiene que estar.
– He hecho esto y esto, y he dejado esto preparado porque he previsto que lo necesitaremos para hoy. – Vale, si eso no se tardaba nada en hacer.
Creo que estas palabras son ejemplos del asesinato del compromiso y la oda a la mediocridad en este mundo.
4 – Evitar responsabilidades
Cuando no nos comprometemos, intentamos tomar las menos responsabilidades posibles. Y eso en un entorno en el que quieres que todo el mundo colabore, se nota mucho. Se nota cuando se proponen cosas y nadie las quiere hacer de forma voluntaria. Yo lo llamo estar en estado de supervivencia o modo zombie: yo sobrevivo con lo justo y no me metas en más jaleos, porque no merece la pena, no hay confianza, no creo en eso que se está proponiendo y tampoco se va a valorar mi trabajo.
Ojo, que entiendo estar en este estado, pero es un síntoma muy grave de que las cosas no van bien, aunque todo sean afirmaciones, “seamos muy felices” y siempre digamos que sí. Va en contra de los resultados del equipo.
Otro tema relacionado con esto son los problemas con gente del equipo. Si alguien tiene un problema con una persona, y lo primero que hace es ir a hablar con el manager de ese problema en vez de tratarlo directamente con la persona en cuestión, pasa algo, el ambiente en el equipo no es favorable.
Y es normal esa actitud, yo reconozco que hay veces que me cuesta decir las cosas malas por no herir a la gente. Y un buen consejo que me dieron ante esto es: si tienes hijos pequeños, sobrinos pequeños, al principio te da pena regañarles por algo, o decirles las cosas que ves. Pero es que ellos no se dan cuenta, y la mejor forma en la que puedes ayudarles es diciéndoles las cosas. Decir las cosas malas también es un síntoma de que alguien te importa, de que un proyecto te importa como para preocuparte por él.
¿Cómo podríamos evitarlo en un equipo ágil?
Habrá muchos factores externos que puedan llevar a evitar responsabilidades. Deberíais tratar, detectar y sacar a la luz dichos factores como equipo. Internamente, hay que detectar los problemas a nivel de compañero y poner alguna solución (muchas veces vienen de actitudes, de falta de respeto con otra persona, etc.).
Y a nivel de equipo en agilidad, si todos los miembros del equipo menos uno trabajan motivados y asumen sus responsabilidades, la visibilidad del trabajo de cada uno en los tableros y en el día a día, puede hacer que dicha persona se ponga las pilas y se esfuerce más.
Al final todo se resume a dar ejemplo de lo que se quiere conseguir.
5 – No atención a los resultados
Esto ocurre cuando los miembros del equipo ponen sus objetivos individuales (por ejemplo su ego, su desarrollo profesional, reconocimiento ante otras personas), frente a los objetivos comunes del equipo.
Un equipo donde nadie confía en nadie, las cosas se ocultan y la gente solo se preocupa de su propio progreso, se traducirá en problemas a la hora de comprometerse, tomar responsabilidades, etc.
Por muy buen profesional que sea una persona, un contexto de este tipo influirá en que se preocupe menos por hacer las cosas bien. Una lástima, ya que de otra manera los resultados podrían haber sido mucho mejores.
En este punto me sorprende la influencia que puede llegar a tener 1 o 2 personas con ego, que solo se preocupan por sí mismas en equipo, y cómo pueden extender la enfermedad al resto de personas (entrando en modo zombie o haciendo que también sigan su propio ego).
¿Cómo podríamos evitar el no atender a los resultados en un equipo ágil?
Este punto es una suma de haber logrado los anteriores puntos: confianza, evitar el miedo al conflicto, compromiso y no evitar responsabilidades.
En software, tener todo esto, procesos, etc. guía a tener buenos resultados. Es muy costoso, pero te sorprendería la cantidad de veces en los que el foco de los problemas de este tipo es una persona o dos personas concretas, que hacen que se extienda la epidemia. Todos hemos tenido la sensación de: si esta persona se fuera…todo iría mejor. Si esta persona escuchara más…todo iría mejor. Y hay veces que esas personas somos nosotros.
Muchas veces entendiendo a esas personas, tratando los problemas, o simplemente hablando con la gente “problemática”, verás como todos somos personas, con motivaciones, preocupaciones y sentimientos, con las que podemos empatizar. Haciendo esto, o en último lugar, tomando las medidas oportunas, los cambios en el equipo se vuelven mucho más fáciles.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Estos dos posts son estupendos. ¡Gracias!