Iterando! = Girando ? Ágil! = Agilidade

Charles Lambdin Blocked Unblock Seguir Seguindo 17 de dezembro de 2018

O psicólogo sueco Berndt Brehmer observou certa vez que nosso sentimento de "aprender" com a experiência pode ser enganoso. Às vezes, seria mais correto dizer que somos condicionados a acreditar que estamos aprendendo com a experiência, quando, na verdade, nosso julgamento não está melhorando (Brehmer, 1980). O mundo real, ele observou, tem pouca semelhança com o que chamamos de "aprendizagem" na escola. Uma sala de aula é um ambiente artificial onde um “padrão ouro” artificial é fornecido pelo professor. Lá, “aprender” é apenas ser capaz de entregar o que o professor pede. Isso é muito útil para a maioria dos trabalhos de produtos, onde no lugar do “professor” está o “negócio”. Isso não contribui para um ambiente de aprendizado, que é necessário para a agilidade.

Como Patton (2018) observou, trata-se de um arranjo cliente-fornecedor, no qual o “cliente” escolhe as apostas a serem feitas e o “fornecedor” as coloca. Normalmente, o “cliente” é recompensado por fazer com que os “fornecedores” façam mais apostas mais rapidamente, sem ninguém prestar muita atenção à precisão do próprio processo de apostas. Se os usuários abandonarem uma oferta e desenvolverem suas próprias soluções, isso não será vinculado àqueles que escolherem as apostas. Ele apenas se infiltra na forma de solicitações futuras de uma maneira desconectada e pouco informativa, e os “chamadores de disparos” procedem como de costume, sem se perguntar o quanto suas previsões realmente são boas.

Isso é parcialmente o que Schwartz (2016) estava argumentando em seu excelente livro, The Art of Business Value . Ao contrário da crença popular, o “negócio” normalmente não sabe o que vai fornecer valor melhor do que as equipes de TI da Scrum. Ignorar isso perpetua a abordagem de planejamento para o trabalho do produto, onde “sucesso” é igualado à entrega e “pronto” é apenas uma entrega. Isso reduz suas equipes ágeis para uma janela drive-thru.

Agora, e se um laboratório de pesquisa fosse avaliado em sua “produção experimental”, sem ninguém realmente se concentrar na interpretação e na importância prática dos resultados produzidos? Aplique isso ao trabalho do produto. Isso tenderia a diminuir ou aumentar os custos? Aumente, duh. Se você não se concentrar em apoiar as hipóteses, não será possível avaliar se pode haver maneiras mais rápidas e mais baratas de testá-las. Isso nos leva a uma questão fundamental com o movimento Ágil. Agile manteve o foco na saída e nos “requisitos”, ignorando que a entrega nunca é um bom padrão ouro. Em muitos contextos isso apenas cria desperdício.

Os agilistas gostam de combater com o refrão que não há valor “até que o software de trabalho seja entregue”, mas isso é igualmente enganoso. Realmente, não há valor até que o valor seja criado e a maioria dos softwares codificados tenha valor real negativo (veja abaixo). Além disso, entregar software não é a única maneira de criar valor, uma epifania que uma “equipe de entrega de software” provavelmente não terá. Alguém treinado em pesquisa de design, facilitação e pesquisa pode remover muitas dúvidas em algumas horas, mesmo no Skype. Se você realmente acha que só pode remover adivinhações ao fornecer incrementos de produtos, provavelmente está desperdiçando muito dinheiro – você está exagerando em seus testes de suposição.

O valor é qualquer que seja o valor do negócio e os caminhos para o valor (impacto) devem ser tratados como hipóteses (ou apostas). Isso pode (e deve) ser mapeado de maneira semelhante ao conceito de mapeamento de impacto de Adzic (2012). Abaixo está um exemplo genérico usando a terminologia Lean UX. Como Adzic ressalta, a maioria dos laços de trabalho do produto é transmitida diretamente aos atores (usuários), o que gera desperdício. Ele negligencia a sinalização de pivô claro.

Agora, considere a sugestão de Reinertsen de que é melhor pensar em “agilidade” como sua capacidade de girar , mudar de direção (ver Powers, 2016). A implicação de algumas entrevistas parece ser que o Lean Startup tem mais a ver com agilidade real do que o Agile. A maioria das equipes “Agile” está fazendo Scrum, que eu usei para tentar conciliar com o Lean Startup argumentando que “iterar” é semelhante a “pivotar”… mas na verdade não é.

Agile é frequentemente dito ser “incremental e iterativo”. O “incremento” é o pedaço do produto entregue no final da caixa de tempo. Então você repete o ciclo e entrega outro incremento no final da próxima caixa de tempo. Essa repetição é o que o Ágil significa por “iterar”, que não é a mesma coisa que girar. Para "girar", pode ser necessário descartar seus incrementos anteriores de produtos e tentar algo totalmente diferente. Quase nenhuma equipe Agile faz isso, um ponto que Alan Cooper vem fazendo há anos. Normalmente, as equipes Agile não estão tomando decisões de “pivot ou stop” – elas apenas “persistem” gradativamente e chamam de “iteração”. Elas não rejeitam hipóteses e tentam outras maneiras de alcançar resultados. Eles não podem, porque isso não é algo que alguém está prestando atenção! (Fale sobre fragilidade!)

O resultado prático é que quanto mais incrementos de produto são adicionados, menos graus de liberdade existem, o que, quando você pensa sobre isso, é realmente o oposto de “agilidade”. Agora, como Allen Holub gosta de me lembrar, não existe coisa como "Ágil". Há o Manifesto, e há diferentes pessoas sobre isso, e é isso. A maioria das organizações compara Agile com o período “Scrum”. Sutherland descobriu como vender o Scrum para empresas com a promessa sedutora de “duas vezes o trabalho na metade do tempo” (então… quatro vezes o trabalho?). Embora isso possa ser como o “negócio” tende a pensar no Agile, ele não tem muito a ver com agilidade. Outros co-autores do Manifesto têm outras ideias. Jeffries, por exemplo, tem sido muito inflexível ultimamente que ele não se importa com a organização e que o objetivo do Agile é tornar a vida melhor para os desenvolvedores. Note que o negócio leva muitas vezes o efeito oposto.

ESTÁ BEM. De volta aos resultados. Muitas vezes, argumenta-se que a maneira de sair dessa bagunça é colocar “resultados acima da produção”, mas mesmo isso pode ir de lado dependendo das definições usadas. Os resultados são melhor descritos no livro Lean UX (Gothelf & Seiden, 2013). Muitos parecem equiparar os resultados a metas ou objetivos vagos, o que não leva em conta o objetivo. (Na minha opinião, é por isso que o conceito de OKRs não agrega valor.) Um “resultado” não é “impacto”, o que é provavelmente o seu objetivo real. Um resultado é a mudança concreta de comportamento que você está tentando criar para gerar impacto nos negócios. Isso destaca um ponto que vi pela primeira vez no Design de Interação Sedutora de Anderson (2011): Há apenas uma maneira de criar valor de negócios, e isso é mudar o comportamento de alguém. Tratar "entrega" como um proxy para isso é curto. (É por isso que o custo do atraso deve, em última instância, estar vinculado aos resultados – o valor não é criado até que a mudança de comportamento que agrega valor realmente aconteça.)

Qualquer um que tenha brincado com isso saberá que pode ser muito desafiador levar as pessoas a declararem resultados concretos. Curiosamente, o mesmo ponto é feito na terapia, e as melhores técnicas que eu encontrei para extrair resultados, na verdade, vêm da terapia e da mudança de trabalho! Foi na leitura sobre Linguagem Limpa e Modelagem Simbólica que aprendi que as pessoas naturalmente gostam de falar sobre “problemas” e “soluções”, enquanto que obter bons resultados normalmente requer treinamento qualificado . Falar sobre problemas pode ser catártico, mas o objetivo não é estar em terapia por décadas. O que muda, especificamente, você está tentando criar? Como você vai saber quando a terapia é "feita"? Não é quando é entregue! É quando certas mudanças sustentáveis acontecem.

Aplique isso ao trabalho com produtos: equipes ágeis também tendem a pensar em seu trabalho em termos de “problemas” e “soluções”. Na verdade, tendemos a chamar o que construímos de “solução”, ignorando que isso é amplamente metafórico. Quando você resolve um problema de matemática, por exemplo, o problema é conhecido, é um dado adquirido. No trabalho com produtos, no entanto, o “problema” assumido muitas vezes não é o problema real. Além disso, um problema de matemática normalmente tem uma “solução” objetiva e única. Isso simplesmente não se aplica ao mapa. O que você está construindo não é “A SOLUÇÃO”. O que você pede para “resolver” normalmente não é “O PROBLEMA”. Há também uma diferença psicológica de orientação. Um quadro de solução de problemas tem uma orientação negativa, longe de. Um “problema” é algo que precisa ser evitado ou remediado.

Um quadro de resultados, por outro lado, é um quadro positivo. Tem uma orientação “para”. Às vezes vejo pessoas dizendo que alcançar um resultado é a mesma coisa que resolver um problema. Não realmente embora. Como Tompkins e Lawley (2006) observam, saber do que você está se afastando não significa que você sabe para onde você quer ir . Eu encontrei isso muitas vezes em um exercício que eu gosto de correr em classes. Eu tenho equipes de pessoas freelist, affinitize, e dot vote em resposta à pergunta, "Quais são os seus problemas difíceis com a entrega de valor para os clientes?" O cluster superior que emerge é quase sempre o mesmo. É uma variação de "ninguém pode realmente dizer o que estamos tentando alcançar".

Sem resultados concretos desejados no lugar, você não tem o que eu venho chamando de "sinais de pivot inequívoco". Um resultado lhe dá uma linha na areia, deixando você saber se deve girar, persistir ou parar. É uma mentalidade completamente diferente. Como Tompkins e Lawley colocaram, investigar um problema e criar uma “solução” geralmente restringe suas opções, o que reduz os caminhos para o valor. Em vez disso, destacando o resultado desejado, você abre o campo e alavanca maior criatividade no serviço de descobrir maneiras diferentes de alcançá-lo. Isso aumenta as opções, que devem ser um dos seus principais objetivos.

Em vez do arranjo cliente-fornecedor, onde o “cliente”, um representante de negócios, informa às equipes ágeis o que construir, e se você, em vez disso, trabalhar com o cliente para alinhar em quais resultados deseja alcançar? Isso mantém os graus de liberdade não gastos, permitindo que o caminho adiante surja como garantido pelas evidências. Agora, como Kohavi et al. (2009), com razão, há alguns que percebem isso como uma "perda de poder".

Muitos de nós já vimos os famosos resultados de Kohavi da plataforma de testes A / B da Microsoft: Para produtos existentes, quando você muda o foco para se as métricas de resultado são afetadas positivamente, um total de 66% do que é construído tem valor zero ou negativo. Em outras palavras, o que foi entregue não teve efeito sobre as medidas de desfecho ou piorou . Apoiando um fracasso ainda custa dinheiro, no entanto, para não mencionar o custo de oportunidade de não ter entregue algo mais valor acrescentado.

Quando os representantes de negócios insistem nesses pontos, Kohavi et al. observe, eles estão essencialmente afirmando que uma abordagem empírica para o trabalho do produto não é necessária. Se isso for verdade, no entanto, eles devem ser capazes de prever os resultados dos testes de hipótese que alegam serem desnecessários . Em outro experimento, Kohavi et al. Também testei isso, pedindo que as pessoas adivinhassem os resultados de oito testes A / B. Qualquer um que conseguisse prever os resultados de seis ganharia uma camiseta. Depois de mais de 200 tentativas, eles acabaram dando… camisas zero. Dos oito palpites, os participantes estavam corretos em média 2,3 vezes, ou seja, suas previsões estavam erradas mais de 70% do tempo.

Se você não vê a importância disso, provavelmente está apostando muito dinheiro no palpite, na paixão e na defesa das pessoas. Isso demonstra a importância da opcionalidade, que a Lean Enterprise vincula ao conceito de antifragilidade de Taleb (Humble, Molesky e O'Reilly, 2015; Taleb, 2012). O resultado é um princípio fundamental: se suas suposições estiverem erradas com mais frequência do que certas, você não deve otimizar por estar certo.

Para encerrar, não estou dizendo que não devemos mais falar sobre problemas ou soluções, apenas que devemos estar mais conscientes de como os conceitos influenciam o pensamento. Palavras têm consequências e metáforas carregam bagagem. Em última análise, eu concordo com Kees Dorst (2015), que argumenta que grande parte do fracasso na aplicação do design thinking aos negócios vem de manter o foco na geração de “soluções” em oposição aos frames . (Eu escrevi sobre quadros de problemas aqui .) No próximo post, precisaremos falar sobre técnicas para obter resultados, bem como o que resulta em um bom resultado. Por enquanto, vou deixar você com esse pensamento:

Referências

Adzic, G. (2012). Mapeamento de impacto: Fazendo um grande impacto com produtos e projetos de software. Reino Unido: Provocando Pensamentos Limitados.

Anderson, SP (2011). Design de interação sedutora: criando experiências de usuário lúdicas, divertidas e eficazes. Berkeley, CA: Novos pilotos.

Brehmer, B. (1980). Em uma palavra: não por experiência. Acta Psychologica, Volume 45, Issues 1–3, pp. 223–241.

Dorst, K. (2015). Inovação de quadros: crie um novo pensamento por design. Cambridge: o MIT Press.

Gothelf, J. & Seiden, J. (2013). Lean UX: Aplicando princípios do Lean para melhorar o UX. Sebastopol, CA: O'Reilly Media, Inc.

Humble, J., Molesky, J. & O'Reilly, B. (2015). Empresa enxuta: como as organizações de alto desempenho inovam em escala. Sebastopol, CA: O'Reilly Media, Inc.

Kohavi, R., Crook, T., Longbotham, R., Grasca, B., Henne, R., Ferres, JL e Melamed, T. (2009). Experimentação online na Microsoft. Retirado em 18 de outubro de 2016 de: http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf .

Patton, J. (2018). 5 coisas que você precisa para corrigir a propriedade do produto Agile. Abra a caridade. Retirado em 17 de dezembro de 2018 de: https://www.youtube.com/watch?v=bgdVJVeqHX8 .

Poderes, S. (2016). Aventuras com entrevistas ágeis – Don Reinertsen. LinkedIn. Consultado em 3 de fevereiro de 2017 a partir de: https://www.linkedin.com/pulse/adventures-agile-interviews-don-reinertsen-simon-powers .

Schwartz, M. (2016). A arte do valor comercial. Portland, OR: IT Revolution.

Taleb, NN (2012). Antifragile: Coisas que ganham da desordem. Nova Iorque: Random House.

Texto original em inglês.