Vamos dar um tempo na série #onovogestor e falar um pouco do Manifesto Ágil numa perspectiva diferente.

Se você já conhece o Manifesto Ágil sabe que ele traz 4 valores que foram escritos de uma forma a valorizar mais os itens à esquerda do que os da direita. Logo, quando se lê: “software em funcionamento mais que documentação abrangente”, ele deve-se privilegiar software funcionando, apesar de saber que documentação ainda é necessária em alguma medida.

Muito bem, agora vamos fazer algumas análises menos óbvias:

[heading]1) Indivíduos e interações entre eles mais que processos e ferramentas[/heading]

Uma coisa pode passar desapercebida para um recém convertido: tudo passa por processos e ferramentas: desde sua chegada à empresa, batendo o ponto ou não, até seu pagamento no final do mês. Alguns são mais claros que outros; alguns mais justos que outros; outros mais coerentes que outros, mas todos estão lá.

Imagino que este valor aparece no Manifesto fazendo frente à burocracia e aos processos e ferramentas que “sempre estiveram lá” e que não eram adaptados à realidade do contexto.

Logo, minha leitura atualizada do Manifesto seria a seguinte:

Deve-se promover os processos e ferramentas que promovam interação entre os indivíduos.

Exemplos disso podem ser as ferramentas de discovery e inception, que, apesar de serem ferramentas, buscam atingir um resultado através da interação dos e com os participantes.

[heading]2) Software funcionando mais que documentação abrangente[/heading]

Eu sei que a documentação que o Manifesto se refere aqui é aquela feita antes da execução do trabalho e que busca especificar tudo antecipadamente para evitar erros. E eu concordo com essa orientação do Manifesto. Tentar prever tudo antes de começar a desenvolver é criar um lote maior do que seria necessário para iniciar os trabalho e o risco acompanha proporcionalmente.

Mas alguém poderia entender documentação de uma forma geral, como se ao final do desenvolvimento nada, ou muito pouco, de documentação fora necessária. Talvez influenciado pelo valor de interação entre as pessoas a documentação poderia ser vista como algo frio e que impede a comunicação cara a cara ou outros tipos de comunicação mais eficientes.

Todavia, eu acredito em:

Ter documentação suficiente para entregar uma solução ao cliente.

Essas minhas releituras são sutis, mas ajudam a passar a mensagem que pretendo. Isso porque, pra mim, é totalmente aceitável chegar ao final da execução de um trabalho com uma documentação abrangente. O benefício está no fato dela ter sido construída no momento certo, de forma suficiente para permitir um loop de feedback curto.

[heading]3) Colaboração com o cliente mais que negociação de contratos[/heading]

Na linha da releitura que estou sugerindo aqui para reflexão, eu colocaria:

Criar contratos que permitam a colaboração.

O valor original do Manifesto poderia dar margem para alguém entender que os contratos vigentes deveriam ser ignorados, em alguns de seus termos, em prol de mudanças oriundas da colaboração com o cliente.

Do jeito que sugeri, deixo evidente a necessidade de constar essa possibilidade de colaboração no contrato, uma vez que esta característica, que é benéfica tanto para clientes quanto para fornecedores, deveria ser uma restrição aceita por ambos antes do início do projeto.

[heading]4) Responder à mudanças mais que seguir um plano[/heading]

De forma parecida com o que disse no primeiro valor do Manifesto, seguir um plano não é algo que deveríamos fazer menos, uma vez que tudo deveria estar dentro de um plano. O problema, portanto, sempre foi não flexibilizar o plano.

Você pode olhar isso no Scrum quando ele revisa o plano a cada sprint. O plano, de fato, é ruim quando não há possibilidade de alterá-lo quando necessário. Isso requer uma gestão atenta à estas oportunidades, pois elas aparecerão.

Logo:

Deve-se ter um plano que possibilite responder à mudanças facilmente.

Creio que algumas restrições devam ajudar a equilibrar essa “flexibilidade” no plano, como questões orçamentárias, éticas, de eficiência e foco.

Lembrando que a forma de pensar Ágil não deve ser a única em sua organização. Estude e considere outros paradigmas de gestão de acordo com o seu contexto de trabalho. Veja #onovogestor.