Colocar o Agile em escala para grandes equipes

As palavras grande e Agile não costumam ser usadas na mesma frase. Grandes organizações ganharam a reputação de serem lentas. Porém, isso está mudando. Muitas grandes organizações de software estão fazendo a transformação para o Agile com sucesso. Elas estão aprendendo a escalar princípios Agile com ou sem estruturas populares, como SAFe, LeSS, ou Nexus.

Na Microsoft, uma dessas organizações usa o Agile para criar produtos e serviços fornecidos com a marca Azure DevOps. Esse grupo tem 35 equipes de recursos que entram em produção a cada três semanas.

Cada equipe no Azure DevOps possui recursos do início ao fim e além. Elas são donas do relacionamento com o cliente. Elas gerenciam sua própria lista de pendências de produtos. Elas escrevem e verificam o código no branch de produção. A cada três semanas, o branch de produção é implantado e o lançamento torna-se público. Em seguida, as equipes monitoram a integridade do sistema e corrigem problemas no local ao vivo.

De acordo com os princípios Agile, as equipes autônomas são mais produtivas. Uma organização Agile quer que suas equipes tenham controle sobre a execução diária. Porém, a autonomia sem alinhamento resultará em caos. Dezenas de equipes trabalhando de forma independente não produziriam um produto unificado e de alta qualidade. O alinhamento dá às equipes seu propósito e garante que elas atinjam as metas da organização. Sem o alinhamento, mesmo as equipes com melhor desempenho falhariam.

Para escalar o Agile, você deve habilitar a autonomia para a equipe, garantindo o alinhamento com a organização.

Para gerenciar o equilíbrio delicado entre alinhamento e autonomia, os líderes de DevOps precisam definir uma taxonomia, definir um processo de planejamento e usar chats de recursos.

Definir uma taxonomia

Uma equipe Agile, bem como a organização Agile maior a qual ela pertence, precisam de uma lista de pendências claramente definida para serem bem-sucedidas. Será difícil para as equipes obterem sucesso se as metas organizacionais não forem claras.

Para definir metas claras e informar como cada equipe contribui para elas, a organização precisa definir uma taxonomia. Uma taxonomia definida claramente cria a nomenclatura de uma organização.

Uma taxonomia comum é épicos, características, histórias e tarefas.

Épicos

Os épicos descrevem iniciativas importantes para o sucesso da organização. Para que os épicos sejam realizados, podem ser necessárias várias equipes e vários sprints, mas tudo isso tem fim. Os épicos têm um objetivo claramente definido. Uma vez alcançado, o épico é encerrado. O número de épicos em andamento deve ser gerenciável para que a organização se mantenha focada. Os épicos são divididos em recursos.

Recursos

Os recursos definem a nova funcionalidade necessária para alcançar o objetivo de um épico. Os recursos são a unidade de lançamento; eles representam o que é liberado para o cliente. As notas de versão publicadas podem ser criadas com base na lista de recursos concluídos recentemente. Os recursos podem levar vários sprints para serem concluídos, mas devem ser dimensionados para garantir um fluxo de valor consistente para o cliente. Os recursos são divididos em histórias.

Histórias

As histórias definem o valor incremental que a equipe deve entregar para criar um recurso. A equipe divide o recurso em partes incrementais. Uma única história concluída pode não fornecer valor significativo ao cliente. No entanto, uma história completa representa um software com qualidade de produção. As histórias são a unidade de trabalho da equipe. A equipe define as histórias que são necessárias para concluir um recurso. Como alternativa, as histórias podem se dividir em tarefas.

Tarefas

As tarefas definem o trabalho necessário para concluir uma história.

Iniciativas

Esta taxonomia não é um sistema único para todos os casos. Muitas organizações introduzem um nível que está acima dos épicos, chamado iniciativas.

Os nomes de cada nível podem ser adaptados à sua organização. No entanto, os nomes definidos acima (épicos, características, histórias) são utilizados amplamente no setor.

Linha de autonomia

Quando a taxonomia for definida, a organização precisará traçar uma linha de autonomia. A linha de autonomia é o ponto em que a propriedade do nível passa da gerência para a equipe. A gerência não interfere nos níveis que pertencem à equipe.

O exemplo a seguir mostra a linha de autonomia traçada abaixo dos recursos. A gerência é dona dos épicos e recursos, que proporcionam alinhamento. As equipes são donas das histórias e tarefas e têm autonomia sobre como elas são executadas.

Neste exemplo, a gerência não diz à equipe como decompor histórias, planejar sprints ou executar trabalhos.

No entanto, a equipe deve garantir que sua execução esteja alinhada com os objetivos da gerência. Embora uma equipe possua sua lista de pendências de histórias, ela deve alinhar sua lista de pendências com os recursos atribuídos a ela.

Planejamento

Para escalar o planejamento Agile, uma equipe precisa de um plano para cada nível da taxonomia. No entanto, é importante iterar e atualizar o plano. Esse processo é chamado de planejamento em ondas sucessivas.

O plano fornece a direção por um intervalo fixo de tempo com a calibração esperada em intervalos regulares. Por exemplo, um plano de 18 meses poderia ser calibrado a cada seis meses.

Aqui está um exemplo de métodos de planejamento para cada nível de uma taxonomia: épicos, recursos, histórias e tarefas.

Visão

A visão é expressa por meio de épicos e define a direção de longo prazo da organização. Os épicos definem o que a organização quer concluir nos próximos 18 meses. A gerência é dona do plano e o calibra semestralmente.

A visão é apresentada em uma reunião prática. Como se espera que a visão seja ambiciosa e muita coisa pode mudar ao longo desse intervalo de tempo, espere concluir cerca de 60% da visão.

Estação do ano

Uma temporada é descrita por meio de recursos e define a estratégia para os próximos seis meses. Os recursos determinam o que a organização deseja iluminar para seus clientes. A gerência é dona do plano sazonal e apresenta a visão e os planos sazonais em uma reunião prática. Todos os planos da equipe devem estar alinhados com o plano sazonal da gerência. Espere concluir cerca de 80% do plano sazonal.

Plano de 3 sprints

O plano de 3 sprints define as histórias e recursos que a equipe terminará nos próximos três sprints. A equipe é dona do plano e o calibra a cada sprint. Cada equipe apresenta seu plano à gerência por meio do chat de recursos (veja abaixo). O plano especifica como a execução da equipe se alinha com o plano sazonal de 6 meses. Espere realizar cerca de 90% do plano de 3 sprints.

Plano de sprint

O plano de sprint define as histórias e recursos que a equipe terminará no próximo sprint. A equipe é dona do plano de sprint e o envia por email para toda a organização para fornecer total transparência. O plano inclui o que a equipe realizou no sprint passado e seu foco para o próximo sprint. Espere realizar cerca de 95% do plano de sprint.

Linha de autonomia

Neste exemplo, a linha de autonomia é traçada para mostrar onde as equipes têm autonomia de planejamento.

Como informamos acima, a gerência não estende a propriedade para baixo da linha de autonomia. A gerência fornece orientação usando a visão e os planos de temporada e, em seguida, dá às equipes autonomia para criar planos de 1 e 3 sprints.

Chats de recursos: onde a autonomia encontra o alinhamento

Um chat de recurso é uma reunião de baixa cerimônia onde cada equipe apresenta seu plano de 3 sprints para a gerência. Essa reunião garante que os planos da equipe estejam alinhados com as metas da organização. Isso também ajuda a gerência a se manter informada sobre o que a equipe está fazendo. Enquanto o plano de 3 sprints é calibrado a cada sprint, os chats de recursos são realizados conforme necessário, geralmente a cada um a três sprints.

Uma reunião de chat de recurso aloca 15 minutos para cada equipe. Com 12 equipes de recurso, essas reuniões podem ser agendadas para durar cerca de três horas. Cada equipe prepara uma apresentação de 3 slides, com os seguintes slides:

Recursos

O primeiro slide descreve os recursos que a equipe destacará nos próximos três sprints.

Dívida

O próximo slide descreve como a equipe gerencia a dívida técnica. Dívida é qualquer coisa que não atende aos padrões de qualidade da gerência. O diretor de engenharia define os níveis de qualidade, que são os mesmos para todas as equipes (alinhamento). Os níveis de qualidade de exemplo incluem o número de bugs por engenheiro, a porcentagem de testes de unidade aprovados e as metas de desempenho.

Problemas e dependências

Os problemas e dependências listados no slide final incluem qualquer coisa que afete o progresso da equipe, como problemas que a equipe não pode resolver ou dependências de outras equipes que precisam de escalonamento.

Cada equipe apresenta seus slides diretamente à gerência. A equipe apresenta como seu plano de 3 sprints se alinha com o plano sazonal de 6 meses. A liderança faz perguntas esclarecedoras e sugere mudanças de direção. Ela também pode solicitar reuniões de acompanhamento para resolver questões mais profundas.

Se o plano de uma equipe não estiver alinhado com as expectativas da gerência, ela pode solicitar um replanejamento. Neste evento raro, a equipe replanejará e agendará um segundo chat de recurso para revisá-lo.

Confiança: a cola que une alinhamento e autonomia

Ao praticar o Agile em escala, a confiança é uma via de mão dupla:

• A gerência deve confiar que as equipes farão o que é certo. Se a gerência não confiar nas equipes, elas não darão autonomia às equipes.

• Uma equipe conquista confiança ao entregar código de alta qualidade consistentemente. Se as equipes não forem confiáveis, a gerência não dará autonomia a elas.

A gerência deve fornecer planos claros para as equipes se alinharem e, então, confiar que elas executarão o plano. As equipes devem alinhar seus planos com a organização e executá-los de forma confiável.

À medida que as organizações procuram escalar o Agile para cenários maiores, a chave é dar autonomia às equipes e, ao mesmo tempo, garantir que elas estejam alinhadas com as metas da organização. Os blocos de construção críticos são a propriedade claramente definida e uma cultura de confiança. Quando organização estabelecer essa base, ela descobrirá que o Agile pode escalar muito bem.

Próximas etapas

Há muitas maneiras de uma equipe de qualquer tamanho começar a ver benefícios hoje mesmo. Confira algumas dessas práticas que escalam.

Saiba mais sobre os recursos de DevOps do Azure para gerenciamento de portfólio e visibilidade entre equipes.

A Microsoft é uma das maiores empresas Agile do mundo. Saiba mais sobre como a Microsoft escala o planejamento de DevOps.