Falta de comprometimento: 5 disfunções de uma equipe de DevOps

Este é o terceiro de uma série de postagens sobre a cultura DevOps e as lições aprendidas com o livro de liderança de Patrick Lencioni, The Five Dysfunctions of a Team - A Leadership Fable.

• 5 Disfunções de uma equipe de DevOps: ausência de confiança, explorou como a confiança é a base da adaptação da cultura de sua equipe para se transformar para o movimento DevOps.
• 5 Disfunções de uma equipe de DevOps: medo do conflito, explorou como as equipes de alto desempenho não têm medo de se envolver em um diálogo apaixonado sobre questões e decisões que são fundamentais para o negócio ou missão.

Agora eu gostaria de explorar a terceira disfunção de uma equipe - falta de comprometimento.

Falta de compromisso

A terceira disfunção é a falta de comprometimento entre os membros da equipe. No contexto de uma equipe, o comprometimento é uma função de duas coisas: clareza e adesão. Grandes equipes tomam decisões claras e oportunas e avançam com total adesão de todos os membros da equipe, mesmo aqueles que votaram contra a decisão.

Uma das tendências fascinantes que estamos começando a ver em toda essa coisa de DevOps é que muitas organizações estão participando de uma forma ou de outra de colaboração entre as principais partes interessadas, mas que a definição de como é o sucesso de sua iniciativa de DevOps não é clara, o que cria ambiguidade em toda a equipe e negócios. Como o DevOps pode ser bem-sucedido se os critérios de sucesso não forem claramente articulados? As empresas estão "fazendo DevOps" apenas para fazer isso ou há uma transformação em andamento? E alguém fora do projeto skunkworks que você está liderando sabe o que é DevOps?

O DevOps precisa de uma melhor definição e adesão imediata em torno de objetivos e entregas. E não existe uma abordagem única para DevOps, mas sim um conjunto emergente de requisitos críticos para 'fazer DevOps'. Mas um sinal de alerta para você estar atento é uma mentalidade de ferramentas ao discutir DevOps. As ferramentas têm um lugar definitivamente, mas lidar com essas questões culturais e organizacionais é o trabalho número 1.

Em uma pesquisa recente realizada pela UpGuard, descobrimos que 27% de todas as iniciativas de DevOps estavam sendo conduzidas de cima para baixo. Por outro lado, mais de 36% de todas as iniciativas de DevOps são consideradas um movimento de base.

O DevOps ainda está em seu estágio inicial, onde mais startups têm vantagem sobre empresas maiores devido à falta de dívida financeira, política e técnica. Além disso, ainda há confusão entre as partes interessadas sobre o que é DevOps, por que eles estão fazendo isso e como é o sucesso. Essa incerteza cria uma falta de adesão dos executivos, o que pode levar a um perigoso efeito cascata. Você pode ter uma equipe incrível que confia uns nos outros e não tem medo de lidar com os problemas difíceis diretamente, mas sem o compromisso de todos os seus colegas de negócios (operações, desenvolvimento, controle de qualidade, gerenciamento de serviços, segurança) e equipes de liderança (gerenciamento, executivos), você vai se desacelerar para alcançar a grandeza.

Conclusão

DevOps é um termo ruim para uma abordagem revolucionária de como a TI é entregue. Tenho poucas dúvidas de que organizações de todas as formas e tamanhos precisam de melhor adesão em torno de objetivos e entregas no que se refere à sua iniciativa de DevOps. Todos nós sabemos que os ciclos de feedback são críticos (abordaremos isso em outro momento), mas uma vez que a clareza de propósito é alcançada e comunicada, deve ser sobre entender o que você tem e se preparar para a automação. Porque lembre-se... Você não pode automatizar o que não entende. Não se trata de buscar consenso (isso é impossível), mas sim de se reunir em torno de qualquer decisão que seja tomada pelo grupo.