Adotando uma cultura Agile

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

O movimento Agile tem como foco descobrir continuamente maneiras de aprimorar a abordagem e a prática da criação de software. Não se trata de um standup diário perfeito ou retrospectiva. 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.

Agile culture

Este artigo detalha os elementos fundamentais que toda organização precisa para criar uma mentalidade e cultura Agile. Eles não devem ser seguidos cegamente, mas sim aplicar o que faz sentido em um determinado ambiente.

Agendamento e ritmo

É importante entender que não há comprimento de sprint perfeito. Teams foram bem sucedidos com diferentes comprimentos de sprint que variam de 1 a 4 semanas. O que realmente importa é a consistência.

Selecione um comprimento de sprint que funcione para a cultura, o produto e o desejo de uma 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 escolha de um sprint de três semanas não foi feita pela equipe de liderança ou outros gerentes; 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 se tornaram a pulsação da organização. Agora cada equipe está marchando para a batida 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 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 as coisas até que seja absolutamente necessário. Isso não poderia ser mais verdadeiro quando se trata de desenvolvimento de software. Teams bugs de punt até o final do ciclo, não pense em instalação ou atualização até que eles sejam forçados e normalmente evitem coisas como localização e acessibilidade sempre que possível. Quando esse padrão surge, as equipes estão acumulando dívidas técnicas que precisarão ser pagas posteriormente. O envio exige que toda a dívida seja paga. Você não pode enganar 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 íntegras

Não há receita para a equipe agile perfeita. No entanto, há algumas características importantes que facilitam muito o sucesso de uma equipe agile.

Localizar equipes sempre que possível

Uma equipe pode encontrar sucesso com pessoas espalhadas por diferentes geografias? Claro, 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 êxito 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 juntos. Quando as equipes estão mexidas, isso interrompe qualquer química que possam ter desenvolvido. Há momentos em que é apropriado reorganizar equipes. No entanto, as equipes normalmente funcionam melhor quando recebem tempo para aprender a trabalhar juntas. Como diretriz, tente manter as equipes intactas por pelo menos doze 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 é balancear o trabalho de carga para outra equipe, em vez de balancear a carga de pessoas entre elas. Tirar uma pessoa de uma equipe para ajudar outra interrompe ambas as equipes e pode frustrar a pessoa que está sendo movida, mesmo que temporária. 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 para outra equipe permite que uma equipe já estabelecida entre e ajude. Torna-se uma conversa prioritária e não uma conversa de pessoas .

Teams deve possuir áreas de recursos, não camadas de arquitetura

Procure criar equipes verticais que possuem áreas de recursos. Essas equipes são responsáveis por todo o trabalho necessário para adicionar recursos à área, do banco de dados às alterações da interface do usuário. A equipe tem o poder de entregar e ter uma experiência de ponta a ponta.

Equipes horizontais que possuem uma camada de arquitetura significa que nenhuma equipe é responsável pela experiência de ponta a ponta. Adicionar um recurso requer várias equipes para coordenar e requer um nível mais alto de gerenciamento de dependência. A resolução de bugs requer que várias equipes investiguem se elas possuem o código necessário para corrigir o bug. Os bugs são rebatidos à medida que as equipes determinam que não é seu bug e o atribuem a outra equipe.

As equipes de recursos não têm esses problemas. A propriedade e a responsabilidade são claras. Pode haver um lugar para algumas equipes baseadas em arquitetura. No entanto, quanto mais verticalmente as equipes estiverem focadas, mais eficazes serão.

Próximas etapas

À medida que as equipes embarcam em sua própria transformação Agile, tenha esses princípios fundamentais em mente. E lembre-se, não há uma única receita que funcione para cada organização. 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 DevOps planejamento.

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