Alguns 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”.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.