Agile, DevOps, engenharia de plataforma A confusão paralisa os desenvolvedores

Como uma grande empresa de consultoria global, a UST concentra-se em ajudar as empresas a inovar e a melhorar a entrega de tecnologia, e grande parte do seu trabalho resultou de práticas de DevOps. Ao trabalhar com clientes, a empresa enfrenta regularmente questões como: como reduzir o tempo de lançamento no mercado e, ao mesmo tempo, melhorar a qualidade do código e o envolvimento dos engenheiros.

Eugene Sazhin, chefe de engenharia, plataforma de agilidade digital e soluções da UST Global, muitas vezes se pegava pensando: “Deve haver um conjunto abrangente de princípios que possamos formular, aderir e recomendar que nossos clientes também sigam para que eles alcancem melhores resultados em suas jornadas transformacionais.”

Isso é exatamente o que a Estrutura de Melhoria de Entrega publicada recentemente pela UST pretende fazer.

7 princípios para melhorar a entrega de software

A estrutura combina ideias derivadas de Lean, Agile e DevOps, bem como a Lei de Conway, Topologias de Equipe, DORA e a própria experiência da UST. Consiste em sete princípios fundamentais:

1. O fluxo é rei.
2. A positividade alimenta o fluxo.
3. Topologias de equipe orquestram o fluxo.
4. Os principais indicadores de desempenho (KPIs) orientam, não governam.
5. Os princípios Lean impulsionam a otimização.
6. Navegue pela Lei de Conway propositalmente.
7. Valorize a confiança em vez do desempenho e o desejo de aprender em vez da experiência.

O conceito de “fluxo” é uma grande parte da estrutura, e a UST está usando fluxo no sentido enxuto/organizacional, em vez de se referir ao estado de fluxo do desenvolvedor individual (embora os dois conceitos estejam intimamente relacionados). Ao definir “fluxo”, a UST escreve:

“Inspirando-nos nos princípios Lean, priorizamos a otimização de todo o fluxo de valor, e não apenas de peças isoladas. Eliminamos desperdícios, minimizamos a mudança de contexto e construímos um sistema onde o trabalho de desenvolvimento flui perfeitamente desde a concepção até a entrega.”

A estrutura geral é focada nos funcionários. O segundo princípio, “a positividade alimenta o fluxo”, fala sobre equilíbrio entre vida pessoal e profissional, autonomia, reconhecimento, crescimento pessoal e aprendizagem. Funcionários engajados e felizes são mais produtivos, mas outro fator é que uma transformação organizacional bem-sucedida exige a participação de todos os envolvidos, desde a liderança sênior até os funcionários locais. Descrevi em outro lugar como três das cinco transformações organizacionais nas quais estive envolvido não funcionaram conforme planejado. Em cada caso, a falta de adesão ou foco da liderança foi um fator importante que contribuiu para o fracasso.

Articulando seus princípios fundamentais

A lógica da UST para publicar seu Quadro de Melhoria de Entrega baseia-se na ideia de Simon Sinek de que se você articular publicamente seus princípios fundamentais, outras pessoas serão incentivadas a se juntar a você. Ao tornar a estrutura pública, o grupo de consultoria também convida a uma conversa, o que deverá permitir-lhes iterar e melhorar a estrutura. Ciclos rápidos de feedback são essenciais em qualquer organização que aprende.

Sazhin também diz que a publicação da estrutura ajuda os negócios de consultoria da empresa. Ele diz que se um cliente da UST “entende de onde viemos quando estamos enfrentando um problema com uma transformação, então poderemos nos conectar e trabalhar juntos, e teremos maiores chances de sucesso”. Por outro lado, se o cliente não concordar com os princípios, então “temos uma desconexão central e isso simplesmente não vai funcionar”.

Se uma empresa reivindica um conjunto de valores fundamentais, mas ninguém presta muita atenção a eles, eles não têm sentido. “Se você está comprometido com os valores fundamentais da estrutura”, disse Sazhin ao The New Stack, “isso significa que você está avaliando todas as suas ações e ideias em relação a esses valores fundamentais e deve filtrar aqueles que não o fazem. alinhar.” Por exemplo, se você está comprometido com um valor fundamental de positividade, então sua comunicação com os funcionários deve seguir esse valor. Você não deve permitir que o RH emita uma comunicação contendo ameaças; fazer isso seria quebrar um dos princípios básicos aos quais você afirma aderir e perderá a confiança. Recuperar a confiança perdida é extremamente difícil.”

A difícil questão da produtividade do desenvolvedor

Numa organização, a confiança flui do topo. Também é desconcertantemente fácil perder; não exibir os valores que você defende é uma forma, mas outras incluem demissões em grande escala quando uma empresa é lucrativa ou vincular avaliações de desempenho a estatísticas facilmente jogáveis.

Suspeito que quase todo mundo foi solicitado a implementar algo que acredita fortemente que não funcionará. Como parceiro responsável, às vezes você precisa recuar — mesmo se for uma empresa de consultoria que depende de deixar os clientes satisfeitos. Por exemplo, os clientes da UST frequentemente pedem uma forma de medir a produtividade do desenvolvedor e incorporar isso em seu fluxo. No entanto, Sazhin disse: “Na maioria das empresas, a produtividade do desenvolvedor tem sido amplamente mal compreendida e mal utilizada”.

A McKinsey foi duramente criticada por seu artigo sobre como medir a produtividade dos desenvolvedores. Mas a atitude subjacente ainda prevalece: a programação é redutível à digitação, então a produtividade equivale a commits do Git, linhas de código, bugs corrigidos ou outra estatística sem sentido. A realidade é que digitar não é a parte difícil da programação e, como Sazhin apontou: “Nenhuma dessas coisas é pertinente aos objetivos de negócios da equipe”.

Por exemplo, um engenheiro sênior que dedica seu tempo ajudando os membros mais jovens da equipe a resolver seus problemas provavelmente está fazendo o melhor possível para melhorar o desempenho da equipe. Mas nada disso será visível se suas avaliações de desempenho forem baseadas nas estatísticas de commit do Git.

O desejo de avaliar os desenvolvedores dessa forma vem do desejo de microgerenciar os membros da equipe e os indivíduos, de acordo com Sazhin. Ela surge da falta de confiança na capacidade de auto-organização de uma equipe. Mas esse pensamento não está alinhado com os princípios fundamentais da UST. Em vez disso, os líderes devem deixar as equipes descobrirem se alguém não está fazendo a sua parte, tornar seguro para as equipes expressarem suas preocupações e ajudar essa pessoa a melhorar (ou fazer mudanças mais drásticas).

Experimentando e evitando o pensamento mágico

Em vez de microgerenciar, argumenta Sazhin, os gerentes precisam “garantir que a equipe entenda quais são os objetivos, remover os impedimentos e depois avaliar se o que a equipe está entregando atende a esses objetivos de negócios”. Isso se reflete no quarto princípio da estrutura, “os KPIs orientam, não governam”.

Isto é importante porque a indústria tecnológica é propensa a pensamentos mágicos. Se nada atingir a produção sem a aprovação de um conselho de controle de mudanças que se reúne apenas duas vezes por ano, nenhuma quantidade de microsserviços fará com que a TI avance mais rápido. Mas muitas organizações parecem pensar que sim.

Da mesma forma, “as empresas dizem que querem ser ágeis”, disse Sazhin, “mas depois adotam o SAFe (Scaled Agile Framework), e isso é desconcertante para mim. Isso significa que eles entendem completamente mal o que é ágil. Você pode implementar o SAFe por anos sem nenhum resultado – e pode alegar que isso ocorre porque você não implementou o SAFe corretamente, mas não é.”

Como disse o consultor ágil Dan North, “o SAFe’s afirmou modelo de negócios é ‘um fornecedor de estrutura, plataforma, conteúdo de treinamento profissional e certificações’. Não há nada sobre o sucesso do cliente, nada sobre responsabilidade, nada sobre se a estrutura funciona.” Tudo parece muito distante da missão do Manifesto Ágil de “descobrir melhores maneiras de desenvolver software”.

Apesar disso, a indústria fez progressos, especialmente quando se trata de reduzir o tempo de obtenção de valor ou de como avançar rapidamente uma ideia para testá-la com os clientes.

Empresas como Amazon, Google, Intuit e Netflix realizam milhares de experimentos todos os anos. “Encorajo os funcionários (da Amazon) a percorrer becos sem saída e experimentar”, disse Jeff Bezos. “Tentamos criar ferramentas para reduzir o custo dos experimentos para que possamos fazer mais deles. Se você puder aumentar o número de experimentos de cem para mil, você aumentará dramaticamente o número de inovações que você produz.”

Você também precisa tornar seguro o fracasso dos experimentadores, já que a grande quantidade de experimentos não fará o que você espera. Isto, por sua vez, significa que os funcionários precisam de autonomia com forte confiança e segurança psicológica no centro. Para evitar o pensamento monocultural, uma empresa precisa de contratações diversificadas, e o trabalho remoto flexível desempenha um papel significativo ao aumentar a diversidade do conjunto de talentos disponíveis.

O que isso significa para acelerar a entrega de software

A entrega de software, em particular, precisa de equipes pequenas, autônomas e multifuncionais que construam unidades de software implementáveis ​​de forma independente. Normalmente, isso implica microsserviços ou Função como Serviço (FaaS), como AWS Lambda. As liberações para produção precisam ocorrer com a frequência necessária, com uma baixa taxa de falhas e um tempo de recuperação rápido de quaisquer falhas de implantação. Sabemos disso há duas décadas ou mais: a pesquisa DORA Accelerate, habilmente liderada por Nicole Forsgren, fornece até referências.

Sazhin enfatiza a importância de validar suas ideias e o progresso que você está fazendo para que quaisquer decisões sejam tomadas com base em dados e não no instinto. “É preciso especificar uma hipótese, reunir os dados da melhor forma possível e depois usar uma abordagem científica para melhorar”, disse ele. “Existe um padrão de pensamento comum de que algumas coisas são demasiado difíceis ou impossíveis de medir, pelo que a recolha de dados para análise científica é demasiado difícil ou mesmo inviável. Isso não pode estar mais longe da verdade.” Ele recomenda o livro Como medir qualquer coisa: encontrando o valor dos intangíveis nos negóciosde Douglas W. Hubbard, que mostra como conseguir isso com a ajuda de estimativas calibradas, análises estatísticas e simulações.

Por fim, Sazhin sugere ter uma rede de pessoas influentes que apoiam o seu trabalho. “Se você não os tiver, não obterá a mudança cultural necessária para a melhoria contínua”, disse ele. “Você precisa aumentar o número de agentes de mudança em sua organização, pessoas que estão ajudando ativamente as equipes nessa jornada. Eles devem estar completamente alinhados e comprometidos, mas o mais importante, devem ser apaixonados por essas mudanças”.

Para obter mais informações, baixe o white paper da UST Liberar o fluxo do desenvolvedor: uma estrutura para melhorar a entrega de software empresarial.

A postagem Agile, DevOps, Platform Engineering Confusion Stalls Devs apareceu pela primeira vez em The New Stack.