"Ágil está morto." As pessoas dizem isso o tempo todo. Mas eles necessariamente acrescentam: "Estamos apenas brincando". Eles meio que significavam que
você tinha práticas tão erradas e estúpidas que o Agile está morto para
você . Mas o Agile "real" não está morto. É só que todo mundo faz errado. Então eu percebi: o verdadeiro Agile é, você sabe, Agile
em teoria . Até eu o implementei. E você sabe o que? Estou farto disso.
Recentemente, vi a mesma defesa antiga em meus artigos: “Mas-mas-mas, o problema é a queda de água, o scrum e a implementação incorreta do Agile, a não observância do Manifesto ... blá blá blá.” Então Bob Marshall me disse a verdade. Ele disse: “Cale a boca, Charles. O manifesto ágil é o jarro que enchemos. Ele fez alguns comentários com os quais eu tive que concordar. Eu pensei sobre isso. O resultado foi este artigo.
Aqui está um teste para você. Como começa a primeira linha de um manifesto Agile? Não espie. Não sabe? Está tudo bem. Isso não importa. Ele diz: "Estamos descobrindo métodos mais avançados de desenvolvimento de software ..." Pare. Observe, ele diz: "desenvolvimento de software". Não diz: "puxando sua organização", "pagando dívidas pela transformação", "cortando-a com esse comando e controle de merda", "focando em resultados e melhorando o trabalho de abertura", "consertando seu sistema de orçamento medieval" ou qualquer outra coisa valor agregado mais avançado que as pessoas tentaram investir nele. Mas o fato é que quando as pessoas dizem que o Agile se refere a toda a organização, é revisionismo. Isto não é justo.
Observe também que começa "
Descobrimos ..." Ele não diz: "Recebemos do alto ..." Você não acha que aprendemos algo desde 2001? Quero dizer, sim, a maioria das grandes organizações ainda está presa em 1987, mas tudo bem, você. Ao contrário da crença popular, a foto abaixo não é realmente do ato de assinar o manifesto. Podemos finalmente parar de fingir?
O manifesto serviu a um propósito específico, mas não o levará aonde você precisa. Então comece seus estudos. Nosso conhecimento tem uma data de validade e não enquanto pensamos. Todo mundo tem colegas (geralmente chefes) que afirmam que "não têm tempo para aprender". Você mesmo sabe que eles são muito autoconfiantes em seus conhecimentos. Portanto, encontre uma boa lista de livros. Acompanhe bons blogs. Aqui está um começo: se você não leu
Sense & Respond ,
Lean Enterprise ,
Um lugar na mesa e
Todo mundo é um agente de mudança , sugiro que faça isso imediatamente. E para seus superiores.
Comece a ler as postagens de John Cutler, Melissa Perry, Bob Marshall, Allen Holub, Laura Klein, Erica Hall, Neil Killick e aqueles a quem se referem. Todos eles concordam um com o outro (ou comigo)? Não, mas eles são inteligentes e também o tornarão mais inteligente. Comece a ler e incentive os outros. A Fast Company diz que o CEO médio lê 60 livros por ano. Quantos livros seus líderes lêem? E o que eles lêem? (Os artigos da HBR, os relatórios do Gartner e os romances de Maeve Binchi não contam). Porque vamos ser sinceros: se seus líderes são mestres do Scrum, você está firmemente preso nos anos 80 e 90.
Vamos para o aprendizado contínuo e paramos de fingir que o Agile é algum tipo de cura. É necessário dizer: o
Agile é e sempre foi uma otimização local para um ligeiro aumento na eficiência do sistema . Somente o Agile injustamente colocou sob o microscópio uma equipe de desenvolvedores de software. Isso não aumenta a flexibilidade organizacional. NÃO. Curiosamente, de acordo com Ken Schwaber (veja seu “Inseguro a qualquer velocidade”), o Agile foi uma tentativa de “compensar os danos causados pela cachoeira”, mas nunca deu às organizações uma alternativa holística e viável à cachoeira. Porque existe uma diferença entre teoria e prática. Trabalhar em um produto é mais uma prática. Quando reclamamos do AINO (Agile In Name Only), não somos honestos consigo mesmos.
Teoria versus prática, lembra? Nós devemos ser pragmáticos. Ágil na prática é quase sempre AINO. Parece um problema com o próprio movimento, certo? De qualquer forma, há coisas mais importantes para aprender, incluindo (mas não limitado a) Lean UX, Lean Enterprise, além do orçamento, teoria das restrições, contabilidade de rendimento, Design Thinking, DevOps, Marshall Organizational Therapy, etc.
Você pode perguntar por que o Lean UX está no topo da lista? Devido ao fato de que,
em sua essência, o Lean UX populariza o conceito de orientação para resultados. Pense: se você não souber que tipo de mudança de comportamento está tentando criar, não entenderá suas ações. Se você não tiver um sinal de rotação claro, não poderá mais ser flexível. Afinal, é isso que o Agile é pivotante. Alguns podem objetar: “Não, não, verifique e se adapte!” Claro. Teoria versus prática, lembra? Não vejo equipes flexíveis que testem e se adaptem. Vejo equipes ágeis tentando recuperar o atraso, brincando com Jira e Rally e trabalhando como se estivessem construindo um muro de tijolos sob ordens.
O Agile realmente tende a mascarar o problema principal - essa é uma falta sistêmica e bidirecional de confiança vertical. Os Agile Coachis partem, agravando a situação: eles deixam para trás gerentes que falam porcos e uma equipe de desenvolvimento que mudou para o Esperanto. As equipes acreditam que o gerenciamento está quebrado e o gerenciamento acredita que o foco principal ainda deve estar no volume, no tempo e na eficiência, ignorando que os cronogramas são arbitrários e as estimativas de tempo são uma
forma de desperdício . (Você sabe quais pontos da história realmente inventaram para
esconder o tempo e ajudar a resolver o problema em si? Também houve conseqüências desagradáveis aqui, certo? Teoria e prática).
Adivinha quem vai ganhar? Dois campos com duas perspectivas radicalmente diferentes. Onde um campo obtém classificações do outro? Se as equipes são como pessoas cegas que sentem um elefante e discordam do que é, então a liderança é como elefantes cegos atacando as pessoas e concordando que todas elas são planas. A solução é reconhecer que o sistema é
uma equipe. Conclua já com otimizações locais e perceba que a confiança é o problema número 1. Pare de colocar injustamente os desenvolvedores sob o microscópio, permitindo que outros se escondam em uma caixa preta. (Por que não estamos interessados em como as equipes de desenvolvimento estratégico funcionam? Ou como são as restrições do sistema de arquitetos legados?)
E enquanto fazemos isso, devemos parar de tratar as equipes de desenvolvimento como se estivessem trabalhando em uma fábrica. Não carimbamos pratos de plástico. Criamos software. Você precisa parar de agir como se estivéssemos
servindo uma pizzaria . Aqui estão as outras regras. Não usamos a mesma receita comprovada.
Desenvolvemos receitas . Se você ainda não entendeu, isso é trabalho de abertura, não apenas entrega. Negligenciar a descoberta leva a perdas maciças: funções não utilizadas e outros trabalhos que não alcançam resultados. Isso revela outra falha profunda do Agile. Ele sugere que os usuários possam ser vistos como cobaias: "Ei, basta usar este produto de merda, então vamos melhorá-lo". Exceto que o produto de merda geralmente permanece assim, não é? Melhorias futuras tornam-se "custos" desnecessários.
Mas, mas, mas, o Agile está realmente focado na pesquisa! Certo? Seremos honestos. Teoria versus prática, lembra? Se você ganha a vida projetando ou pesquisando, responda a esta pergunta. Como você costuma se sentir ao trabalhar com equipes flexíveis? Você é inicialmente visto como valor e solicitado a ajudar a "testar e se adaptar"? Ou você está sendo solicitado a "provar o seu valor"? Como Alan Cooper disse, quando você é solicitado a "provar seu valor", você fica claro que está em um sistema que não o valoriza. Observe que eles estão pedindo a um participante individual para provar seu valor - eles não estão perguntando quanto de seu código realmente influencia os indicadores na direção certa. Em outras palavras, eles ainda se concentram nas pessoas,
não no trabalho em si . Eles provavelmente ainda estão focados em ossos, não em valor, ignorando áreas onde uma parte significativa do valor realmente flui.
Se você trabalha com equipes flexíveis, na próxima vez que for solicitado a "mostrar seu valor", tente isso. Comece fazendo perguntas a
eles . Eles sabem qual é o preço do atraso? Quais exercícios eles usam para avaliar esse parâmetro? Que resultados específicos eles estão tentando alcançar? Qual proporção de seu produto realmente atinge seu desempenho? Eles não sabem? Se houver maneiras mais rápidas e baratas de descobrir o que desenvolver, além de liberar o código, eles estão interessados em aprender? Qual é a eficiência do fluxo? Quão ruim é isso? Quanto tempo eles gastam nas reuniões? Se houver jogos de designers e ações simplificadas que levarão a melhores soluções em muito menos tempo, eles estão interessados em aprender? Porque não vou apenas mostrar meu valor, ensinarei você a criar mais valor
em tudo o que você faz .
Esta é uma maneira diferente de pensar. Isso é meta. Isso é estratégico. Como observa Austin Gowella, tanto o Agile quanto a cascata estão focados no
desenvolvimento . Design é um
teste . Se eles não estiverem interessados, você pode sair. Se eles simplesmente abaixarem a cabeça para lançar um produto, concentrando-se nos custos, eles nunca saberão o suficiente para entender que você geralmente obtém mais do que aquilo em que se concentra (hum, ossos). Esta é uma fábrica de recursos. Responsabilidade mútua. Eles fingem criar pratos de plástico. Você tem coisas mais importantes a fazer. Porque o valor real é fornecido por opções geradas por meio de
pesquisa . Quanto mais opções você criar e mais flexível sua abordagem, mais caminhos possíveis e melhores resultados. O que eles estão tentando alcançar? Eles exploraram de três a cinco maneiras de conseguir isso? Isso levará a melhores tomadas de decisão para o futuro. Uma opção não é uma escolha. Dois é um dilema. Três - agora você conseguiu algo.
Já ouviu falar da Lei da Diversidade Necessária? O componente com mais opções
controla o sistema . Aplique-o à estúpida luta pelo poder de Agile vs. Waterfall. Você tinha executivos que tentaram manter o controle do sistema de cima e equipes flexíveis que tentaram trazer valor para mais perto da fonte (usuários e clientes reais). A saída de uma guerra civil sem sentido é ensinar às pessoas como gerar opções
em todos os níveis . O caminho a seguir não é ágil contra uma cachoeira. Esse é um trabalho estratégico de cima para baixo (cascata) inteligente, com táticas de baixo para cima empiricamente orientadas. O design e a descoberta ajudam nos dois casos.
Então ... qual é a solução? Esse é um foco razoável em resultados claros, não na entrega, com resultados planejados em vez de marcas planejadas, não no projeto, mas com equipes de produtos confiáveis autorizadas a verificar suposições e encontrar o caminho mais curto para o valor.
Agora para treinamento (adaptado com base no gráfico de John Cutler).
Então ... isso significa que o Agile está saindo? Claro que não. Este é apenas um post idiota do blog. Eu não tenho poder E mesmo que fosse, o Agile ainda não desapareceria.
O movimento Agile tornou possível muitos desses conceitos . Além disso, contrariamente à crença popular, as práticas ágeis não foram inventadas pelo movimento Agile. Eles apareceram décadas antes.
Então não, não quero que o Agile saia.
Eu só quero que sejamos mais honestos.