Por que as equipes autogerenciáveis são tão importantes

Como equipes autogerenciáveis podem ser a melhor opção para seu projeto

Quando tornamos o gerenciamento de tarefas complexas o mais próximo possível do trabalho (ou seja, capacitando equipes autogerenciáveis), nos preparamos para o sucesso.

Eis uma situação que me deparo com novas equipes Scrum o tempo todo:

O trabalho deles é complicado, você vê; há todas essas dependências para cada item do backlog a ser implementado, onde cada tarefa precisa de alguém com uma habilidade especial. Nesse sentido, temos que agendar como cada pessoa com a habilidade correta terminará cada tarefa em uma determinada ordem, de modo que tudo isso seja devidamente planejado e gerenciando em cada sprint.

Você também pode gostar: A importância dos líderes ágeis

Sim, eu sei que isso não é pouco.

Antes que você perceba, há gráficos de Gantt nas paredes e as pessoas estão chamando outras pessoas de “recursos”. Esta é a razão pela qual eu mantenho minha medicação para enxaqueca sempre à mão.

O problema aqui é que a primeira afirmação feita aqui é absolutamente verdadeira:

Implementar um novo recurso em um sistema complexo é complicado e certamente há mais fatores envolvidos do que qualquer pessoa possa gerenciar de forma eficaz.

Equipes autogerenciáveis rumo à vitória

Felizmente, a solução é bastante fácil: trazer a gestão dessa complexidade o mais próximo possível do trabalho, o que na verdade significa remover o gerente do projeto e permitir que a equipe decida por si mesma como o trabalho deve ser feito.

Porém, logo que isso comece a ser realizado começará também a encontrar impedimentos para a equipe realizar seu trabalho .

O mais importante deles é que muitos novos recursos e bugs precisam de mais do que apenas uma única pessoa para completá-los; no mínimo, você precisará de alguém para codificá-lo e outra pessoa para testá-lo, mas também pode precisar de alguém para modificar um banco de dados ou codificar uma interface do usuário ou ainda criar gráficos e até mesmo escrever um arquivo de ajuda.

Para ser claro, eu realmente não concordo com a abordagem de classificar os desenvolvedores por competências específicas.

Eu sinto que um desenvolvedor deve ser capaz de codificar algo em um aplicativo do começo ao fim, independentemente de qual parte do aplicativo precisa ser modificada.

Isso torna o desenvolvimento muito mais fácil – um recurso complexo pode ser desenvolvido por uma única pessoa e a única razão pela qual outra pessoa pode ser necessária é para testes ou programação em pares .

Percebo que isso nem sempre é possível em todas as organizações, então convido você para o meio-termo: a equipe autogerenciável e multifuncional.

Melhor dos dois mundos

Equipes multifuncionais são aquelas que incluem tudo o que é necessário para implementar qualquer item de backlog do início ao fim, incluindo testes. Isso significa que a equipe será composta por designers de interface do usuário, desenvolvedores de back-end, administradores de banco de dado (se for o caso) e, definitivamente, testadores.

Auto-organização significa que a equipe decide, como um grupo, como implementar esses itens do backlog. Isso significa que, se um recurso foi iniciado por Joe, o desenvolvedor de interface do usuário, mas ele precisa de algo alterado por João, o DBA, tudo o que ele precisa fazer é dizer a João para fazer essa alteração quando tiver uma chance, sem agendamento complexo, apenas indivíduos e suas interações fazendo as coisas acontecerem.

Agora, para que isso funcione, você precisa de muita colaboração entre os membros da equipe . Por favor, note que isso não significa que os desenvolvedores gastem mais tempo trocando e-mails; significa que eles passam mais tempo interagindo de fato, de preferência com uma comunicação real face a face.

Em muitos casos, muito dessa conversa colaborativa será feita durante a reunião diária, enquanto os desenvolvedores conversam sobre o que estão planejando para o dia e seus impedimentos; como um Scrum Master, você deve permitir e promover que os desenvolvedores, durante a reunião, planejem com quem se unirão para concluir seu trabalho, mas não tanto a ponto de tornar a reunião mais longa do que deveria.

Acostume-se com a frase: “Vocês dois devem ser capazes de resolver os detalhes após a daily, vamos continuar”.

Além disso, tente evitar que a equipe planeje seus planos individuais com mais de um ou dois dias de antecedência; mais do que isso e os planos tornam-se nebulosos.

Você também pode considerar algumas outras opções para aumentar a colaboração (e, portanto, a capacidade da equipe de se auto-organizar) removendo as paredes e permitindo que a equipe trabalhe em uma única sala sem separação. Dessa forma, se um desenvolvedor precisar de outra pessoa para uma alteração ou tarefa específica, ele poderá simplesmente pedir sem ter que visitar seu escritório.

Ao fazer isso (ou ao decidir sobre as equipes em geral), lembre-se do tamanho da equipe individual – uma equipe maior que nove pessoas começará a achar difícil se comunicar como um grupo de forma eficaz e você começará a dificultar a colaboração em vez de ajudá-lo.

O tamanho ideal da equipe é de 10 pessoas incluindo o PO e o SM e o mesmo deve valer para as outras equipes.

Finalmente, nunca é demais encorajar os membros da equipe a se tornarem multifuncionais como um todo.

Apresente a equipe para a programação em pares. Cabe a eles adotá-la ou não e até modificá-la em algo que se adapte à cultura de sua própria equipe, mas quanto mais eles puderem ver o código fora de sua própria especialidade, mais fácil será para sua equipe assumir trabalhos complexos.

Pergunta para equipes autogerenciáveis

Os métodos ágeis tentam evitar o impacto gerencial negativo nas equipes para promover a capacitação dos funcionários, mas o que você deve fazer se uma equipe não estiver funcionando como deveria?

Tente este experimento mental.

Você é um gerente de desenvolvimento de software. Você aprende sobre ágil e acha que é bom. Você adota o ágil e transforma todas as suas equipes em equipes autogerenciáveis.

A maioria de suas equipes trabalha bem. A produtividade aumenta, as pessoas são mais felizes. Eles organizam seu próprio trabalho. Ocasionalmente, as equipes vêm até você e dizem que gostariam de mais pessoas na equipe. Desde que eles possam comprovar isso com evidências de que são produtivos e agregam valor, e que adicionar mais membros aumentará o valor que eles entregam, eles podem expandir.

Mas, uma equipe não tem o desempenho esperado. Eles não atingem a produtividade das outras equipes e não demonstram o valor que outras equipes entregam.

Pergunta: Você intervém?

Se você intervir, você não está permitindo que eles se auto-organizem, você está bancando o péssimo gerente.

Se você intervir em uma equipe, o que as outras equipes pensarão?

Talvez não seja tão claro assim. Talvez a equipe esteja tendo um bom desempenho, mas fica claro que apesar disso não estão melhorando como as outras equipes.

Pergunta: Como você estimula a equipe a passar para um nível de desempenho mais alto?

E se quando você os desafiar sobre coisas como programação em pares, honrar prazos, talvez velocidade previsível entre outras ações, eles lhe disserem que tentaram essas coisas, ou pelo menos falaram sobre elas, e decidiram que isso não é bom para eles.

Pergunta: O que você faz se eles se auto-organizam para não fazer as coisas que você esperava que fizessem? Coisas que você acha que podem melhorar o desempenho?

(Potencialmente, se você permitir que uma equipe se auto-organize, eles podem até começar a solicitar documentos de requisitos completos antecipadamente, eles podem resistir a solicitações de mudança.)

Agora suponha que, em vez de jogar como um grande mau gerente, você jogue como facilitador um Uber-Scrum-Master. Vá até a equipe e diga: “Acho que essa equipe poderia ter um desempenho melhor, gostaria de ajudá-los a melhorar”.

E alguém da equipe responde: “Você poderia nos dar um exemplo de quando você acha que poderíamos ter um desempenho melhor?”

Agora você tem uma instância específica em sua mente onde as outras equipes (as equipes de desempenho) pensam que este está errado. Você diz a eles? Dizer a eles é negativo, dizer a eles pode torná-los defensivos, dizer a eles realmente faz você parecer um grande gerente ruim.

Você pode contratar um Agile coach, Scrum master ou algo assim e pedir a eles que façam essas perguntas e façam essas mudanças. Mas isso não é apenas delegar? Você ainda é o poder por trás da ação.

Você poderia ir às outras equipes e pedir-lhes para desafiar a equipe com baixo desempenho e levantar preocupações diretamente, mas isso pode ser visto como manipulador, e agora você está interferindo em várias equipes. Você está permitindo que eles se auto-organizem?

Agora suponha que as coisas piorem. A empresa perde dinheiro e os acionistas pedem demissões.

Você comunica isso às equipes e pede voluntários? – você pode encontrar problemas de direito trabalhista aqui.

Você pede a todos (inclusive você) que façam um corte salarial?

Suponha que ao analisar os números você descobriu que era a equipe de baixo desempenho que estava arrastando todos para baixo, e cortar toda a equipe poderia devolver o lucro. Você deve pedir às equipes que façam isso elas mesmas? Ou você faz isso?

Se a equipe analisasse os números, a equipe com baixo desempenho decidiria se oferecer para redundância? Seria justo que você – ou as próprias equipes – decidissem cortar uma pessoa de cada equipe?

Resumindo: se você tem uma equipe onde o desempenho não é satisfatório, o que você faz?

Suponho que o ideal seja que alguém da equipe, provavelmente uma pessoa do tipo proprietário do produto/analista, analise regularmente o benefício fornecido pela equipe e o custo da equipe. Se os benefícios ficarem abaixo do custo e a equipe não puder elaborar um plano para alterá-lo, os membros da equipe solicitarão a dissolução. Mas alguém já viu isso?

Faço essas perguntas porque não sei as respostas. São perguntas como essa que aumentam meu ceticismo sobre equipes autogerenciáveis, ou melhor, me fazem ver limites no modelo.

Acho difícil imaginar qualquer equipe se oferecendo para se dissolver. Ah, pode haver a estranha história de equipes fazendo isso, mas acho difícil imaginar que essa seja a norma. Acho mais fácil imaginar equipes ficando mais defensivas e procurando explicar suas falhas por referência a outras pessoas (estou evitando a palavra “culpa”).

Arie de Geus em  The Living Company  diz que as empresas, e por extensão as equipes, são seres vivos que existem para continuar sua própria existência. Nos países capitalistas, os mercados acabarão forçando a saída de empresas de baixo desempenho. No ecossistema fechado dentro de uma empresa como replicamos esse mecanismo?

Vejo limites em equipes autogerenciáveis: Um dos papéis da gerência é determinar esses limites e agir dentro dos limites.

Por fim, execute este experimento mental novamente, mas desta vez imagine que você (o gerente esclarecido) optou por se demitir depois de configurar as equipes. As perguntas ainda permanecem, os problemas ainda existem, mas remover o gerente remove a última pessoa que poderia agir.

Acredito que se você compartilhar este texto com seu time vocês chegarão em conclusões maravilhosas.

Lembre-se: não existe modelo fantástico e ideal. O que existe sempre é a adaptação e um olhar crítico sobre receitas que parecem fáceis e milagrosas. Nunca perca de vista a melhoria continua e a busca de valor.

No comments yet.

Leave a comment

Your email address will not be published.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Pular para a barra de ferramentas