Cuando leemos sobre como funciona la colaboración y la autonomía de gestión en los equipos que han adoptado metodologías ágiles, sobre como todo funciona de manera democrática, tenemos la impresión de que los desarrolladores fueron los primeros en abrazar estos conceptos y que fue difícil aceptar el principio por la alta gerencia.
Paul Glen, un consultor en liderazgo ofrece varios artículos sobre el tema, escribió un artículo titulado "Sometimes It Takes a Tyrant to Support Collaboration", donde explica que, a menudo, la colaboración debe ser defendido por líder en función de algunos tipos de comportamientos que son perjudiciales para el grupo. También ofrece algunas maneras para hacer frente a este tipo de comportamiento.
Me gustaría ir un poco más allá y escribir sobre eso, en mi opinión, serían las causas de esos comportamientos inadecuados que pueden poner en riesgo la colaboración en un equipo que ha adoptado metodologías ágiles.
Hay dos aspectos en el desarrollo de sistemas, que no son colaborativos y que tengo vistos como las raíces de estos comportamientos inadecuados:
- Falsa sensación de poder: el trabajo técnico isolado da una falsa sensación de poder. Si sólo una persona sabe cómo hacer determinado trabajo técnico, ella comienza a sentirse indispensable y cree que su empleo está garantizado. Por otra parte, a los gerentes no les gusta sentirse rehenes. Es natural que el gerente quiera que más personas sepan el trabajo de otras personas del equipo para que, en ausencia de una de esas personas, el equipo no quede cojo. Las metodologías ágiles presuponen de la colaboración, llegando al punto de usar la programación por parejas. Este es un riesgo para aquellos que piensan que el hecho de que solo ellos saben cierta parte del sistema es una garantía de empleo.
- Ocultar debilidades: la labor técnica isolada da la oportunidad de ocultar las deficiencias. Un desarrollador que tenga alguna deficiencia, por no tener revisado el código por otros puede fácilmente ocultar sus deficiencias. Ese es otro escenario que un administrador no quiere ver. Defectos técnicos pueden ser perjudiciales no sólo desde el punto de vista de la productividad, es decir, algo demora mas es ser hecho de lo que debería, sino también en términos de calidad, porque el código realizado por los desarrolladores que esconden deficiencias tiene un enorme potencial de defecto. Las metodologías ágiles, a través de una intensa colaboración que debe ser practicada, expone las debilidades, lo que también puede ser una amenaza para algunos desarrolladores.
Cuando se implementa la metodología ágil, puede ocurrir que una o más personas del equipo se sientan amenazadas por los efectos de la colaboración a la luz de los aspectos anteriores y en una situación como ésta, en última instancia acaben por buscar otro trabajo. Este es un riesgo conocido. Ken Schwabe, uno de los creadores de Scrum, menciona que se espera que el 20% de turn over cuando se elige aplicar metodologías ágiles. También mencionó que hasta el 40% de la gerencia se puede ir. En la vida de un gerente se producen muchos cambios cuando el equipo implementa metodologías ágiles.
Debemos recordar que lo mas importante es mantener los valores de las metodologías ágiles.
Por lo tanto, a pesar de sonar extraño, a veces es necesario ser un dictador para garantizar que la cooperación prevalezca en su equipo.
