Transição - Um exemplo de vitória de curto prazo

Bem, nesse caso considero de curtíssimo prazo.



Quando recentemente eu comecei a prestar consultoria em uma grande equipe percebi que o primeiro caminho a trilhar era o da colaboração. Caminho difícil, devido à cultura e à natureza do projeto. Essa meta envolvia, inclusive, colaboração com a área de QA.

Em cada oportunidade que eu podia falar de colaboração, eu falava. Em cada pergunta que eu podia responder com a colaboração, eu respondia. No meio de olhares céticos, rebatendo alguns argumentos, insistia pontualmente. No último mês, em cada reunião que eu era chamado a falar, comentava sobre o conceito stop to start and start to finish.

Estava dançando com o sistema. Dentre algumas mudanças, a mais importante para este texto, foi a inclusão da coluna "Caso de Teste" antes da coluna "Desenvolvimento", para que os desenvolvedores codificassem orientado aos casos de teste. Essa medida surgiu após um feedback recorrente de que cerca de 70% dos bugs eram causados pelo desconhecimento do desenvolvedor de que precisaria passar por determinado(s) caso(s) de teste.

Pois bem, todos receberam bem a ideia e duas semanas se passaram. Ontem cheguei para trabalhar e essa equipe estava em reunião em frente ao quadro. Quando eu me aproximei, tivemos o seguinte diálogo:

- Celso, estamos com uma dúvida. Se o desenvolvedor estiver de bobeira ele pode começar uma história mesmo sem o caso de teste escrito?

- Não. Mas se já existir pelo menos um caso de teste escrito, o desenvolvedor pode começar a codificação por ele e continuar conforme os outros ficam prontos.

Nesse momento eu já estava bem animado, pois seria o início de um processo de colaboração muito forte.

Continuei:

- Entretanto, vocês precisam treinar um sentimento de que cada história, desde que nasce até ficar pronta (done)  pertence ao time como um todo. É responsabilidade de todos fazer com que a história chegue na coluna "done". Não podemos ter melindre do tipo "o build terminou, falta apenas o analista de teste terminar o trabalho dele"; "Ele está me atrasando, já fiz a minha parte". Não existe mais "minha parte", pois tudo é de todos. Vocês entendem isso?

Todos disseram que sim. E foi quando um dos desenvolvedores acrescentou:

- Eu discordo até de só começarmos a desenvolver com um caso de teste. Podemos começar a desenvolver enquanto o analista de teste escreve os casos de teste. Em algum momento, vamos validar o código com os casos de teste e vamos sugerir novos casos de teste que o analista de teste não pensou inicialmente. A coisa toda pode acontecer ao mesmo tempo, só precisamos garantir que o código saia de "Desenvolvimento" passando por todos os casos de teste.

Eu fiz algumas perguntas e todas as respostas passaram por colaboração, inclusive com frases do tipo: "Colaboração, não é o que você vive falando?"

Não sei se eles perceberam, mas os meus olhos devem ter brilhado. Comentei:

- O que vocês estão propondo é a meta atual para que os times se tornem mais colaborativos. Vocês tem noção do que será necessário para isso funcionar? Do nível de colaboração e de senso de time que vocês precisarão ter não só dentro de DEV e de QA isoladamente, mas todos vocês precisarão funcionar como um time? Não tenho dúvida que propondo isso, vocês tem a maturidade para pelo menos tentar, mas quero que vocês entendam o que será necessário para aumentar as chances de sucesso. A cada atitude que demonstre falta de colaboração, vou relembrar essa reunião, estão prontos?

Todos toparam e eliminamos a coluna "Caso de Teste" do quadro.

Não existirá falha ou sucesso dessa tentativa. Apenas o fato, neste momento, de estarmos conversando sobre isso e todos terem topado pelo menos tentar, já é uma grande vitória. Demonstra grande maturidade da empresa e dos envolvidos.

As vitórias de curto prazo são essenciais para a manutenção da transição e da confiança das pessoas. No livro Leading Change, Kotter deixa claro, em um capítulo inteiro, essa necessidade.

Abaixo um gráfico da análise de Kotter:

Esta é uma tipo de short-term win que precisa se celebrada. São situações como essa que abordaremos no Change Management Brasil. Vemos as pessoas escrevendo sobre os objetivos, mas temos pouca literatura mostrando algumas formas, ainda menos com exemplos da área do trabalho do conhecimento.  O que podemos usar como argumento? Como? Quais as etapas? A importância de perceber tudo como sistema, sob efeito da teoria das redes? Como dançar com o sistema? Como e quando afrouxar a pressão para que o sistema respire e pense? É isso que queremos mostrar para os change agents (ou para quem deseja se tornar um).

E alto nível de colaboração deve ser um dos focos iniciais. Certa vez, conversando com o Felipe Rodrigues, ele me disse que ágil não funciona. O que funciona é um grupo de pessoas motivadas, comprometidas e colaborando por uma meta em comum, como um time. Não é difícil perceber que essa frase é verdadeira.

Você deve usar a cultura ágil para criar essas três qualidades nas pessoas que trabalham com você e não buscar a agilidade como um fim. Na minha visão, todos os princípios e valores que formam a cultura ágil é o meio ideal de alcançarmos motivação, comprometimento e colaboração entre todos os envolvidos. Quem trabalha com criatividade demanda um tipo de gestão diferente. Alta colaboração e ciclos curtos de feedback são os maiores ganhos da cultura ágil, na minha opinião.

Um sucesso deste tipo pode "contaminar" toda a empresa. Colaborar pode virar regra em vez de exceção.