auto-organização

Está lá nos princípios do Manifesto Ágil:

The best architectures, requirements, and designs emerge from self-organizing teams.

Muitas implementações de modelos como o CMMI definem um processo-padrão, em que são estabelecidos papéis, atividades, etapas, documentos, etc. Apesar de indicar a necessidade de adaptação do processo-padrão para cada projeto, na prática esses modelos, através desse padrão, exercem uma forte influência no processo que é instanciado. Portanto, podemos dizer que há nesse caso um modelo organizacional que impõe às equipes uma forma de organização.

Os agilistas entendem que isso é ruim, que o melhor é que as equipes se auto-organizem, que definam seus próprios processos, seus próprios papéis, suas próprias atividades, etc. E isso é realmente fácil de aceitar. Desenvolvimento de software é uma atividade intelectual. Como qualquer outra atividade intelectual, não faz muito sentido impor um processo de trabalho. Imagine a imposição de um modelo de trabalho a uma equipe de escritores, de compositores, de arquitetos, de publicitários… Estabeleça metas e deixe que sua equipe se organize da forma que melhor julgar.

Há quem enxergue nisso uma anarquia completa, uma desvalorização peremptória de processos. Isso é um erro crasso. Agilistas valorizam sim processos. Isso fica claro no Manifesto:

We have come to value individuals and interactions over processes and tools. While there is value in the item on the right, we value the item on the left more.

A diferença fundamental é o olhar que se dá a processos. As próprias equipes são responsáveis por seus processos. Não há imposição:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Um outro erro comum é achar que os agilistas são niilistas quanto a processos, ou que se deve partir do nada e deixar que as equipes construam naturalmente seus próprios processos. Esse mito nasceu da proposta dos agilistas de simplificação drástica dos processos tradicionalmente estabelecidos. Mas isso definitivamente não quer dizer que se deve partir do nada. O ideal é partir de um modelo estabelecido, como o Scrum, e ir adaptando ao longo do tempo. Aqui na Fortes por exemplo indicamos o XP. Mas todas as equipes já realizaram suas adaptações. Hoje somente uma delas trabalha com programação em par de forma sistematizada, por exemplo.

E o autogerenciamento?

Curiosamente, pelos menos nas listas nacionais, mais se fala em autogerenciamento que em auto-organização. Esses conceitos, apesar de parecidos e “intersecionados”, são diferentes. Autogerenciamento implica em auto-organização. Mas o contrário não é verdade. Autogerenciamento é a inexistência de um gerente controlando o processo. Auto-organização é a inexistência de uma força externa à equipe impondo um modelo de trabalho. Autogerenciamento requer equipes e membros maduros. Auto-organização, não necessariamente (apesar de aconselhável).

Apesar de serem conceitos diferentes, e apesar do Manifesto não mencionar explicitamente o autogerenciamento, isso não quer dizer que não se deve buscá-lo. Em desenvolvimento de software, como em qualquer outra atividade do conhecimento, o ideal é construir equipes autogerenciadas. Para mim, um dos objetivos do Scrum Master deve ser se fazer desnecessário. Esse estado representaria o autogerenciamento.

Ainda assim, mesmo que toda a comunidade ágil fale em autogerenciamento, mesmo que a utilização de métodos ágeis levem à construção de equipes autogerenciáveis, não me sinto confortável de dizer que é um conceito diretamente suportado pela filosofia ágil.

·

·

atualização [07/08/2009]

Sugiro fortemente a leitura do comentário do Fábio Akita.