Gestão de mudanças ágil

A entrega ágil vem do desenvolvimento de software. O Manifesto for Agile Software Development (2001) estabeleceu quatro valores, entre eles “responder a mudanças mais que seguir um plano”, e doze princípios que favorecem a entrega frequente de software funcionando e a colaboração próxima com os usuários. Frameworks como o Scrum transformam essas ideias em rotina: o trabalho é puxado de um backlog e entregue em sprints de um mês ou menos.

A entrega ágil muda o ritmo da mudança para as pessoas afetadas. Em vez de um único go-live depois de meses de desenho, elas recebem um fluxo constante de mudanças menores, e cada uma ainda precisa ser compreendida, aprendida e usada.

A gestão de mudanças ágil é a disciplina de apoiar as pessoas ao longo desse fluxo. Não é um modelo único com etapas fixas: autores da prática, como Melanie Franklin, a descrevem em seus próprios termos, e as organizações a adaptam ao seu método de entrega.

A gestão de mudanças ágil é, portanto, a gestão de mudanças no ritmo da entrega iterativa, e não um substituto dela.

As atividades continuam familiares: análise de impacto, engajamento, comunicação, aprendizagem, suporte e reforço. O que muda é o seu tamanho, momento e frequência.

O gestor de mudanças também se aproxima da equipe de entrega, muitas vezes participando dos seus eventos de planejamento e revisão, em vez de receber um desenho pronto.

A gestão de mudanças ágil, portanto, pede um trabalho de mudança menor e mais frequente, planejado perto da equipe de entrega.

Um backlog da mudança é uma lista ordenada das atividades de mudança de que uma entrega vai precisar: um briefing para os líderes de equipe, um guia curto, a atualização de um procedimento, uma sessão de plantão de dúvidas, uma pergunta a testar com os usuários. Cada item está ligado à funcionalidade ou à entrega que cria a necessidade.

O gestor de mudanças ordena o backlog pelo impacto sobre as pessoas e pelas datas de entrega, e o revisa com o product owner, para que o trabalho de mudança fique visível ao lado do trabalho de entrega. Algumas equipes incluem condições de adoção na sua definição de pronto, por exemplo “orientações publicadas e líderes de equipe informados”, para que uma funcionalidade não seja considerada concluída enquanto as pessoas ainda não conseguem usá-la.

O feedback dos usuários vira novos itens do backlog, para a equipe da mudança ou, quando aponta um problema de desenho, para a equipe de entrega.

Um backlog da mudança torna a gestão de mudanças ágil planejável da mesma forma que o trabalho de entrega que ela apoia.

Os eventos do Scrum oferecem pontos naturais para ligar o trabalho de mudança à entrega:

• Planejamento da sprint: verifique quais itens selecionados afetam as pessoas e planeje os itens de mudança de que elas precisam.
• Revisão da sprint: convide representantes das pessoas afetadas e registre suas reações como feedback.
• Retrospectiva: inclua lições sobre a adoção, e não apenas sobre a entrega.

O ritmo em que uma equipe entrega não precisa ser o ritmo em que as pessoas recebem a mudança. Na Brightwater Health, uma equipe de agendamento trabalha em sprints de duas semanas, mas o gestor de mudanças combina com o product owner liberar as novas funcionalidades para as clínicas uma vez por mês. Antes de cada liberação, os gestores das clínicas recebem uma nota de uma página sobre “o que está mudando” e conduzem uma breve reunião com a equipe. Os agentes de mudança de cada clínica reúnem as dúvidas, que entram no backlog da mudança do mês seguinte.

A gestão de mudanças ágil, portanto, separa a cadência de entrega da cadência de adoção quando as pessoas precisam de tempo para absorver cada passo.

A adoção iterativa tem vantagens reais. Mudanças pequenas são mais fáceis de aprender do que grandes. Os usuários veem benefícios cedo e podem influenciar os incrementos seguintes, o que gera senso de pertencimento. Os problemas aparecem em uma entrega, e não todos de uma vez.

Ela também traz riscos:

• Fadiga de mudança. Um fluxo constante de pequenas mudanças, somado a outras iniciativas, pode esgotar as pessoas.
• Nenhum encerramento claro. As pessoas podem nunca sentir que a mudança terminou ou que o modo antigo chegou ao fim.
• História perdida. Vista entrega por entrega, a mudança pode parecer uma série de ajustes sem propósito.

As respostas habituais são agrupar pequenas mudanças em menos entregas, manter uma imagem estável do objetivo final e um roadmap visível, e marcar marcos para que as pessoas vejam o progresso.

A gestão de mudanças ágil funciona melhor quando cada incremento é apresentado como um passo rumo a um propósito que as pessoas entendem.

A base de evidências é escassa. Uma revisão sistemática de transformações ágeis em larga escala feita por Dikert, Paasivaara e Lassenius (2016) constatou que a maioria dos relatos publicados eram relatos de experiência, e não estudos de pesquisa, e apontou a resistência à mudança entre os desafios recorrentes e o treinamento, o coaching e a comunicação entre os fatores de sucesso. Essa revisão trata da adoção do próprio ágil, o que está relacionado, mas não é o mesmo, que gerenciar outras mudanças por meio da entrega ágil.

Os erros comuns incluem:

• tratar o “ágil” como motivo para pular o planejamento da mudança;
• manter o gestor de mudanças fora da equipe, de modo que os impactos são descobertos tarde;
• equiparar “entregue” a “adotado”;
• ignorar as partes da organização que não trabalham em sprints, como operações ou RH.

A gestão de mudanças ágil é, portanto, uma adaptação prática com pouca pesquisa por trás, e ainda precisa de uma estratégia clara e de indicadores de adoção.