Que fique claro: não se “instala” agile

Yoda: Do or do not, there is no tryAlguns cases reportam que o Scrum e/ou a agilidade foram capazes de levar as empresas que passaram a utilizá-los a um estado de hiperprodutividade. Tais cases falam de melhorias de até 400% na produtividade.

Um potencial cliente me questionou quando alcançaria o dobro de produtividade. Ele estava realizando o planejamento do seu departamento e queria saber quando, usando Scrum, ele atingiria a marca de 200%.

É natural que um gestor  se preocupe com esse tipo de questão. É natural que pessoas nessa posição busquem entender o que vale a pena aplicar, quanto vai custar, quando é o payback, qual a taxa de retorno, e outras questões semelhantes. O problema no questionamento é que a pergunta foi feita como se houvesse uma comparação de produtos. “Qual produto vai me dar mais retorno no meu ambiente, Mercurial ou TFS?” A pergunta é válida quando é feita comparando uma ferramenta de Source Control e outra que também faz isso. Podemos argumentar sobre as vantagens e desvantagens de cada uma no ambiente, podemos falar de valor agregado, etc. E a troca de uma ferramenta de source control, ainda que dê um pouco de trabalho, é razoavelmente simples. Simplificando bastante, basta instalar a nova ferramenta, migrar tudo, e desativar a ferramenta antiga. Nenhum comportamento precisa mudar. Isso não funciona com uma metodologia de desenvolvimento. Isso não funciona quando temos que realizar uma mudança cultural fundamental para que uma nova metodologia seja aplicada.

Que fique claro: não se “instala” agile.

Assim, a pergunta sobre atingir 200% de produtividade é irrelevante. É simplesmente impossível fazer essa conta, porque esse marco pode nunca ser atingido, ou, dado um ambiente devidamente cultivado e propício à realização das melhorias necessárias, acontecer relativamente rápido. Ou algo entre estes dois extremos pode acontecer. Um projeto de mudança cultural baseado em agile tem uma grande incerteza, e qualquer estimativa, no fim das contas, fica irrelevante. Como tudo que é agil, a mudança deve ser iterativa e incremental. É possível estimar considerando as diversas variáveis apresentadas pela empresa, mas é bom lembrar que estimativas são chutes, por definição.

Usar agilidade requer predisposição à mudança.

Assim, preparei uma rápida resposta padrão para o gestor que quer “instalar agile”. Fiquem a vontade para replicá-la ou repassá-la aos seus gestores, clientes, ou quem quer possa aproveitá-la. A ideia é passar uma ideia central, então uma adptação à sua realidade sempre vai caber. A resposta objetiva fazer os que buscam resultado rápido sem mudar de verdade que nem tentem usar agile, evitando que depois, como acontece tanto, fiquem reclamando e dizendo que tentaram e não funciona.

Caro buscador de uma bala de prata,

Entendo que, como gestor, ao buscar um processo ágil, você esteja buscando que sua produtividade melhore. Quem não gostaria de escolher um novo processo e ver tudo melhorar automaticamente? No entanto e infelizmente, o seu time é composto de pessoas, e isso significa que o comportamento dele não é determinístico, assim como o seu próprio.

Nós podemos ajudá-lo a entender como o Scrum funciona, e ajudá-lo a utilizar o Scrum na sua empresa, algo que tem o potencial de mudar para sempre como sua empresa funciona. Pode ser que durante este processo você descubra outra bala de prata que lhe pareça mais atraente e abandone o Scrum. Muitos meses se passam até que a média das empresas perceba que o Scrum não vai fazer o seu trabalho, e que elas ainda precisam resolver os próprios problemas.

As empresas que realmente estão dispostas a mudar seu comportamento relatam melhorias na previsibilidade das suas entregas, na qualidade dos seus produtos, e no relacionamento dos times e da empresa como um todo. Tais empresas também costumam reagir mais rápido à mudanças, inovam mais e tem um turnover menor.

No entando, as empresas que apenas dizem estar usando Scrum mas mantém velhos comportamentos, hábitos e processos são muito mais comuns do que as que recebem os benefícios citados. Mudar velhos hábitos sempre é difícil. Trabalhar dificuldades técnicas e políticas a caminho de uma melhora genuína é difícil. O Scrum e a agilidade em geral exigem estas mudanças. Assim, a maioria das empresas falha ao adotar e Scrum ou outro framework ágil, porque precisam confiar em seus funcionários, entender que eles estão fazendo o melhor ou buscando chegar lá, melhorar suas práticas de engenharia, e enterrar egos e pessoas com comportamentos políticos nocivos.

Sendo assim, se você não quiser passar por essas mudanças para alcançar os benefícios citados não use Scrum ou outro framework ágil. Se quiser genuinamente melhorar e está disposto a passar por tais dificuldades até que os benefícios comecem a aparecer, estamos à disposição.

Usem à vontade. Como dizia Yoda, “do or dot not, there is no try”.

  • Pingback: Que fique claro: não se “instala” agile

  • Rodrigo Vidal

    Excelente post Gigio!

  • Pingback: Tweets that mention Que fique claro: não se “instala” agile | Blog Lambda3 -- Topsy.com

  • Lucas S.

    Não gostei.

    Se você não consegue mensurar o ganho que terá em aplicar uma metodologia como conseguirá convencer uma empresa que é melhor usar scrum ou qualquer outra que seja? Ficou muito vago seu ponto de vista. Tá mais para um “se quiser bem, se não quiser faz o que vc quiser..”.

    Não gostei..

    • http://blog.lambda3.com.br/L3/giovannibassi/ Giovanni Bassi

      Lucas, essa resposta vale pra qualquer projeto. Veja o link que está no post sobre estimativa.
      Que é melhor é fato, há vários cases mostrando isso.
      E lembrando: não queremos convencer ninguém. Fato é que a maiorias das empresas sofre com os processos tradicionais. Eu não preciso que elas mudem. Elas que precisam mudar. Eu jamais vou dizer pra uma empresa que funciona bem com o processo tradicional que ela deve mudar. Só que esta empresa não existe. Ela só acha que existe.

      Em resumo: até pode-se fazer uma análise, mas somente se a empresa quer mudar é que encontrará benefícios. E estimativas são inúteis num processo de mudança cultura.

    • Ricardo Serradas

      Tive essa discussão hoje no escritório.

      Não há o que mensurar. São dois mundos diferentes. O que tem que deixar bem claro para o cliente é algo como, por exemplo (seguindo minha discussão de hoje, quando falávamos de escopo):

      O que você quer?

      - Quer poder colaborar com o projeto contínuamente, participar da sua evolução, aprender junto com o time e repensar o caminho correto para o sucesso de forma constante, receber entregas parciais já agregando valor ou…

      - Quer fechar um escopo, sumir e reaparecer só daqui a 6 meses e, se identificar que pediu algo errado, terá que abrir uma change request e será cobrado adicionalmente?

      Entende? É expor ao cliente o que virá pela frente, dependendo do caminho que ele escolher. Como, por exemplo, podemos mensurar o quão produtivo será se o cara for um cliente presente? E se ele estiver junto do time todos os dias e não agregar valor nenhum?

      É como sempre falamos, estamos lidando com pessoas e, quando falamos de pessoas, não há exatas.

      []‘s

    • http://www.lambda3.com.br Felipe Rodrigues

      Pode mensurar o ganho de outras formas. Agile não busca aumentar a produtividade. Não tem pretenções de dobrar o quanto cada desenvolvedor faz.

      O problema não é querer mensurar os ganhos, o problema é mensurar os ganhos pela ótica errada. Veja esse comentário: http://blog.lambda3.com.br/2011/01/que-fique-claro-nao-se-instala-agile/#comment-137966072

  • Alessandro

    Não gostei. Não apresentou nenhum argumento convicente. Passou mais a idéia de ser superior que o cliente, prepotência.

    • http://blog.lambda3.com.br/L3/giovannibassi/ Giovanni Bassi

      Alessandro, que fique claro que eu não quero convencer ninguém. Cada um faz software como quer. O argumento do post é não vender agile para quem quer continuar no comando, controle e ineficiência.
      Prepotência também pode ser argumentada para o outro lado, que insiste em manter processos ineficientes para promoção política.

    • http://www.lambda3.com.br Felipe Rodrigues

      Olá Alesandro,

      Não veja essa atitude como prepotência, mas sim como uma tentativa de educar o cliente em relação ao agile. Os argumentos são inúmeros e repetitivos. Agile não é um processo de produção. Envolve muita mudança cultural. Seu objetivo não é aumentar a velocidade do time.

      Os conceitos que estão por trás da frase “Que fique claro: não se “instala” agile.” são muitos e complicados.

      Um exemplo, quando se instala Agile não se buscar aumentar a produtividade. Busca-se principalmente reduzir a quantidade de trabalho para atingir um objetivo. Dessa forma, podemos ser mais lentos e mesmo assim entregar mais valor. Mas isso também não é uma regra.

      Quanto à parte da prepotência, algumas vezes é preciso ser duro para romper alguns costumes antigos e nocivos à prática do agile. Um consultor precisa saber como e quando ser duro com um cliente e quando pode ser mais brando.

  • http://twitter.com/fabriciocastela Fabrício Alves

    Gostei …. porem não vejo aplicando este framework em uma equipe, que na sua maioria, compreende de Jr ou estagiário. Hoje tenho este problema na minha empresa … e os diretorem querem apenas os benefísios do framework e não os comprometimentos que a mesma necessita. Neste caso como fazer? Não fazer!

    • http://www.lambda3.com.br Felipe Rodrigues

      Fabrício,

      Com desenvolvedores ruins, você não corre o risco de desenvolver software bom. Com desenvolvedores inexperiêntes você o software será no mínimo “inexperiênte”. Precisa nivelar o time, independente de qual metodologia você quer aplicar.

  • http://saulocarvalho.net Personal Saulo

    O post é bacana só que de novo batemos na tecla de como usar ou não agilidade. Na boa vamos avançar. Aposto que o Giovanni, tem zilhões de outros assuntos para postar e compartilhar para podermos ter outros tipos de discussões e conclusões. Parece que ainda não saímos das premissas do Agile e sempre esbarramos nas pessoas que não entendem que usar ou não agile é uma questão de necessidade da empresa/projeto. Move on !!

    • http://blog.lambda3.com.br/L3/giovannibassi/ Giovanni Bassi

      Saulo, fazemos isso direto. Viu os posts recentes sobre gestão de risco, equilibrio pcp, etc?

      • http://saulocarvalho.net Saulo

        Na verdade eu não os li, mas o meu ponto é que estamos quase sempre encontrando posts assim. E posts assim geram sempre a mesma discussão, sempre gira em torno de “Na minha empresa o Agile não funcionou, logo o agile não serve”, e acaba virando um tipo de “Guerra Santa” . Acho que discussões assim já “deram o que tinham que dar”.

        • http://www.lambda3.com.br Felipe Rodrigues

          Ola Saulo,

          Há muitas pessoas que não entenderam isso. Há públicos diferentes e
          esse tipo de post é útil para vários de nossos clientes.

          • http://saulocarvalho.net Saulo

            Sim acredito que para pessoas que não conheçem é muito útil. O ponto em questão são discussões q não acrescentam muita coisa. JMP [Just my opinion]

        • http://www.lambda3.com.br Felipe Rodrigues

          LinkedIn
          ————

          I’d like to add you to my professional network on LinkedIn.

          - Felipe Rodrigues

          Felipe Rodrigues
          Director at Crafters Software Studio
          Campinas Area, Brazil

          Confirm that you know Felipe Rodrigues
          https://www.linkedin.com/e/6ofmdk-gmu1dooh-1e/isd/2748101438/fg8NqnH_/


          (c) 2011, LinkedIn Corporation

        • http://www.lambda3.com.br Felipe Rodrigues

          LinkedIn
          ————

          This is a reminder that on April 23, Felipe Rodrigues sent you an invitation to become part of his or her professional network at LinkedIn.

          Follow this link to accept Felipe Rodrigues’s invitation.

          https://www.linkedin.com/e/6ofmdk-gmyp93ho-1t/doi/2748101438/fg8NqnH_/gir_518990707_0/EML-inv_17_rem/

          Signing up is free and takes less than a minute.

  • Luiza Rodrigues

    Olá Giovani,

    Já faz algum tempo que acompanho o seu Blog, e não é a toa. Vocês mantém o foco na qualidade do conteúdo e na clareza das informações. Parabéns para toda a equipe pelo sucesso do blog, para isso é preciso muita dedicação e foco.
    Aproveitando o tema Agile…
    De tanto usar Desenvolvimento Ágil, a equipe GPE – Gestão de Processos Estratégicos E Tecnologia Da Informação criou a primeira ferramenta web de Scrum brasileira!
    Demos o nome de Scrumhalf (www.scrumhalf.com.br) e gostaríamos de contar com a sua opinião – existe um plano gratuito que dá para testar a vontade.
    Qualquer dúvida ou problema é só falar!
    Ok?

    Grande Abraço,
    Equipe GPE.