Remoção de Impedimentos é uma habilidade de todos em um time ágil!
Entender o que realmente é impedimento é fundamental, não devemos ignorar a compreensão correta disso.
Do contrario, estamos falando de um “anti padrão” da agilidade, que são os gargalos nos times por falta de autonomia.
O que é Impedimento?
Imagine o seguinte cenário: você está dirigindo em direção ao seu destino em uma estrada dentro de uma selva, e se depara com um elefante na sua frente.
Você olha para o lado e tem valas. Voltar “pra trás” não é uma opção. E o elefante está parado olhando pra você.
Neste caso, você tem um impedimento.
Agora imagine o seguinte: você está dirigindo em direção ao seu destino em uma estrada dentro de uma selva, e se depara com um elefante na sua frente.
Você olha para o elefante e ele fala para você: “Olá, quer passar? Se quiser, abra um chamado para o Service Desk, sinalize sua prioridade e assim que chegar sua vez na fila um adestrador virá aqui me pedir para sair, e eu sairei da sua frente”.
Neste caso, você não tem um impedimento. Você tem uma tarefa a realizar.
Podemos definir impedimento como um problema que o time não conseguiu resolver, e que bloqueia o andamento dos seus trabalhos.
Lei do Menor Esforço e Remoção de Impedimentos
Acho que todo ser humano deveria entender a Lei do Menor Esforço. Nosso corpo é programado para utilizá-la, e o de qualquer ser vivo na natureza também.
Basicamente, trata-se de priorizar as ações para gerar economia de energia e ter o resultado esperado com o mínimo de esforço possível.
Se bem utilizado é um mindset excelente para a eficiência ótima. 🙂
Entretanto, seres racionais abusam um pouco disso.
Muitos acabam se acomodando e utilizando esse estimulo natural da mente e do corpo para delegar o que poderia fazer, a outros.
Time autônomo e Remoção de Impedimentos
Em equipes de trabalho mais tradicionais foi criada uma cultura de que ao primeiro sinal de dificuldade para prosseguir, basta pedir ao Gerente de Projetos, Coordenador ou outro Líder, que resolva para nós.
É como os filhos pequenos com seus pais. No primeiro obstáculo, chama-se o pai ou a mãe para “remover o impedimento”.
Em equipes de trabalho ágeis, o que se espera é diferente: havendo o obstáculo o time deve tentar resolver sozinho e após esgotar as possibilidades, não tendo sucesso, o time deve então levantar o braço e pedir ajuda.
Em agilidade há uma premissa de que o time deve ter autonomia para conduzir 100% do seu trabalho.
Junto com essa autonomia, vem também a responsabilidade.
E ser responsável pelo resultado sugere que o time se vire sozinho o máximo que conseguir.
O Scrum Master e a Remoção de Impedimentos
O Scrum Master (SM) é um Líder Servidor: ele trabalha para o time, e não o time trabalha para ele.
Mas liderar um time ágil é mais sobre potencializar os membros do time do que levar água quando alguém está com sede, quando poderia ir ao bebedouro e encher sua garrafa d’agua.
A nossa cultura está muito mais acostumada com lideranças “comando x controle” do que “liderança servidora”.
É natural, afinal, ficamos séculos no primeiro mindset, e estamos há poucos anos no segundo.
Complementa-se ainda, a Lei do Menor esforço que citei anteriormente.
E muito Scrum Master, membros de equipe e gestores, acham que o SM deve fazer aquilo que o time poderia fazer sozinho, afinal, para muitos, a principal tarefa de um SM é a remoção de impedimentos.
Uma pessoa apenas aprende a andar de bicicleta quando se tira as duas rodinhas.
O Scrum Master deve potencializar o time para que ele “voe com as próprias asas”, e não potencializar o time para que este tenha dependências externas para resolver seus problemas.
Exemplo de Impedimento de Verdade x Impedimento de Mentira
Vamos exemplificar alguns cenários onde temos impedimentos “de fato”, e outros cenários onde tenha pseudo-impedimentos, que são atividades que o próprio time de desenvolvedores pode (e deve) resolver sozinho.
Vejamos alguns exemplos de pseudo-impedimentos.
Criação de usuário para acesso a banco de dados
Desenvolvedores sempre precisam pedir acesso a algum recurso de infra-estrutura ou software que precisa consumir para realizar sua atividade.
Neste caso, o Dev pode abrir o chamado, interagir com a área que vai atender, pedir e negociar a priorização.
Dependência com Dev de outro time
É comum um time, para realizar sua entrega, depender da entrega de outro time.
Quando isso ocorre, o próprio Dev pode (e deve) ir atrás do Dev do outro time para alinhar o planejamento da dependência.
Se houver a necessidade de combinar prioridades de backlog com o Product Owner (PO), o próprio Dev pode fazer isso também.
Aquisição de mais “poder de processamento” para performance do trabalho
Desenvolvedor de software demanda recursos de processamento poderosos. Eventualmente o Dev vai precisar de um disco SSD, mais recursos no servidor na Nuvem, mais memória para seu notebook etc.
Nestes casos, o Dev pode abrir o chamado e acompanhar sua solicitação. Pedindo a prioridade necessária, especificando as configurações do que precisa, indo falar com a área de Compras, Infra-estrutura etc.
Vejamos agora alguns exemplos de impedimentos “de fato”, nos mesmos cenários dos exemplos citados acima.
Criação de usuário para acesso a banco de dados
o Dev abriu o chamado, pediu o acesso, negociou a priorização e quando o responsável pelo atendimento pegou o ticket para atender, respondeu dizendo que a política da empresa não permite tal acesso.
Se não há solução técnica de contorno e o Dev não consegue fazer mais nada e está bloqueado, então há um impedimento.
Neste caso o Dev pode escalar o problema ao SM para que o SM busque entender da política, conseguir alçada de aprovação para autorizar o acesso, levar o problema a algum comitê de gestão para que não ocorra novamente etc.
Dependência com Dev de outro time
O Dev solicitante foi até o Dev do outro time, explicou sua necessidade, falou sobre o impacto que está tendo e o Dev responsável pela dependência disse que não consegue entregar a dependência pronta no prazo estipulado porque o PO priorizou outra coisa.
O novo prazo do PO não atende a necessidade do Dev solicitante.
Se não há solução técnica de contorno e o Dev não consegue fazer mais nada e está bloqueado, então há um impedimento.
Neste caso o Dev pode escalar o problema ao SM para que o SM procure, juntamente com o PO do time, o PO do outro time e negociar uma data que atenda.
Não havendo possibilidade, o SM deve negociar com o PO do próprio time um replanejamento da entrega, e de posse desta data, dar publicidade do novo plano em função do problema.
Aquisição de mais “poder de processamento” para performance do trabalho
O Dev precisa de mais espaço no seu ambiente em Nuvem, pois está trabalhando com um processamento pesado e a performance da configuração atual do ambiente não atende.
O Dev solicita à infra-estrutura a configuração, mas o Analista da infra alega que não pode fazer, porque o orçamento mensal para tal ambiente está estourado.
O Dev pergunta com quem deve falar sobre isso, é informado e procura o Gerente de Compras para explicar a situação e pedir ajuda.
O Gerente de Compras só lamenta e alega não ter mesmo mais orçamento.
Se não há solução técnica de contorno e o Dev não consegue fazer mais nada e está bloqueado, então há um impedimento.
Neste caso o Dev pode escalar o problema ao SM para que o SM procure o responsável por Compras, explique o impacto da restrição e negocie mais orçamento.
Havendo nova negativa, o SM pode procurar seu gestor direto e escalar o problema para tentar reverter, ou pode também negociar que algum time que tenha espaço ocioso no servidor desligue temporariamente seu ambiente, para que o time possa avançar na entrega, por exemplo.
São apenas exemplos simples e didáticos, mas em essência, retratam bem o que ocorre em vários times quando o assunto é “Remoção de Impedimentos”.
Agilidade prega horizontalidade, e para ser horizontal, a comunicação tem que ser a mais fluída possível, “linha reta entre ponto A e ponto B”.
Em estruturas “comando x controle” tem que pedir “bença” até ao papa para alguma coisa. Em agilidade deve ser o inverso disso.
Lembrando: devemos sempre usar o bom senso.
O SM não é escravo, mas quando o time está no sufoco com alguma entrega crítica, nada impede que o SM absorva pontualmente essa parte do trabalho do time para ajudar no resultado.
Afinal, time é time.