Li há um tempo atrás um post do Dan Rawsthorne (CSM, CSP, CST) no blog da Danube Technologies, falando sobre como ele se sentia desconfortável com algumas afirmações ou concepções incorretas a respeito do que é efetividade (effective) e o que é eficiência (efficient). Como o post foi na época de festas, terminei perdendo o timing e não consegui traduzir nem fazer nenhum tipo de comentário no blog, mas tinha deixado o post gravado aqui para depois escrever sobre ele. Fiz uma tradução abaixo (para ver o texto na íntegra, em inglês, clique aqui):
Eu gostaria de falar um pouco sobre uma situação recorrente que encontro nos times que faço coaching e nas classes que ensino. Quando falo com as pessoas sobre Scrum (e agilidade em geral), eu invariavelmente escuto coisas como “Eu gostaria que os meus times fossem mais eficientes”, ou “Estamos usando Scrum então poderemos ser mais eficientes”, e, é claro “nós seremos mais eficientes com esse processo e economizaremos algum dinheiro, certo?”
A resposta é “não”, ou “não imediatamente”, e isso normalmente nos leva a uma conversa sobre efetividade versus eficiência. Por definição, efetividade é “produzir um forte efeito”, que em software siginifica que nós entregaremos algo usável para o negócio. Eficiência, por outro lado, é “produzir resultados com pouco desperdício de esforço”, o que é uma coisa completamente diferente, e é um conceito totalmente não-agile.
Agora, vamos olhar para o que as empresas normalmente fazem (lembre-se que você é o que você realmente faz, e não o que você diz que faz). Em minha experiência, muitas empresas estão no negócio de “deixar as pessoas ocupadas” ao invés de estar no negócio de “produzir um produto”. Isto é, gerentes entram em mais apuros por suas pessoas “desperdiçarem tempo” do que por sua organização não produzir o produto correto. Isso é uma vergonha.
Agilidade é sobre ciclos de “verificação e adaptação”, ou seja, feedback. Quanto mais feedback você recebe, mais efetivo você será, mas mais esforço será também gasto. Isso é inerentemente ineficiente — estamos sacrificando efetividade de propósito. Para poder ser eficiente com agile, você precisaria de loops de feedback que te fornecessem as respostas que você precisa o mais rápido possível, e ter o quanto mais loops de feedback como possível. E nós não sabemos como fazer isso, sabemos?
Aqui é quando aparecem frases como “falhe rápido, falhe cedo”, que é uma forma de dizer que nós gostamos de ser eficientemente ágeis, aprendendo nossas lições o mais rápido possível. Okay, e não me importaria em ser eficientemente ágil, preferiria ao invés disso ser efetivo do que eficiente. E, na minha visão, não traz nenhum bem tentar ser eficiente até que você já saiba como ser efetivo. Isto é, se você pnão consegue produzir o produto certo todas as vezes (ou virtualmente todas as vezes) então não tente adicionar eficiências ao seu processo.
Para colocar de maneira bem simples, “Waterfall é eficiente — agilidade é efetiva”, e quando nós tentamos ser eficientemente ágeis, nós terminamos por introduzir uma falsa previsibilidade no nosso processo, que no final, termina nos ferindo.
É isso por agora, meus dois centavos, Dan.
