3 Perguntas contra o Microgerenciamento no Scrum

Um dos princípios fundamentais do Agile e do Scrum é exatamente o oposto do microgerenciamento: a crença no poder das equipes auto-organizadas. É precisamente isso que torna um chefe, Scrum Master ou Product Owner que pratica microgerenciamento um problema particularmente difícil para equipes ágeis.

Encontrei três perguntas que são úteis ao lidar com microgerenciadores:

Quem?

A primeira pergunta é "Quem?". Quem sofre com o microgerenciamento? Se você é afetado pelo microgerenciamento, mas o resto do Scrum Team não, isso pode indicar que alguém está preocupado com o seu desempenho. Se for esse o caso, você precisa trabalhar no seu próprio desempenho e melhorar a percepção que esse stakeholder tem sobre você.

No entanto, se toda a equipe está sob microgerenciamento, esse comportamento provavelmente está relacionado ao próprio stakeholder.

Para descobrir se apenas você ou toda a equipe é afetada pelo microgerenciamento, anote durante um ou dois Sprints em quais coisas o microgerenciador se concentra especialmente. Registre todas as atividades de microgerenciamento para poder analisar esses dados posteriormente e identificar quem exatamente é afetado.

Quando?

Manter um registro do microgerenciamento também vai ajudar você a responder a segunda pergunta: Quando o microgerenciamento ocorre?

O microgerenciamento acontece mais antes ou depois de uma reunião? Por exemplo, o Product Owner pode sair estressado toda terça-feira da ligação com o cliente e, por isso, ter uma tendência maior ao microgerenciamento. Ou então o Scrum Master tende ao microgerenciamento no dia anterior à reunião mensal com o VP de Engenharia.

Às vezes, as pessoas também tendem ao microgerenciamento em determinados horários do dia. Um antigo chefe meu tendia especialmente ao microgerenciamento antes da primeira xícara de café.

Outras pessoas ainda tendem ao microgerenciamento em determinados momentos durante uma iteração. Talvez uma pessoa com quem você lida tenda especialmente ao microgerenciamento durante os últimos dias de uma iteração, porque começa a ficar nervosa e se pergunta se tudo será concluído. Aqui também você deve registrar essas informações para poder identificar padrões posteriormente.

Eu uso uma tabela com as seguintes colunas:

Data: A data específica (por exemplo, 8 de março de 2017). Isso geralmente não revela padrões. No entanto, permite que você revise os dados quando quiser lembrar o que exatamente estava acontecendo na organização naquela época.

Dia da semana: Em determinadas circunstâncias, o microgerenciamento ocorre apenas em determinados dias da semana (por exemplo, sextas-feiras). Por isso, você deve anotar o dia da semana.

Dia no Sprint: Para poder identificar se o microgerenciamento ocorre regularmente em um determinado momento do Sprint, anote em qual dia do Sprint o microgerenciamento aconteceu. Pode ser simplesmente "Dia 3" ou "7/10" para indicar que é o sétimo dia em um Sprint de 10 dias.

Horário: Anote também o horário (por exemplo, 10:15).

Quem foi afetado pelo microgerenciamento: Foi você, todo o Scrum Team ou um colega de equipe?

Sobre o que se tratava: Registre nesta coluna sobre o que era o microgerenciamento.

O contexto: Havia acontecimentos especiais no Sprint, no projeto ou na organização ao mesmo tempo? O microgerenciamento ocorreu logo antes ou depois de uma reunião? Qual era a reunião? E o que estava acontecendo na iteração de forma geral?

Observações: Anote aqui tudo o que você considera importante em relação a isso. A tabela a seguir serve como exemplo.

Por quê?

Depois de registrar as atividades de microgerenciamento por algumas semanas, é hora de fazer a terceira pergunta: Por que o microgerenciamento aconteceu em primeiro lugar?

Procure padrões no seu registro. Tente encontrar os gatilhos para isso.

Talvez seu Product Owner tenda ao microgerenciamento após a reunião semanal com o chefe dele.

Talvez seu superior direto tenda ao microgerenciamento no final do mês, quando precisa escrever um relatório para o chefe dele.

Com base nesses padrões, você deve tentar ter conversas significativas com as respectivas pessoas. Com grande certeza, você não terá sucesso se simplesmente disser: "Por favor, pare com o microgerenciamento!" Em vez disso, tente conversar com elas sobre o que as preocupa e, consequentemente, o que está causando esse comportamento.

Assim que conseguir identificar algumas das causas do microgerenciamento, você poderá prever e eliminar isso no futuro.

Prever e eliminar gatilhos

Se você conseguir prever comportamentos indesejados através de observação precisa, deve trabalhar na eliminação dos gatilhos. Frequentemente, isso é alcançado abordando proativamente o microgerenciador e fornecendo informações a ele.

Se seu Product Owner, por exemplo, fica regularmente estressado após a reunião semanal com o chefe e volta a cair no microgerenciamento, reúna-se com o Product Owner antes dessa reunião. Certifique-se de que seu Product Owner esteja bem informado e preparado para a reunião com o chefe.

Aborde ativamente os stakeholders propensos ao microgerenciamento e forneça as informações necessárias. Tente fazer isso pouco antes do respectivo gatilho ocorrer. Assim, você garante que essas pessoas tenham todas as informações importantes ou se lembrem delas.

No entanto, tenha cuidado para não criar novos processos trabalhosos para si mesmo. Você tem controle sobre a relação com o Stakeholder (ou chefe) quando oferece informações ativamente, em vez de esperar até que seja perguntado e então ter que se adaptar ao cronograma de outras pessoas.

Algumas pessoas não têm jeito

Mesmo com essas dicas, você nem sempre conseguirá eliminar todo o microgerenciamento. Alguns stakeholders são microgerenciadores incorrigíveis. As dicas mencionadas aqui, no entanto, vão ajudá-lo a ter mais controle sobre a maioria das situações e, assim, torná-las mais suportáveis.

Este texto é do Blog de Mike Cohn e foi traduzido por nós para o português.

O que é realmente produtividade

=> Desvendamos os maiores mitos sobre produtividade.

Priorização e objetivos de médio prazo

=> Aprenda como você pode priorizar melhor como Product Owner.

Tomada de decisão em equipe

=> Assim você chega mais rápido a melhores decisões com Scrum.