5 sinais que seu processo de desenvolvimento agile deve mudar

Você chama seu processo de desenvolvimento agile de “fragile”, “waterfall híbrido” ou “falso agile”? Sua lista de pendências agile é mais como uma fila de pedidos ou um quadro de tarefas? Mais especificamente, as equipes de desenvolvimento agile estão exibindo algum desses 15 sinais de que você está agindo errado?

Leia também: 13 ‘melhores práticas’ que a TI deve evitar a todo custo

Talvez o seu processo de desenvolvimento agile não seja tão ruim e as equipes estejam acelerando, liberando e satisfazendo os clientes. Talvez as equipes tenham amadurecido metodologias ágeis, formalizado o gerenciamento de versões, estabelecido disciplinas de estimativa agile e desenvolvido padrões de redação de histórias. Felizmente, eles fizeram parceria com equipes de operações e suas ferramentas agiles se integram com controle de versão, pipelines de CI/CD (integração contínua/entrega contínua) e plataformas de observação.

É bem provável que as equipes de sua organização estejam em algum lugar entre esses dois extremos. Embora muitas organizações agiles tenham um processo contínuo para amadurecer e melhorar as práticas ágeis, às vezes o processo de desenvolvimento deve mudar. Algumas organizações utilizam KPIs (indicadores-chave de desempenho) agiles e métricas de desenvolvimento para reconhecer o progresso e sinalizar quando as mudanças são necessárias. Mas algumas organizações podem não ter métricas formais em vigor e dependem de pessoas e processos para indicar se e onde os ajustes são necessários.

Aqui estão cinco indicadores de que o processo de desenvolvimento agile deve mudar e meus ajustes recomendados.

Há um acúmulo de tarefas e o planejamento é insuficiente

As equipes Agile descobrem rapidamente que poluir um backlog com cada ideia, solicitação ou problema técnico torna difícil para o product owner, scrum master e a equipe trabalharem de forma eficiente. Se as equipes mantiverem uma grande lista de pendências em suas ferramentas ágeis, elas devem usar rótulos ou tags para filtrar as prioridades de curto prazo em relação às de longo prazo.

Um desafio ainda maior é quando as equipes adotam o planejamento just-in-time e priorizam, escrevem, revisam e estimam histórias de usuários durante os dias anteriores ao início do sprint. É muito mais difícil desenvolver um entendimento compartilhado dos requisitos sob pressão de tempo. As equipes têm menos probabilidade de considerar arquitetura, operações, padrões técnicos e outras práticas recomendadas quando não há tempo suficiente dedicado ao planejamento. O pior é que é difícil acomodar os processos de negócios posteriores, como treinamento e gerenciamento de mudança, se as partes interessadas da empresa não souberem os resultados finais ou o roteiro de médio prazo.

Existem várias práticas recomendadas para planejar atrasos, incluindo planejamento ágil contínuo, planejamento de Implementação de Programa e outras práticas de planejamento trimestral. Essas práticas ajudam várias equipes agiles a ter ideias épicas, dividir recursos, confirmar dependências e priorizar a escrita de histórias do usuário.

Sprints e lançamentos ficam aquém dos compromissos

Depois de escrever “5 Ways agile teams meet sprint commitments” [5 maneiras pelas quais as equipes ágeis cumprem os compromissos de sprint], ouvi de algumas pessoas no Twitter que o comprometimento acabou e mais equipes estão mudando de Scrum para Kanban.

Há momentos em que recomendo Scrum e outras instâncias em que Kanban tem vantagens, mas sou um forte defensor de equipes de desenvolvimento ágil comprometidas com o trabalho que aceitam. O compromisso sinaliza aos product owner e às partes interessadas que há um entendimento compartilhado de quem, por que e o que é necessário, e exige equipes agiles para definir um plano de implementação.

Os compromissos representam uma previsão, e esperar que as equipes atendam ou excedam as metas de forma consistente não é realista. Quando as equipes de desenvolvimento agile se comprometem a fazer as histórias do usuário, muitas vezes é diante de várias incógnitas em torno da implementação, dependências da equipe e suposições de tecnologia.

Quando as equipes agiles perdem compromissos de forma consistente, pode ser hora de considerar mudanças e melhorias. Comprometer-se com menos histórias pode parecer uma resposta fácil, mas não é se o problema for a coordenação para atender aos requisitos em um sprint ou na duração de uma versão.

As melhores equipes auto-organizadas reconhecem falhas no cumprimento das expectativas, usam retrospectivas para diagnosticar as causas raízes e se comprometem com melhorias.

Sprints terminam sem demonstrações bem assistidas

A agenda da reunião de revisão do sprint é demonstrar histórias de usuários concluídas para o product owner e as partes interessadas e obter feedback antecipado. As revisões de sprint devem ser bem atendidas e as equipes devem ter muito o que mostrar.

As melhores equipes ágeis com quem tive o privilégio de trabalhar tratam as revisões de sprint como teatro. Elas discutem como demonstrar a história, quem deve liderá-la, quando sequenciá-la e que tipos de feedback capturar. O líder do sqaud garante que as revisões do sprint sejam executadas dentro do cronograma, que o feedback seja capturado e que longas discussões sejam estacionadas para acompanhamento posterior.

Avaliações abaixo da média podem apontar para vários problemas:

• As histórias não são escritas da perspectiva do usuário, o que as torna mais desafiadoras para a demonstração.
• Os desenvolvedores estão preocupados em mostrar uma experiência do usuário que é um trabalho em andamento.
• As equipes trabalham até as últimas horas antes da revisão e não estão preparadas para fazer um bom show.
• Os product owners definem expectativas irrealistas com stakeholders e deixam suas equipes secarem durante a demonstração.
• As partes interessadas não veem valor em participar por causa de maus desempenhos anteriores ou sentem que ninguém está ouvindo seus comentários.
• As revisões de sprint devem ser momentos para celebrar o progresso de uma equipe.

Desempenhos fracos ou não supervisionados podem levar a problemas de ânimo da equipe.

Defeitos crescentes são encontrados na produção

Muitas equipes de desenvolvimento agile automatizam testes, configuram pipelines de CI/CD e implantam infraestrutura como código para melhorar a confiabilidade das versões e implantar mudanças de produção com mais frequência. As organizações mais avançadas empregam estratégias de teste shift-left e devops maduros para incluir segurança no início do processo de desenvolvimento.

O senso comum é que as implantações frequentes levam a uma maior satisfação do usuário e a menos problemas de dependência técnica. No relatório de 2020 State of Devops, 45% das empresas orientadas para a engenharia de alta evolução afirmam uma frequência de implantação sob demanda e 38% têm menos de um dia de tempo de espera para mudanças. Empresas mais conservadoras, operacionalmente maduras e focadas em governança têm percentuais mais baixos.

Implantações frequentes fazem sentido até que não o façam. Um indicador claro de que as equipes de desenvolvimento agile estão implantando com muita frequência é se um número crescente de defeitos são encontrados na produção.

Os defeitos de produção podem afetar o desempenho dos negócios e são altamente problemáticos quando as organizações desenvolvem reputações por implantar software com erros. Também é desafiador quando as equipes de desenvolvimento devem responder a grandes incidentes de produção, programar lançamentos de reparos de emergência ou priorizar a correção de defeitos em vez de outras prioridades.

As equipes que encontram defeitos crescentes na produção devem discutir as causas raízes e encontrar soluções. Em muitos casos, planejar atrasos com antecedência, melhorar os requisitos, investir em automação de teste, aumentar a variedade de dados de teste ou instrumentar testes contínuos são etapas que podem ajudar a reduzir os defeitos de produção.

As equipes ágeis ou suas partes interessadas não estão felizes

O fator mais importante para considerar mudanças é se a equipe agile ou seus stakeholders estão satisfeitos.

Perder um sprint ou mesmo um lançamento não deve ser motivo de alarme, mas os líderes devem definir abordagens para capturar feedback formalmente. Os diálogos individuais são úteis, mas as organizações maiores devem considerar a satisfação do cliente e pesquisas agiles com colegas de equipe.

Procure equipes que relatem bloqueios devido a problemas fora de seu controle. Se houver muitas dependências entre equipes agiles ou se pessoas, habilidades, tecnologia ou fornecedores impedirem sua capacidade de execução, problemas prolongados provavelmente afetarão a felicidade da equipe.

Partes interessadas insatisfeitas são igualmente motivo de preocupação. A insatisfação pode resultar de expectativas excessivamente altas, baixa qualidade de entrega ou apenas das realidades de trabalho fora de sua colaboração com equipes agiles. Na minha experiência, equipes agiles felizes estão relacionadas à satisfação das partes interessadas. Quando as pessoas estão frustradas, é hora de ouvir e priorizar as mudanças apropriadas.

Uma prática recomendada é as equipes ágeis buscarem e priorizarem ajustes incrementais em seus processos, princípios, colaboração e padrões. Organizações agile que buscam modificações menores podem evitar pivots mais difíceis. Não é disso que se trata o Agile?