Caro Agile, Estou Cansado de Fingir

Charles Lambdin Blocked Unblock Seguir Seguindo 20 de novembro de 2018

"Ágil está morto." As pessoas continuam dizendo isso. Mas então eles dizem: "Estamos apenas brincando". Eles dizem que eles queriam dizer o jeito que você Agile está morto. E idiota. Mas o Agile "real" não está morto. É só que todo mundo faz Agile errado . Então eu acho que o Agile real é, você sabe, Agile na teoria . Até eu fiz isso. E sabe de uma coisa? Estou cansada de fazer isso.

Eu estava recentemente reunindo as mesmas velhas defesas online: “Mas, mas, mas o problema é o Waterscrumfall, não o Agile como pretendido no Manifesto… blá blá blá”. Então Bob Marshall me deu a informação. Ele basicamente disse: “Cala a boca Charles. O Manifesto Ágil é um pote. ”Ele fez alguns pontos que eu tinha que concordar. Eu pensei sobre isso. O resultado é este post.

Aqui está um teste para você. Como começa a primeira linha do Manifesto Ágil? Nenhum pico. Não sabe? Isso é bom. Não importa. Ele diz: "Estamos descobrindo maneiras melhores de desenvolver software …" Pare. Observe que ele diz “desenvolver software”. Ele não diz “inclinar-se para fora da sua organização”, “pagar dívidas de transformação”, “acabar com essa porcaria de comando e controle”, “concentrar-se nos resultados e melhorar trabalho de descoberta ”,“ consertando seu sistema orçamentário medieval ”, ou qualquer outra coisa que agregue mais valor e que as pessoas tenham tentado dar a ele. Mas a coisa é, quando as pessoas dizem que o Ágil pertence a toda a organização, é uma história revisionista. Isso é desonesto.

Note também que começa, "Nós estamos descobrindo …" Ele não diz: "Nós recebemos do alto …" Você não acha que aprendemos uma coisa ou duas desde 2001? Quero dizer, sim, a maioria das grandes organizações ainda estão presas em 1987, mas vamos lá. Ao contrário da crença popular, a foto abaixo não é realmente da assinatura Snowbird do Manifesto. Podemos finalmente parar de fingir o contrário?

O Manifesto serviu a um propósito, mas não vai levá-lo aonde você precisa ir. Então comece a estudar. Nosso conhecimento tem uma vida útil e, às vezes, não é tão longo quanto supomos. Todos nós temos colegas (geralmente líderes) que afirmam que “não têm tempo para aprender”, e você sabe, eles são muito confiantes no que eles acham que sabem. Então encontre uma boa lista de livros. Siga alguns bons blogs. Aqui está um começo: se você ainda não leu o Sense & Respond , o Lean Enterprise , um lugar na mesa e todo mundo é um agente de mudança , sugiro que o faça imediatamente. Seus líderes também.

Comece a ler as postagens de John Cutler, Melissa Perri, Bob Marshall, Allen Holub, Laura Klein, Erika Hall, Neil Killick e ramificar-se de lá. Todos eles concordam um com o outro (ou comigo)? Não, mas eles são espertos e eles vão te deixar mais esperta. Comece a ler e comece a incentivar os outros também. Fast Company diz que o CEO médio lê 60 livros por ano. Quantos livros seus líderes lêem? E o que eles estão lendo? (Artigos de HBR , relatórios do Gartner e romances de Maeve Binchy não contam.) Porque, sejamos francos, se seus líderes ainda estão tentando criar Scrum, então você está firmemente preso nos anos 80 e 90.

Então, vamos seguir com o aprendizado contínuo, e vamos parar de fingir que o Agile era algum tipo de cura para todos. Isso precisa ser dito: Agile é e sempre foi uma otimização local, proporcionando pouco ganho ao sistema. Tudo o que Agile fez foi colocar equipes de desenvolvimento de software injustamente sob um microscópio. Isso não faz nada para aumentar a agilidade organizacional. NADA. Curiosamente, Agile foi uma tentativa de, nas palavras de Ken Schwaber (ver o seu "unSAFe a qualquer velocidade"), "desfazer os danos que a Waterfall tinha feito", e ainda Agile nunca deu às organizações uma alternativa holística e viável para Waterfall. Porque há uma diferença entre teoria e prática. O trabalho do produto é mais sobre prática. Quando nos queixamos de "AINO" (Agile In Name Only), não estamos sendo honestos conosco mesmos.

Teoria vs. prática, lembra? Nós precisamos ser pragmáticos. Ágil na prática é quase sempre AINO. Parece um problema com o movimento em si, não é? Há coisas mais importantes para se aprender, incluindo (mas não limitado a) Lean UX, Lean Enterprise, Beyond Budgeting, Teoria das Restrições, Throughput Accounting, Design Thinking, DevOps, Marshall's Organizational Therapy, e assim por diante.

Por que, você poderia perguntar, o Lean UX estaria no topo da lista? Resultados, é por isso, um conceito largamente popularizado por Lean UX. Pense nisso: se você não sabe qual mudança de comportamento está tentando criar, então não saberá como deve realmente mudar. Se você não tem uma sinalização de pivot inequívoca, então você não pode ser realmente “ágil” em primeiro lugar. Isso é o que a agilidade é, afinal, girar . Alguns podem objetar e dizer: “Mas, mas, mas inspecionar e adaptar!” Claro. Teoria vs. prática, lembra? Não vejo equipes ágeis inspecionando e adaptando. Eu vejo equipes Agile adicionando incrementos de backlogs, conversando com Jira e Rally e agindo como se estivessem construindo muros de tijolos onde quer que fossem mandados.

O Agile na verdade tende a mascarar o problema central, que é uma falta bidirecional sistêmica de confiança vertical. Os treinadores Agile saem, piorando as coisas, com os gerentes falando Pig Latin e as equipes de desenvolvimento agora falando Esperanto. As equipes acreditam que a administração está quebrada e a administração acha que o foco ainda deve ser escopo, prazos e eficiência, ignorando que os prazos são arbitrários e as estimativas de tempo solicitadas são uma forma de desperdício . (Você sabia que os pontos da história foram realmente inventados para obscurecer o tempo e ajudar a aliviar esse problema? Isso saiu pela culatra também, não foi? Teoria vs. prática.)

Bem, adivinha quem vai ganhar? Dois campos com duas perspectivas radicalmente diferentes, mas com um campo recebendo avaliações de desempenho do outro? Se as equipes são como as pessoas cegas sentindo o elefante e discordando sobre o que é, então a liderança é como elefantes cegos pisando nas pessoas e concordando que são todos planos. A saída é reconhecer que o sistema é a equipe. Saia com as otimizações locais já, e perceba que a confiança é a questão ?1. Pare de colocar injustamente o dev em um microscópio e deixe todo mundo se esconder em uma caixa preta. (Por que não estamos tão preocupados com o funcionamento das equipes de estratégia? Ou como arquitetos legados são restrições no sistema?)

E enquanto estamos nisso, temos que parar de tratar equipes de desenvolvedores como eles trabalham em uma fábrica. Nós não estamos fazendo talheres de plástico. Estamos criando software. As mesmas regras não se aplicam. Não estamos executando a mesma receita testada e comprovada. Estamos criando receitas . Se você ainda não descobriu, é um trabalho de descoberta , não apenas entrega. Uma negligência na descoberta gera um desperdício enorme: recursos não utilizados e outros trabalhos que não atingem resultados. Isso expõe outra das falhas profundas do Agile. Ele supõe que os usuários ficarão bem ao serem tratados como porquinhos-da-índia: “Aqui, basta usar esse produto de porcaria, então vamos melhorá-lo.” Exceto que normalmente é deixado um produto ruim, não é? As melhorias futuras são consideradas "custo" desnecessário.

Mas mas, Agile se preocupa com o trabalho de descoberta! Mesmo? Seja honesto aqui. Teoria vs. prática, lembra? Se você projetar ou descobrir o trabalho para ganhar a vida, responda a essa pergunta. Como você costuma ser tratado quando trabalha com equipes ágeis? Você é visto como agregador de valor e pediu para ajudá-los a “inspecionar e adaptar-se?” Ou você é solicitado a “demonstrar seu valor?” Como Alan Cooper disse, quando você é solicitado a demonstrar seu valor, eles estão te avisando estão em um sistema que não valoriza você. Observe que eles estão pedindo a um colaborador individual para provar seu valor – eles não estão perguntando quanto de seu código realmente move as métricas de resultado na direção certa. Em outras palavras, eles ainda estão se concentrando nas pessoas e não no trabalho em si . Eles provavelmente ainda estão focados no custo, não no valor, ignorando onde a maior parte do valor está realmente vazando.

Se você fizer um trabalho de descoberta com equipes ágeis, na próxima vez em que for solicitado a "demonstrar seu valor", tente fazer isso. Comece fazendo-lhes perguntas. Eles sabem qual é o custo do atraso? Que exercícios eles estão usando para estimar isso? Quais resultados concretos eles estão tentando alcançar? Que proporção do que eles constroem realmente alcança suas métricas de resultado? Eles não sabem? Se existem maneiras mais rápidas e baratas de aprender o que construir além do código de embarque, eles estariam interessados em aprender? Qual é a eficiência do seu fluxo? Quão ruim é isso? Quanto desse tempo eles gastam preso em reuniões? Se houver jogos de design e atividades facilitadas que possam gerar melhores decisões em muito menos tempo, eles estariam interessados em aprender? Porque não vou mostrar a você o quanto sou valioso – vou ensiná-lo a criar mais valor em tudo que você faz .

Esta é uma maneira diferente de pensar. É meta. É estratégico. Como observa Austin Govella (e vale a pena deixar isso acontecer), tanto o Agile quanto o Waterfall estão focados na construção . Design é sobre validação . Se eles não estiverem interessados, procure outro lugar. Se eles são apenas cabeças para baixo, produzindo saída, concentrando-se no custo, eles nunca vão aprender o suficiente para perceber que você tende a obter mais do que você se concentrar (ahem, custo). Eles são uma fábrica de recursos. Fiança. Eles estão fingindo que estão criando cutelaria de plástico. Você tem coisas melhores para fazer. Porque o valor real é assegurado pelas opções e as opções são geradas pela descoberta . Quanto mais opções você gerar e mais flexível sua abordagem, mais caminhos possíveis existem para resultados positivos. O que eles estão tentando alcançar? Eles exploraram de três a cinco maneiras de alcançá-lo? Isso levará a uma melhor tomada de decisão por um longo caminho. Uma opção não é escolha. Dois é um dilema. Três, agora você está chegando a algum lugar.

Você já ouviu falar da Lei da Variedade Necessária? O componente com mais opções controla o sistema . Aplique isso à luta de poder estúpida “Agile vs. Waterfall”. Você tinha líderes tentando manter o controle do sistema no topo e equipes ágeis tentando direcionar o valor para mais perto da fonte (os usuários e clientes reais). A saída da guerra civil é ensinar as pessoas a gerar opções em todos os níveis . O caminho a seguir não é "Agile vs. Waterfall". É um trabalho inteligente de estratégia de cima para baixo da Waterfall com táticas empíricas de baixo para cima. O trabalho de design e descoberta ajuda com tudo isso .

Então … qual é a saída? É um foco inteligente em resultados claros, não em produtos, com resultados mapeados substituindo marcos planejados, com equipes de produtos confiáveis, não equipes de projeto, com poderes para avaliar suposições e descobrir o caminho mínimo para o valor.

Agora comece a aprender. (Imagem adaptada de John Cutler.)

Então… isso significa que o Agile está indo embora? Claro que não. Este é apenas um post no blog, bobo. Eu não tenho nenhum poder. E se eu tivesse o meu caminho, o Agile ainda não iria embora. O movimento Ágil fez muito do pensamento mencionado aqui possível. Além disso, ao contrário da crença popular, práticas ágeis não foram inventadas pelo movimento Ágil. Eles são anteriores a muitas décadas.

Então, não, eu não quero que o Agile vá embora.

Eu só queria que pudéssemos começar a ser mais honestos sobre isso.