Adotar uma cultura Agile

Se há uma lição a ser aprendida com a última década de "Transformações Agile", é que não existe uma solução única que sirva para todos ao adotar ou implementar uma abordagem Agile. Cada organização tem necessidades, restrições e requisitos diferentes. Seguir cegamente uma prescrição não levará ao sucesso.

O movimento Agile trata-se de encontrar continuamente maneiras de melhorar a prática de criação de software. Não se trata de uma reunião stand-up diária perfeita ou uma retrospectiva perfeita. Em vez disso, trata-se de criar uma cultura onde a coisa certa acontece com mais frequência do que não. Atividades como standups e retrospectivas têm seu lugar, mas não mudarão a cultura de uma organização.

Este artigo detalha os elementos fundamentais que toda organização precisa para criar uma mentalidade e cultura Agile. As recomendações não devem ser seguidas cegamente. Cada organização deve aplicar o que faz sentido em um determinado ambiente.

Agendamento e ritmo

Não há comprimento de sprint perfeito. As equipes foram bem sucedidas com comprimentos de sprint que variam de uma a quatro semanas. O que mais importa é a consistência.

Selecione um comprimento de sprint que funcione para a cultura, o produto e o desejo da sua organização de fornecer atualizações. Por exemplo, a divisão ferramentas de desenvolvedor da Microsoft (cerca de 6.000 pessoas) funciona em sprints de três semanas. A equipe de liderança não escolheu esse comprimento de sprint; veio de comentários diretos das equipes de engenharia. Toda a divisão opera nesta agenda de sprint de três semanas. Desde então, os sprints tornaram-se o coração da organização. Agora cada equipe marcha ao ritmo do mesmo tambor.

É importante escolher um comprimento de sprint e ficar com ele. Se houver várias equipes Agile, todas elas deverão usar o mesmo comprimento de sprint. Se os comentários geram uma alteração, então seja receptivo. Ficará claro quando o termo certo estiver em vigor.

Uma cultura de envio

Peter Provost, Gerente de Programas do Grupo Principal da Microsoft, disse : "Você não pode enganar o envio". A simplicidade e a verdade dessa afirmação são uma pedra angular da cultura Agile. O que Peter significa é que enviar seu software ensinará coisas que você não pode e não entenderá a menos que você esteja realmente enviando seu software.

A natureza humana é atrasar ou evitar fazer coisas até que seja absolutamente necessário. Isso não poderia ser mais verdadeiro quando se trata de desenvolvimento de software. As equipes adiam bugs até o final do ciclo, não pensam em configuração ou atualização até que sejam obrigadas, e geralmente evitam questões como localização e acessibilidade sempre que possível. Quando esse padrão surge, as equipes acumulam dívidas técnicas que precisarão ser pagas posteriormente. O envio exige que todas as dívidas sejam pagas. Você não pode burlar o envio. Para estabelecer uma cultura Agile, comece tentando enviar o produto no final de cada sprint. Não será fácil no início, mas quando uma equipe tenta, eles rapidamente descobrem todas as coisas que deveriam estar acontecendo, mas não estão.

Equipes Saudáveis

Não há receita para a equipe agile perfeita. No entanto, algumas características importantes tornam o sucesso muito mais fácil de alcançar.

Localizar equipes conjuntamente sempre que possível

Uma equipe pode encontrar sucesso com pessoas espalhadas por diferentes geografias? Sim, mas é mais difícil. Quando as pessoas estão co-localizadas e sentadas na mesma sala, as conversas certas tendem a acontecer. Ainda é possível ter sucesso com equipes localizadas em todo o mundo e em fusos horários diferentes. Mas essa mesma equipe não teria uma vantagem sem todos esses obstáculos?

Manter as equipes intactas por um período razoável de tempo

Permitir que as equipes dominem a arte de criar software em conjunto. Quando as equipes são reorganizadas, qualquer dinâmica que elas desenvolveram se interrompe. Às vezes, é apropriado reorganizar, mas as equipes normalmente são mais produtivas quando recebem tempo para aprender a trabalhar juntas. Como diretriz, tente manter as equipes intactas por pelo menos 12 meses.

Trabalho de balanceamento de carga, não pessoas

Às vezes, as equipes ficam para trás e precisam de ajuda. Uma tática comum para resolver isso é emprestar uma pessoa de uma equipe para outra. No entanto, isso pode ser contraproducente. Uma solução melhor é distribuir a carga de trabalho para outra equipe, em vez de redistribuir pessoas entre elas. Puxar uma pessoa de uma equipe para ajudar outra interrompe ambas as equipes, e isso pode frustrar a pessoa que está sendo movida, mesmo que temporariamente. Tudo isso afeta a produtividade da equipe e, mais provável do que não, afeta negativamente a capacidade de voltar ao cronograma.

O trabalho de balanceamento de carga em vez de pessoas permite que uma equipe já estabelecida entre e ajude. Torna-se uma conversa sobre prioridades, não uma conversa sobre pessoas.

Permitir que as equipes gerenciem áreas de funcionalidades, não camadas de arquitetura

Esforce-se para criar equipes verticais que sejam responsáveis por áreas de funcionalidades. Essas equipes são responsáveis por todo o trabalho necessário para adicionar recursos à área, do banco de dados às alterações de interface do usuário. A equipe está capacitada para entregar e assumir a responsabilidade por uma experiência de ponta a ponta.

Quando as equipes horizontais possuem camadas de arquitetura, nenhuma equipe é responsável pela experiência de ponta a ponta. A adição de um recurso requer que várias equipes coordenem e exijam um nível mais alto de gerenciamento de dependência. A resolução de bugs exige que várias equipes investiguem se elas possuem o código necessário para corrigir o bug. Os bugs são repassados à medida que as equipes determinam que não é seu bug, sendo atribuídos a outra equipe.

As equipes de funcionalidade não têm esses problemas. A propriedade e a responsabilidade são claras. Pode haver um lugar para algumas equipes orientadas à arquitetura. No entanto, as equipes focadas verticalmente são mais eficazes.

Próximas etapas

À medida que as equipes embarcam em sua própria transformação Agile, tenha esses princípios fundamentais em mente. Lembre-se de que não há uma única receita que funcione para todas as organizações. Transformações ágeis são uma jornada. Faça alterações e aprenda com elas. Com o tempo, a organização desenvolverá a cultura Agile de que precisa.

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

Saiba mais sobre como o Azure DevOps permite que as equipes adotem e dimensionem uma cultura Agile.