Quando lemos sobre como funciona a colaboração e o auto-gerenciamento em times que adotaram metodologias ágeis, sobre como tudo funciona de forma democrática, ficamos com a impressão que os desenvolvedores foram os primeiros a abraçar esses conceitos e que o difícil foi fazer a alta gerência aceitar.

Paul Glen, um consultor sobre liderança de geeks que disponibiliza vários artigos sobre o tema, escreveu um artigo entitulado “Sometimes It Takes a Tyrant to Support Collaboration” onde ele explica que muitas vezes a colaboração precisa ser defendida pelo líder em função de alguns tipos de comportamentos que são prejudiciais ao grupo. Ele dá também algumas formas de lidar com esse tipo de comportamento.

Eu gostaria de ir um pouco além e escrever sobre o que, ao meu ver, seriam as causas desses comportamentos inadequados que podem por em risco a colaboração em um time que adotou metodologias ágeis.

Há dois aspectos do trabalho de desenvolvimento de sistemas não colaborativo que tenho visto como sendo as raízes desses comportamentos inadequados:

• falsa sensação de poder: o trabalho técnico isolado dá uma falsa sensação de poder. Se somente uma pessoa sabe fazer determinado trabalho técnico, ela começa a se sentir indispensável e acredita que seu emprego está garantido. Por outro lado, gerentes não gostam de se sentir reféns. É natural que o gerente queira que mais pessoas conheçam o trabalho de outras pessoas do time para que, na ausência de uma dessas pessoas, o time não fique capenga. As metodologias ágeis pressupõem a colaboração, chegando ao ponto de usar a programação pareada. Isso é um risco para aqueles que acham que o fato de só eles saberem determinada parte do sistema é uma garantia de emprego.
• deficiências escondidas: o trabalho técnico isolado dá a oportunidade de esconder deficiências. Um desenvolvedor que tenha alguma deficiência, por não ter seu código revisto por outras pessoas pode facilmente esconder suas deficiências. Esse é outro cenário que um gerente não quer ver. Deficiênciais técnicas podem ser danosas não só do ponto de vista de produtividade, ou seja, algo demorar mais para ser feito do que deveria, mas também do ponto de vista de qualidade, pois código feito por desenvolvedores que escondem deficiências tem um potencial enorme de dar defeito. As metodologias ágeis, por meio da intensa colaboração que deve ser praticada, expõe as deficiências, o que também pode ser uma ameaça para alguns desenvolvedores.

Quando da implementação de metodologia ágil, pode acontecer de uma ou mais pessoas do time se sentirem ameaçadas pelos efeitos da colaboração em função dos aspectos acima e, numa situação como essa, acabarem optando por procurar outro emprego. Esse é um risco conhecido. Ken Schwaber, um dos criadores do Scrum, menciona que é esperado até 20% de turn over quando da implementação de metodologias ágeis. Ele também menciona que até 40% da gerência pode ir embora. Já comentei sobre o tema da mudança de papel do gerente nas metodologias ágeis.

Por isso, apesar de soar estranho, às vezes é mesmo necessário ser um ditador para garantir que a colaboração prevaleça em seu time.