Quem tem medo de Scrum?

Após quase um ano (um ano!) de trabalho duro, voltado à implantação de Scrum em minha empresa, posso dizer categoricamente a todos, em alto e bom som: Ser ágil hoje em dia não está nada fácil! E tem mais! Mudar a cabeça das pessoas que trabalham em TI, visando criar um novo ambiente, uma nova forma de pensar e transformar tudo isso em uma nova cultura, é tão ou mais difícil que escalar o Monte Everest! Para ambos, além do preparo físico, é preciso o psicológico! Pois obstáculos não faltam…

Antes de qualquer coisa, também digo que não! Não sou e nem sofro de um sentimento derrotista! E tem mais: Prefiro atuar com Scrum à ter que subir uma montanha! Afinal de contas, estou deixando aqui apenas mais um depoimento real, de quem saiu do universo teórico dos livros e chegou a uma constatação! Pois entendo que um livro só é bom se vier seguido da prática!

Nesse caso, para aqueles que tentam se aventurar nessa arte, fica aqui um conselho: Como dizia meu Scrum guru Alexandre Magno, a resistência maior ao Scrum não está do lado do cliente (que adora a agilidade), mas sim na própria equipe de TI! E pasmem! A maior mudança, a cultural, não está no comercial, na pré-venda ou na concepção de projeto para o cliente, mas sim, está dentro da nossa própria cozinha! E nessa hora, o que fazer?

Trabalhar de maneira ágil, segundo rezam diversas cartilhas agilistas, de referências como Scott Ambler, Ken Schwaber ou Alistair Cockburn, todos esses são unânimes em apenas um único ponto: Para que seu projeto dê certo e você se torne ágil, o primeiro passo é comunicar-se bem, mais e melhor! E fazer isso é simples? Sim, é muito simples! Tão simples que dói, e para fazê-lo tem que ter coragem…

Digo isso porque sem sombra de dúvidas, para promover a comunicação efetiva entre as pessoas, certas barreiras devem ser transpassadas, dentre elas o orgulho, o ego e a vontade de se sentir mais que o outro. Da mesma forma, para liderar e ser um Scrum Master (team lider), não é preciso ser um catedrático em metodologias ou vomitar processos malucos e sair preenchendo templates. Basta apenas existir no time de projeto uma liderança servidora e pessoas responsáveis por seu trabalho; comprometidas em quebrar problemas e promover a cooperação entre todos os membros, da própria equipe e do seu cliente.

Para isso, o líder deve ter uma atitude positiva! Direcionar sua equipe, sempre visando atingir uma meta comum. Essa pessoa deve mostrar ao time que o “ponto de conforto” está na entrega de valor ao cliente e não na justificativa do insucesso ao final de um ciclo de trabalho! Pois sabemos que a melhor cobrança é aquela que vem de dentro para fora e não ao contrário. E o time que se cobra é porque está comprometido com o resultado de seu esforço!

Entendo que um líder servidor não deve ser um cara teórico, mas sim prático. E para ser prático, esse precisa estar bem informado de tudo que está ocorrendo no decorrer dos trabalhos! Portanto, fazer da comunicação em sua equipe uma prática diária e com hora marcada para acontecer é primordial. Sim! Esse cara terá que se comprometer e ser cobrado por estar informado sobre tudo que acontece! Em Scrum, essa prática é chamada de daily meeting.

Sem mais delongas e indo direto ao ponto, quando se decide utilizar Scrum, algumas práticas propagadas pelo método devem acontecer impreterivelmente! Dentre elas o tal encontro diário da equipe e o acompanhamento dos trabalhos em um canal comum e visível para todos do time, por meio de um quadro Kanban, devem ser utilizados.

Isso por si só, já é Scrum. Essa é a raiz do método, o DNA, onde tudo começa… Sem essas duas práticas ou com apenas uma delas, estamos fazendo o temeroso Scrumbut. Ou seja, “Aqui em nossa equipe utilizamos Scrum, mas…”. E tenha certeza que esse “mas”, geralmente, esconde os problemas que a própria prática do Scrum traz à tona.

E você sabe por quê? A resposta é simples: Quem quer se expor? Problemas geram exposição e quando mostrados, geram desconforto. Será que agora faz sentido o início desse texto, quando foi dito que a área mais resistente à implantação e uso de Scrum é a própria área de TI?

Dessa maneira, até quando iremos nos esconder por trás de nossos próprios erros? Para você (é, você mesmo) que esconde seus erros, está sendo honesto consigo ou está indo trabalhar apenas para bater ponto? Está sendo honesto com seu líder, com seu chefe ou com quem lhe paga o almoço? Se você não assume seus próprios erros, como fica seu propósito profissional? Temer a exposição do erro é um ato de salvação do emprego ou de covardia? No final das contas, você tem medo do que? De errar ou de aprender?

Pondo um ponto final nessa conversa, desde já, entendo que o ultimo parágrafo, até para quem escreveu, causou certo desconforto!

Acredito que o debate é o início para uma boa comunicação. A exposição do trabalho perante o time de projeto e a pontuação de suas atividades pode parecer ruim num primeiro momento, mas quebrado o preconceito, não tenha dúvida que facilita a vida de todo mundo.

Segundo o educador Benjamin Bloom, em sua teoria da taxionomia educacional, o mesmo propõe que o aprendizado efetivo se dá com o erro, pois quando esse ocorre, teoria e prática se fundem, fazendo com que o resultado dessa fusão se transforme em conhecimento!

Portanto, errar não é demérito! Mas empurrar ou escondê-lo é sim, uma grande hipocrisia! Por fim, muito mais do que uma (auto) crítica, afinal também trabalho em TI, convido todos para uma ultima reflexão. Quando desligar sua máquina ao final de mais um dia de trabalho, responda a essa pergunta: “O que você veio fazer aqui hoje?”

SUGESTÃO DE LEITURA:
O Monge e o Executivo – Uma história sobre a essência da liderança
James C. Hunter

http://pt.wikipedia.org/wiki/Taxonomia_dos_objetivos_educacionais