Dimensionamento ágil para grandes equipes

As palavras big 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 com sucesso a transformação para Agile. Eles estão aprendendo a escalar princípios ágeis 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 sob a marca Azure DevOps. Este grupo tem 35 equipas de funcionalidades que libertam para produção a cada três semanas.

Cada equipa no Azure DevOps é responsável pelas funcionalidades desde a conceção até à implementação e evolução. Eles são os donos das relações com clientes. Eles gerenciam sua própria lista de pendências de produtos. Eles escrevem e verificam o código no ramo de produção. A cada três semanas, o ramo de produção é implantado e o lançamento se torna público. Em seguida, as equipes monitoram a integridade do sistema e corrigem problemas no local.

De acordo com os princípios ágeis, as equipes autônomas são mais produtivas. Uma organização ágil quer que suas equipes tenham controle sobre sua execução diária. Mas autonomia sem alinhamento resultaria no 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 organizacionais. Sem alinhamento, mesmo as equipas com melhor desempenho falhariam.

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

Para gerenciar o delicado equilíbrio 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 ágil, e a organização Agile maior a que pertence, precisa de uma lista de pendências claramente definida para ser bem-sucedida. As equipes terão dificuldades para ter sucesso se os objetivos organizacionais não forem claros.

Para definir metas claras e afirmar 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, características, histórias e tarefas.

Épicos

Os épicos descrevem iniciativas importantes para o sucesso da organização. Os épicos podem levar várias equipas e vários sprints a realizar, mas não estão sem fim. Os épicos têm um objetivo claramente definido. Uma vez obtido, o épico é concluído. O número de épicos em andamento deve ser gerenciável para manter a organização focada. Os épicos são divididos em funcionalidades.

Caraterísticas

Os recursos definem a nova funcionalidade necessária para realizar o objetivo de um épico. As características 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 funcionalidades recentemente concluídas. 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 divididas em histórias.

Histórias

As histórias definem o valor incremental que a equipe deve entregar para criar um recurso. A equipa divide a funcionalidade em partes incrementais. Uma única história concluída pode não fornecer valor significativo para o cliente. No entanto, uma história concluída representa um software em nível de produção. As histórias são a unidade de tarefa da equipa. A equipe define as histórias necessárias para concluir um recurso. Opcionalmente, as histórias dividem-se em tarefas.

Tasks

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

Iniciativas

Esta taxonomia não é um sistema único. Muitas organizações introduzem um nível acima dos épicos chamados 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 amplamente utilizados na indústria.

Linha de autonomia

Uma vez definida uma taxonomia, a organização precisa traçar uma linha de autonomia. A linha de autonomia é o ponto em que a propriedade do nível passa da gestão para a equipe. A gestão não interfere nos níveis que são propriedade da equipa.

O exemplo a seguir mostra a linha de autonomia desenhada abaixo dos recursos. A gerência possui épicos e recursos, que proporcionam alinhamento. As equipas são proprietárias de histórias e tarefas e têm autonomia sobre a forma como executam.

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

A equipe, no entanto, deve garantir que sua execução esteja alinhada com os objetivos da gestão. Embora uma equipa seja proprietária do seu backlog de histórias, deve alinhar o backlog com as funcionalidades atribuídas a ela.

Planning

Para escalar o planejamento ágil, 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 de ondas rolantes.

O plano fornece orientação por um período de tempo fixo com 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, características, histórias, tarefas.

Visão

A visão é expressa através de épicos e define a direção de longo prazo da organização. Os grandes objetivos definem o que a organização pretende concluir nos próximos 18 meses. A gerência é proprietária do plano e o calibra a cada seis meses.

A visão é apresentada numa reunião geral. Como a visão pretende ser ambiciosa e muita coisa pode mudar ao longo desse período, pode-se esperar realizar cerca de 60% da visão.

Época

Uma temporada é descrita através de recursos e define a estratégia para os próximos seis meses. As funcionalidades determinam o que a organização deseja disponibilizar para os seus clientes. A gerência é responsável pelo plano sazonal e apresenta a visão e os planos sazonais numa reunião geral. Todos os planos de equipe devem estar alinhados com o plano sazonal da administração. 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 equipa terminará nos próximos três sprints. A equipa é proprietária do plano e calibra-o a cada sprint. Cada equipa apresenta o seu plano à gestão através do chat de funcionalidades (ver 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 Sprint

O plano de sprint define as histórias e funcionalidades que a equipa terminará no próximo sprint. A equipe é proprietária 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 é traçada para mostrar onde as equipes têm autonomia de planejamento.

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

Conversas sobre funcionalidades: onde a autonomia encontra o alinhamento

Um chat de funcionalidades é uma reunião de baixa cerimónia onde cada equipa apresenta o seu plano de 3 sprints para a gestão. Essa reunião garante que os planos da equipe estejam alinhados com os objetivos organizacionais. Também ajuda a gerência a manter-se informada sobre o que a equipa está a fazer. 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 sobre funcionalidades aloca 15 minutos para cada equipa. Com 12 equipas de destaque, estas reuniões podem ser agendadas para durar cerca de três horas. Cada equipa prepara um conjunto de 3 diapositivos, com os seguintes slides:

Caraterísticas

O primeiro slide descreve os recursos que a equipe ativará 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 elemento que não atenda aos padrões de qualidade da gestão. O diretor de engenharia define os padrões de qualidade, que são os mesmos para todas as equipes (alinhamento). Exemplos de barras de qualidade incluem o número de bugs por engenheiro, a porcentagem de aprovação nos testes de unidade 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 equipa apresenta os seus diapositivos diretamente à gerência. A equipa apresenta como o 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. Podem também 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 administração, a gerência pode solicitar um novo plano. Neste raro evento, a equipa vai replanejar e agendar um segundo chat sobre funcionalidades para reavaliá-las.

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

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

• A gestão deve confiar nas equipas para fazerem a coisa certa. Se a gestão não confiar nas equipas, não dará autonomia às equipas.

• Uma equipe ganha confiança ao fornecer consistentemente código de alta qualidade. Se as equipas não forem fiáveis, a gestão não lhes dará autonomia.

A gerência deve fornecer planos claros para que as equipes se alinhem e, em seguida, confiem em suas equipes para executar. As equipas devem alinhar os seus planos com a organização e executar de forma fidedigna.

À medida que as organizações procuram escalar o Agile para cenários maiores, a chave é dar autonomia às equipes, garantindo que elas estejam alinhadas com os objetivos organizacionais. Os alicerces críticos são a apropriação claramente definida e uma cultura de confiança. Uma vez que uma organização tenha essa base estabelecida, ela descobrirá que o Agile pode escalar muito bem.

Próximos passos

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

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

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