Dimensionamento do Agile para grandes equipes

As palavras grandes e Agile não são frequentemente usadas na mesma frase. Grandes organizações ganharam a reputação de serem lentas. No entanto, isso está mudando. Muitas grandes organizações de software estão fazendo a transformação com êxito no Agile. Eles estão aprendendo a dimensionar 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 enviados sob a marca Azure DevOps. Esse grupo tem 35 equipes de funcionalidades que lançam suas entregas em produção a cada três semanas.

Cada equipe dentro do Azure DevOps possui recursos do início ao fim e além. Eles possuem relacionamentos com clientes. Eles gerenciam sua própria lista de pendências de produto. Eles escrevem e validam o código no branch de produção. A cada três semanas, o branch de produção é implantado e o lançamento se torna público. Em seguida, as equipes monitoram a integridade do sistema e corrigem problemas em ambiente de produção.

De acordo com os princípios do Agile, as equipes autônomas são mais produtivas. Uma organização Agile quer que suas equipes tenham controle sobre sua execução diária. Mas a autonomia sem alinhamento resultaria em caos. Dezenas de equipes que trabalham de forma independente não produziriam um produto unificado e de alta qualidade. O alinhamento fornece às equipes sua finalidade e garante que elas atendam às metas organizacionais. Sem alinhamento, mesmo as equipes com melhor desempenho falhariam.

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

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

Definir uma taxonomia

Uma equipe Agile, e a organização Agile maior à qual pertence, precisam de um backlog claramente definido para ter êxito. As equipes lutarão para ter sucesso se as metas organizacionais não estiverem claras.

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

Uma taxonomia comum são épicos, recursos, histórias e tarefas.

Épicos

A Epics descreve iniciativas importantes para o sucesso da organização. Épicos podem requerer várias equipes e vários sprints para serem concluídos, mas têm um fim. Os épicos têm uma meta claramente definida. Uma vez alcançado, o épico é concluído. O número de épicos em andamento deve ser gerenciável para manter a organização focada. Épicos são divididos em funcionalidades.

Features

Os recursos definem a nova funcionalidade necessária para atingir a meta de um épico. As funcionalidades são a unidade de lançamento; elas representam o que é entregue ao cliente. As notas de versão que foram publicadas podem ser criadas com base na lista de funcionalidades concluídas recentemente. Os recursos podem levar vários sprints para serem concluídos, mas devem ser dimensionados para garantir um fluxo consistente de valor para o cliente. As funcionalidades são quebradas em histórias.

Histórias

As histórias definem o valor incremental que a equipe deve fornecer para criar um recurso. A equipe divide a funcionalidade em partes incrementais. Uma única história concluída pode não fornecer um valor significativo para o cliente. No entanto, um projeto concluído representa um software em qualidade de produção. As histórias são a unidade de trabalho da equipe. A equipe define as histórias necessárias para concluir um recurso. As histórias, opcionalmente, são divididas em tarefas.

Tasks

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

Iniciativas

Essa taxonomia não é um sistema universal. Muitas organizações introduzem um nível acima dos épicos chamados iniciativas.

Os nomes de cada nível podem ser personalizados para sua organização. No entanto, os nomes definidos acima (épicos, features, histórias) são amplamente usados na indústria.

Linha de autonomia

Depois que uma taxonomia é definida, a organização precisa desenhar uma linha de autonomia. A linha de autonomia é o ponto em que a propriedade do nível passa da gestão para a equipe. O gerenciamento não interfere nos níveis pertencentes à equipe.

O exemplo a seguir mostra a linha de autonomia desenhada abaixo das funcionalidades. A gestão possui épicos e funcionalidades, que proporcionam alinhamento. As equipes possuem estórias e tarefas e têm autonomia sobre como realizam seu trabalho.

Neste exemplo, o gerenciamento não conta à equipe como decompor histórias, planejar sprints ou executar trabalhos.

A equipe, no entanto, deve garantir que sua execução se alinhe às metas do gerenciamento. Embora uma equipe possua seu backlog de itens, ela deve alinhar esse backlog com os recursos atribuídos a ela.

Planning

Para dimensionar 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 contínuas.

O plano fornece direção para um período fixo de tempo com a calibragem esperada em intervalos regulares. Por exemplo, um plano de 18 meses pode 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, tarefas.

Visão

A visão é expressa por meio de épicos e define a direção de longo prazo da organização. Os epics definem o que a organização deseja concluir nos próximos 18 meses. O gerenciamento possui o plano e o calibra a cada seis meses.

A visão é apresentada em uma reunião geral. Como a visão foi projetada para ser ambiciosa e muita coisa pode mudar ao longo desse período de tempo, almeje concretizar cerca de 60% da visão.

Estação

Uma temporada é descrita por meio de características e define a estratégia para os próximos seis meses. As funcionalidades determinam o que a organização deseja destacar para seus clientes. A administração é responsável pelo plano sazonal e apresenta a visão e os planos sazonais em uma reunião geral. Todos os planos de equipe devem se alinhar ao plano sazonal do gerenciamento. Espere realizar cerca de 80% do plano sazonal.

Plano de 3 sprints

O plano de 3 sprints define as histórias e funcionalidades que a equipe terminará nos próximos três sprints. A equipe é dona do plano e calibra-o a cada sprint. Cada equipe apresenta seu plano para a gestão via o recurso de chat da funcionalidade (veja abaixo). O plano especifica como a execução da equipe se alinha com o plano sazonal de seis 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 concluirá no próximo sprint. A equipe é dona do plano de sprint e envia-o por e-mail para toda a organização para 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 é desenhada para mostrar onde as equipes têm autonomia de planejamento.

Conforme indicado acima, o gerenciamento não estende a propriedade abaixo da linha de autonomia. O gerenciamento fornece diretrizes usando visão e planos sazonais e depois dá às equipes autonomia para criar planos de 3 sprints e de sprints individuais.

Chats sobre funcionalidades: onde a autonomia encontra o alinhamento

Um chat de funcionalidades é uma reunião informal onde cada equipe apresenta seu plano de 3 sprints para a gestão. Essa reunião garante que os planos da equipe se alinhem às metas organizacionais. Também ajuda o gerenciamento a se manter informado sobre o que a equipe está fazendo. Embora o plano de 3 sprints seja calibrado a cada sprint, os chats de funcionalidades são realizados conforme necessário, geralmente a cada um a três sprints.

Uma reunião de chat sobre funcionalidade aloca 15 minutos para cada equipe. Com 12 equipes de funcionalidades, essas reuniões podem ser agendadas e tendem a durar cerca de três horas. Cada equipe prepara um deck de 3 slides, com os seguintes slides:

Features

O primeiro slide descreve os recursos que a equipe implementará 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 atenda aos padrões de qualidade da gerência. O diretor de engenharia define os padrões de qualidade, que são os mesmos para todas as equipes (alinhamento). As barras de qualidade de exemplo incluem o número de bugs por engenheiro, o percentual 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 impacte 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 para o gerenciamento. A equipe apresenta como seu plano de 3 sprints se alinha ao plano sazonal de 6 meses. A liderança faz perguntas esclarecedoras e sugere mudanças na direção. Eles também podem solicitar reuniões de acompanhamento para resolver problemas mais profundos.

Se o plano de uma equipe não estiver alinhado com as expectativas da gestão, a gestão poderá solicitar um replanejamento. Nesse raro evento, a equipe replanejará e agendará um segundo chat sobre funcionalidades para revisá-lo.

Confiança: a cola que mantém o alinhamento e a autonomia juntos

Ao praticar o Agile em escala, a confiança é uma via bidirecional:

• O gerenciamento deve confiar nas equipes para fazer a coisa certa. Se o gerenciamento não confiar nas equipes, elas não darão autonomia às equipes.

• Uma equipe ganha confiança fornecendo consistentemente código de alta qualidade. Se as equipes não forem confiáveis, o gerenciamento não lhes dará autonomia.

A administração deve fornecer planos claros para que as equipes possam se alinhar e, em seguida, confiar em suas equipes para executar. As equipes devem alinhar seus planos com a organização e executar de maneira confiável.

À medida que as organizações buscam dimensionar o Agile para cenários maiores, a chave é dar autonomia às equipes, garantindo que elas estejam alinhadas com as metas organizacionais. Os blocos de construção críticos são propriedade claramente definida e uma cultura de confiança. Depois que uma organização tiver essa base estabelecida, ela descobrirá que o Agile pode ser escalado muito bem.

Próximas etapas

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

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

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