Necessidade de impor a colaboração
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. Comentarei sobre o que muda na vida de um gerente quando o time adota metodologias ágeis em breve.
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.
14 de outubro de 2008 às 11:00
Joca, Bom dia!
Se o integrante da equipe não cultiva valores ágeis seria prudente me posicionar como um “ditador” ?
Vejo que posso até mudar hábitos da pessoa em questão, mas e os valores? conseguiria mudar dessa forma? Eu creio que não.
Abraços.
14 de outubro de 2008 às 18:36
Danilo,
É bem provável que você não consiga mudar os valores dessa pessoa. Se esse for o caso, talvez valha a pena até mesmo repensar se vale ter essa pessoa no time. Como o próprio Ken Schwaber disse, há pessoas que não se adaptam ao valores ágeis.
[]s.
27 de novembro de 2008 às 10:45
“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.”
Líder? Imposição de colaboração? Eventuais deficiências nos desenvolvedores devem ser superadas através de treinamento e colaboração, e não de uma “caça as bruxas”. Creio que estas equipes não estão usando metodologias ágeis.
29 de novembro de 2008 às 12:00
Olá Anderson,
Como eu disse, “ser necessário impor a colaboração” realmente soa estranho, mas faz sentido. Quando uma equipe não está usando metodologia ágil e está num ambiente onde tudo vem de um chefe centralizador, a transição para uso de metodologia ágil não é nada fácil, a começar pela mudança que acontecerá com o próprio chefe. As responsabilidades desse chefe mudarão consideravelmente. Será que esse chefe irá se adaptar? E o time, pessoas que estavam acostumadas a trabalharem sozinhas, a serem “donas” do seu código, será que todas estarão dispostas a colaborar, a compartilhar seus códigos e eventuais “gambiarras” feitas? Sem dúvida treinamento e colaboração são essenciais para o sucesso da implementação de uma metodologia ágil, mas pode ter certeza que, mesmo com todo suporte oferecido, há o risco de alguns membros da equipe não se adaptarem.
[]s.