Es posible que a estas alturas ya se haya hablado mucho de trabajo en equipo, de motivación, de felicidad, y puede que leer otro artículo más de este tema te haga tirarte de los pelos. Pero es que en software, no tenemos otra opción distinta a trabajar en equipo, si queremos conseguir grandes resultados.
Y realmente, aunque no te des cuenta, en software nos pasamos la vida preocupados por estos temas. Establecemos elementos que nos permiten trabajar en equipo, pautas para comunicarnos y coordinarnos (procesos de software), tenemos algún tipo de management o delegamos las tareas entre todos los miembros del equipo, estandarizamos ciertos aspectos (como el IDE, los estándares de código, las herramientas de gestión de configuración), creamos metodologías en las que le damos más importancia a la colaboración, a las personas (metodologías ágiles), etc.
Todos estos aspectos solo existen por el hecho de que un grupo de personas tienen que trabajar juntas, porque un equipo hace cosas mejores que los individuos que lo componen de forma aislada.
Y a pesar de todo, seguimos teniendo muchos fallos en software. Hay veces que esos fallos vienen de creer que nuestros procesos son excelentes, pero en realidad no tenemos ni los procesos establecidos, ni claros, y cada uno hace lo que quiere. Otras veces sí los tenemos, pero sigue faltando algo. Y en otras situaciones no entendemos por qué no podemos llegar a acordar unos procesos entre todos.
¡Pero si en otras empresas lo hacen y les va bien! ¿Por qué nosotros no?¿Por qué cada persona entiende una cosa concreta? ¿Es que esos procesos no funcionan? ¿Es que la gente no está comprometida con esos procesos porque no ven que realmente les funcionen, son impuestos sin sentido? ¿Es que hay algo dentro del equipo que fomente que las cosas no vayan bien? Personas, personas, personas.
Y es que a veces falta lo más básico en el equipo, la confianza o tenemos situaciones de miedo, frustraciones, apatía…
Patrick Lencioni, en su libro The Five Dysfunctions of a Team – A Leadership Fable (una de mis últimas lecturas del verano, por cierto) habla de que hay 5 cosas que hacen que un equipo falle, que no termine de trabajar bien. Tras leerme el libro, no dejaba de sacar ejemplos encontrados en mi día a día, ya que habla de aspectos de sentido común muy reales, de los que podemos aprender para los equipos software o cualquier tipo de equipo.
¿Qué hace que los equipos no sean equipos?
Según Patrick hay 5 cosas que hacen que los equipos no vayan bien: falta de confianza, miedo al conflicto, falta de compromiso, evitar responsabilidades y poca atención a los resultados.
Voy a contarte mis conclusiones después de leer sobre el tema, y ejemplos en equipos ágiles 🙂
1 – Falta de confianza
El tema de la confianza ya ha aparecido alguna vez en este blog (Team Trust Canvas: Trabajando la confianza dentro de un equipo o ¿Qué motiva a las personas de un equipo?), y es el pilar central de un buen equipo.
Aquí no hablamos de una confianza “predictiva”, es decir, sé lo que Pepito va a hacer en esta situación y por lo tanto me adelanto a él para que vaya bien, o le complemento de alguna manera. Aquí hablamos de estar lo suficientemente confiados y seguros dentro de un equipo como para reconocer nuestros fallos, vulnerabilidades, decirlos abiertamente (porque influyen en el equipo) y enmendarlos. También es bueno ser capaz de pedir consejo a otro miembro del equipo si sabe más de una tecnología que tú.
Todo ello sin temor al rechazo, al fracaso, a la burla o a las malas reacciones. Deberíamos ser capaces de poder hablar estos temas abiertamente. Este tipo de confianza también va muy ligada a la transparencia y claridad dentro del equipo: si no hay confianza, no puede haber transparencia ni visibilidad.
Al escribir estas líneas me viene a la cabeza un cierto equipo de gente genial, con muchas ganas, pero que en ese momento era muy junior con la tecnología que les había tocado desarrollar. Además de lidiar con las fechas de entrega, con la imposición del proyecto y con su trabajo diario, la empresa estaba inmersa en un proceso de cambio hacia Scrum, y este equipo incorporó las reuniones de Scrum, los tableros para visualizar el trabajo, etc. En ninguna de estas reuniones salía ningún impedimento, pero era palpable que les costaba muchísimo actualizar los tableros físicos, y eran muy reticentes a utilizar Jira, a realizar un seguimiento de su trabajo.
Costó muchísimo llegar a la raíz del problema, porque lo que parecía vaguería, en realidad eran meses y meses de represión de la dirección, miedo a que pudieran ver el avance del trabajo y les recriminaran no ir más rápido por ser inexpertos en esa tecnología. Hasta solucionar este problema, fue imposible aplicar bien Scrum, ya que la visibilidad era una amenaza para el equipo.
Claro que en este punto hay que tener cuidado. Aquí hablamos de mejorar la confianza y de mostrar las debilidades siempre y cuando la gente sea competente. En este caso el problema real fue el miedo, y la gente en realidad era competente.
Si una persona siempre falla, no hace su trabajo, se está quejando siempre, y todo es un problema, no es un tema de confianza, sino de competencia. También he vivido este extremo (y mucho más en un proceso de cambio), y aunque me duele muchísimo, ha habido casos en los que cuando una persona concreta sale de la empresa todo va mejor.
Mostrar nuestras vulnerabilidades en un equipo genera confianza, hace que todos nos ayudemos, genera que el equipo piense como equipo y no como personas individuales trepando por sus intereses.
¿Cómo podríamos evitar la ausencia de confianza en un equipo ágil?
Dentro de las distintas metodologías de software, creo que la agilidad y Scrum promueven la confianza, mostrando vulnerabilidades y buscando soluciones, a través de las actividades orientadas para ello: los daily meetings, las demos a los stakeholders, las retrospectivas, etc.
Además la comunicación abierta y el feedback, son muy buenos elementos para fomentar la confianza. En el libro de Paul Goddard que mencionaba en el post ¿Cómo es posible que la improvisación teatral tenga algo que ver con los equipos ágiles? también se explican más técnicas para mejorar la confianza a través de la improvisación.
Aún así la confianza no sale sola, y hay que trabajarla y cuidarla. Mi consejo es que creéis espacios orientados a ello y dediquéis retrospectivas y dinámicas de grupo para tratar este tema.
Por otra parte, es muy importante que los líderes, los managers, CTOs, etc. den ejemplo de mostrar vulnerabilidades y generar confianza. Y por favor, aunque reconozcamos nuestros errores y los saquemos a la luz, celebrad los éxitos, reconoced abiertamente el buen trabajo, ya que muchas veces se nos olvida esta parte.
—
La semana que viene continuaré comentando el resto de puntos: miedo al conflicto, falta de compromiso, evitar responsabilidades y poca atención a los resultados.
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