Concrete Logo
Hamburger button

Ágil como MacGyver no Caipira Ágil – parte 1

  • Blog
  • 27 de Agosto de 2012
Share

 

Sábado passado 18 de agosto estive na UNICAMP em Campinas no Caipira Ágil. Foi muito bom. Gosto do ambiente de faculdade, me faz voltar no tempo. Contando meus dois anos e pouco do curso de mestrado, vivi assim por mais de 7 anos. Eventos deste tipo são mais descontraídos. O coffee break foi ao ar livre como mostra a foto abaixo:

Coffee break

 

Introdução

Fui lá falar de um assunto fruto de muita conversa e um bocado de observação. Sinto em muitos bons desenvolvedores um certo tédio e até mesmo descrédito só de ouvir falar em agilidade. E alguns deles já foram muito entusiasmados. O que está acontecendo?

Inevitável não lembrar do manifesto ágil:

    Indivíduos e interação entre eles mais que processos e ferramentas
    Software em funcionamento mais que documentação abrangente
    Colaboração com o cliente mais que negociação de contratos
    Responder a mudanças mais que seguir um plano

Este manifesto veio de gente experiente cansada de ver software sendo entregue aos trancos e barrancos a clientes geralmente insatisfeitos. Eu vivi aquela época, ninguém me contou.

Uma vez entrei no escritório de uma empresa que prometia ser um potencial enorme cliente para mim. Ao dar o cartão da minha empresa falando em desenvolvimento de sistemas, fui recebido com a frase:

    “Ah, então você desenvolve sistemas. Então você é vigarista!”

Este era o conceito que nossa classe tinha lá pelos meados dos anos 90. Tudo fruto de muitos sistemas que não atendiam às reais necessidades dos clientes.

Eu mesmo entreguei um sistema ERP feito por minha empresa lotado de features pedidas pelo diretor que participou de todas as entrevistas de análise. Depois fui descobrir que os funcionários usuários da solução automatizada, não usavam metade do que o sistema tinha. Eles faziam muitas coisas na mão por fora do sistema. Fazer coisas desnecessárias era coisa comum nos tempos do waterfall. Justamente o oposto do conceito de MVP.

 

Qual o problema agora? Porque o “ágil” anda sendo questionado?

É claro que isto poderia ser assunto de um estudo muito mais sério e com alguma base científica. Aqui falo apenas de impressões pessoais. Infelizmente não consegui abordar o assunto de forma sucinta e então desdobrarei em 2 posts grandes.

Todo mundo agora se diz “ágil”. O “ágil” agora é mainstream. Poucas empresas ainda se orgulham de usar práticas e processos burocráticos. Mas o fato de se dizer ágil não basta.

É preciso lembrar que o desenvolvedor é uma pessoa, que precisa ser motivado ou ao menos reconhecido, para fazer um trabalho intelectual de melhor qualidade.

É claro que não tratar o desenvolvedor como pessoa (ou tratar como sei lá o quê tipo peça, móveis e utensílios ou recurso) é herança dos antigos modos de gestão top down. É coisa comum nas empresas que empregam métodos de gestão sem diferenciar trabalho braçal repetitivo de trabalho intelectual.

Há um monte de livros sobre desenvolvimento ágil mas poucos sobre gestão ágil (só estou lembrando agora do Management 3.0). Muitas das empresas que se dizem ágeis, empregam métodos de gestão que já falhavam com pessoas antes do manifesto ágil e que continuam a falhar, mesmo usando no desenvolvimento práticas e processos ágeis. Mas não vou discutir agora os modos de gestão ágil porque este assunto por si só já mereceria algumas páginas. Vou me ater na questão das práticas e processos usados no desenvolvimento dito ágil.

Alguns gestores de empresas “ágeis” tentam transformar em processos obrigatórios alguma recomendação que leram em algum livro como se todos os individuos fossem iguais. Estes gestores dão a impressão que acreditam no modelo bala de prata, frameworks de referência ou soluções do tipo “one size fits all”.

Eu, talvez pelo meu passado de consultor que me exigia analisar casos isolados, advogo o uso do raciocínio e do discernimento. Isto significa escolher dentro do arsenal de recomendações dos estudiosos, isto é, dentro do cinto de utilidades composto pelo que se aprende nos livros e palestras, as práticas e rituais de processos que aparentam ser, ou que o grupo tem mais aptidão para usar, o conjunto mais adequado ao projeto.

No meu ponto de vista, devemos agir assim em cada projeto e para cada grupo de pessoas, com o objetivo de conduzir ao melhor resultado final, isto é, software funcionando em uso pelo cliente no menor espaço de tempo possível (MVP sempre em mente).

 

A apresentação

O propósito foi debater com a platéia algumas práticas e processos ditos ágeis.

    – Eu queria saber se todo mundo adota todas as práticas.
    – Saber se segue todos os processos SEMPRE.

É principalmente esta palavra SEMPRE que mais me incomoda. Fazer algo sempre igual pressupõe trabalho repetitivo, coisa não muito comum no nosso dia a dia. E aplicar processos sem considerar as pessoas contraria a primeira frase do manifesto ágil.

Os slides abaixo contém um preâmbulo que fiz antes de iniciar o papo com a platéia.

O papo com a platéia será o assunto do próximo post
 

Um comentário sobre os slides que falam de gerentes

Fiz questão de incluir estes slides pela repercussão do tema democracia organizacional e a paralela campanha contra os gerentes iniciada por nossos amigos da Lambda3 e até referendada por outros amigos.

Antes que você se posicione contra ou a favor do que eles dizem, é bom ler os posts com as justificativas em Sim! Sem Gerentes!, em A palavra “gerente” e outros que podem ser achados facilmente no blog da lambda3. Dentro do contexto e do ambiente que construíram na empresa deles, acho os argumentos bem razoáveis.

Só não sei se o modelo pode ser replicado a torto e a direito. Acho muito bom que estejam carregando esta bandeira e colocando o assunto em discussão. Deve sair alguma coisa boa mesmo para aqueles como eu, que ainda acreditam na necessidade de um gerente (não do tipo comando e controle).

Citei lá em cima o livro Management 3.0 do Jurgen Apello. A história no prefácio de como foi escrito este livro já mostra razões porque precisamos questionar os modos tradicionais de gestão. Não foi a toa este treinamento no Agile Brazil foi um dos primeiros a lotar. Você ainda ouvirá falar muito no Martie.

Mas pelo que li até agora do livro, os gerentes não estão tão ameaçados assim. É o uso de métodos tradicionais que precisa ser repensado. Os novos gerentes tém uma série de novas responsabilidades muito além do modelo comando e controle e também bem além do que pode fazer um lider técnico.

Meu depoimento

Fui gerente muito tempo, tanto nos 17 anos que tive minha própria empresa quanto depois quando deixei de empreender justamente para assumir cargos de gerência. Fui gerente também daquele tipo PMP, Piloto de Microsoft Project. Este tipo eu concordo que não há mais razão de existir (apesar de saber que ainda existe). E concordo que gerente do tipo “comando e controle” pode desestimular a criatividade e prejudicar o resultado final do produto.

Mas dentre as funções que tinha geralmente gerenciando vários times de projeto ao mesmo tempo, uma delas era ouvir as broncas do diretor que jogava em cima de mim todas as reclamações dos clientes. Ele me pagava, entre outras coisas, para ouvir seus desabafos.

Eu tinha obrigação de motivar a equipe para produzir o máximo. Não podia simplesmente chegar na equipe responsável pelo tal projeto reclamado e dizer que o cliente estava fulo da vida ameaçando romper o contrato. Repassar o desespero não ajudaria a resolver os problemas. Afinal aquela era “a equipe” que tinha. Caso perdesse alguém, a situação só pioraria. O que fazia era justamente engabelar o time com conversas do tipo:

    “Olhem, vocês estão fazendo um trabalho legal. Mas sacumé, clientes sempre querem mais e isto é uma oportunidade da gente mostrar nosso valor. Vamos dar uma gás aqui neste quesito (o tal que o cliente meteu o pau) porque eles dizem que não está funcionando como previsto.”

Resumindo, tentava não ser apenas um proxi passando ao time a mesma bronca que ouvia do diretor. E acho que seria muito contraproducente o diretor ter que reclamar diretamente com cada time.

Outra atividade do gerente que não vejo como fazer de forma ágil em uma empresa sem gerente, é o trato das questões das relações com a empresa do tipo abonar faltas, intermediar a remoção de impedimentos que dependem de ações da diretoria e tudo o mais, que sem gerente, exigiriam contatos frequentes entre o desenvolvedor e um diretor. Nem todas as empresas tem gente especializada para fazer isto.

 
É isso… por enquanto.

 
Disclaimer: O que escrevi aqui é um pensamento exclusivamente meu e ainda em formação. Por favor comentem, critiquem, discordem. Todo feedback será bem-vindo.

E aguardem as observações oriundas do papo com a platéia no próximo post.

 
PS: Usei MacGyver no título para representar alguém que sempre foi considerado ágil justamente porque sabia agir de acordo com as circunstâncias. Não era do tipo que agia sempre igual.