O elefante no quarto ágil

Charles Lambdin em Columbus 'Egg Seguir Mar 25 · 7 min ler

Um dos meus livros de negócios favoritos dos últimos anos é o fenomenal The Art of Business Value, de Mark Schwartz (2016). (Sua continuação, A Seat at the Table , também é fantástica.) A Art of Business Value habilmente chama Agile em basicamente esquivando-se de todos os assuntos de estratégia. Isso permitiu o Scrum, que é como a maioria das organizações aborda o “Ágil”, para consagrar o Modelo de Fast Food do trabalho do produto, com equipes IT Agile sendo esperadas para atender aos pedidos que o Negócio coloca no drive proverbial. O resultado foi, bem, Waterfall. Para misturar metáforas, há um elefante na sala, e é um imperador sem roupas. O principal argumento de Schwartz é que, embora o Agile tenha feito alguma melhoria em relação a Waterfall, não foi longe o suficiente. Como resultado, confundir o Agile com o melhor do produto moderno é ficar para trás.

A Waterfall tirou uma foto instantânea da informação e baseou um plano de longo prazo nela. A Agile percebeu que especificar requisitos de solução antes do trabalho do projeto é uma tarefa tola. Infelizmente, parou aí. Nas palavras de Schwartz,

… A suposição crítica que não foi contestada era que o negócio é responsável por determinar as necessidades do negócio – em outras palavras, para tomar decisões sobre o que agregaria valor ao negócio. Mesmo que a equipe e o negócio trabalhassem juntos iterativa e incrementalmente, era apenas o negócio que possuía a necessidade do negócio. A equipe de TI recebeu um feedback frequente da empresa sobre se estava "atendendo à necessidade" e ajustou o curso de acordo. A essência do modelo ainda era que a TI não fazia parte do negócio, mas novamente tomava uma ordem.

Nessa visão, o negócio comunica as necessidades e a TI deve preencher os pedidos feitos. Aqui, o “sucesso” é medido em termos de satisfação do cliente empresarial. Como ex-CIO, ele diz que sabe em primeira mão que o trabalho de TI não é “cumprir os requisitos de negócios”, como evidenciado pelo fato de que sempre que os resultados de negócios não são alcançados, o CIO não pode simplesmente dizer “e daí? Entregamos os requisitos que você nos deu. ” Ainda é uma falha de TI.

Em seu livro de 2009, The Real Business of IT , Hunter e Westermen chamam isso de “armadilha de valor”. Tratar o negócio como cliente de TI – e supondo que o cliente esteja sempre certo – limita o valor. Ele nega uma das coisas mais valiosas que a TI pode fazer, o que ajuda os gerentes de negócios a aprender como o negócio deve ser mudado, além de ajudá-los a desempenhar suas funções conforme implementam essas mudanças.

Ágil assumiu que o valor comercial é algo conhecido pelos negócios, mas não pelas equipes ágeis. Isso simplesmente não é verdade, diz Schwartz. O valor comercial não é uma fórmula secreta conhecida apenas pelo “negócio”. Não há magia secreta do MBA. Para escapar da armadilha de valor, a empresa precisa se associar com as equipes de TI ágil para descobrir o que será valioso à medida que as equipes fizerem seu trabalho . Nós já sabemos que a maioria dos recursos não cria valor, enfatiza Schwartz, então precisamos nos afastar de um modelo que finge que, se entregarmos apenas mais recursos, o valor comercial irá aparecer de forma mágica.

Ele está dizendo que quando a literatura Agile faz discutir o valor do negócio, que raramente atinge mais de alguma referência esotérica para “ROI”, que é, Schwartz argumenta, não é uma coisa útil para se concentrar. Por exemplo, Ken Schwaber (2004), assim como Craig Larman e Bas Vodde (2009), afirmam que o Product Owner é responsável por “maximizar o ROI”. (Huh?) Larman e Vodde afirmam que quando o produto em questão venceu Para ser comprado por clientes externos, o Dono do Produto ainda é responsável pelo ROI escolhendo "os itens de maior valor de negócios e menor custo em cada sprint". Como Schwartz aponta, esse é um raciocínio circular.

Embora tecnicamente possa ser qualquer coisa, o "R" no ROI é geralmente a receita. Um dos pais do Scrum, Jeff Sutherland, afirmou que o Product Owner é responsável por “maximizar a receita por ponto de história” (ver Sutherland, 2013). Schwartz diz, com razão, que é hora de ligar para a BS nessa noção. O fato é que nenhum Product Owner realmente estima o ROI de uma história, nem deveria. Mesmo que, de alguma forma, um Product Owner tenha descoberto como aplicar um aumento médio projetado dividido por um custo médio projetado para itens de backlog individuais, isso nem sempre maximiza o valor do negócio. Há uma variedade de problemas tanto no ROI quanto no NPV que Schwartz discute, resumidos na tabela a seguir.

O ROI e o NPV são basicamente a tomada da Finance em Waterfall. Mas não devemos mais tomar todas as decisões antecipadas – as decisões devem ser tomadas no “último momento responsável”, certo? Se sim, por que estamos baseando as decisões em números estáticos derivados de decisões iniciais? Como Schwartz observa,

Parte do valor comercial que o desenvolvimento de software pode nos dar é a capacidade de responder a necessidades futuras desconhecidas. Podemos construir coisas de uma maneira que nos dê mais opções no futuro ou de uma forma que nos dê um aprendizado validado sobre o ambiente em que estamos. Em termos econômicos, podemos dizer que os esforços de desenvolvimento de software podem nos dar “opções reais” – isto é, opções para investir mais ou para não investir no futuro, dependendo do caminho que o mercado seguir.

O mais interessante é que Schwartz ainda aponta que o Scrum está em desacordo com o Lean Startup, e que o DevOps está firmemente do lado do Lean Startup. Aqui, a equipe não é uma receptora unidirecional de “necessidades de negócios”. Em vez disso, ela experimenta e alimenta as informações de volta ao negócio, ajudando a diferenciar a compreensão do valor do próprio negócio à medida que as descobertas são feitas. O negócio, então, não é o “cliente” da TI, mas ambos trazem suas perspectivas únicas para um relacionamento iterativo e colaborativo que busca deixar as ideias certas emergirem à medida que o trabalho avança. Como Schwartz coloca, o Agile introduziu uma visão dinâmica dos requisitos – agora é hora de introduzir uma visão dinâmica do valor . Nossa compreensão de valor, assim como nossas suposições sobre “requisitos”, deve evoluir com o tempo com base em novas informações.

Isso traz outro problema. No Scrum, o Product Owner é o OPYCLT – a única pessoa que você pode ouvir . A equipe Agile não deve receber ordens de mais ninguém . Isso, Schwartz observa, soa suspeitamente como comando e controle, outro conceito que DevOps elimina. Isso deixa o Scrum em uma situação estranha: no DevOps, os gerentes não ditam mais o trabalho para as equipes de produto, então por que os Product Owners? Bem, dizem alguns, o Dono do Produto pode dizer ao time o que fazer, mas não como fazê-lo … mas é exatamente isso que os bons gerentes fizeram, de qualquer maneira, observa Schwartz. Bem, talvez a vantagem seja que alguém deve ter a palavra final quando se trata de priorização e recursos…. Sim, diz Schwartz, e esse era o gerente. Então, novamente, qual é a diferença?

A tomada de decisão deve ser descentralizada para as próprias equipes Agile, algo que o Scrum evita. No Scrum, as equipes têm a tarefa de criar recursos que não escolhem nem podem supervisionar a adoção. Isso é errado, argumenta Schwartz. O trabalho do produto é um esporte de equipe e as equipes ágeis devem possuir a entrega de valor. A equipe deve ser capaz de interagir com a organização e ajudar a determinar e obter valor. O Product Owner não deve ser um intermediário. A equipe do Agile deve continuamente provocar e observar, sentir e responder, e se aventurar além de suas retrospectivas, o que mantém a equipe focada em seus próprios processos internos.

O Product Owner, argumenta Schwartz, é uma posição de liderança em um Sistema Adaptativo Complexo (CAS). O Product Owner pode ajudar as equipes a enquadrar as medidas em torno de sua saída para mostrar o valor que elas adicionaram. Mas, como Schwartz pergunta, como a liderança conhece os indicadores corretos de valor de negócios a serem seguidos para alcançar os resultados corretos? Não pode, ele diz. Líderes, assim como equipes ágeis, só podem postular uma hipótese, observar resultados e alterar seu curso de acordo. E isso nos leva à definição de valor comercial de Schwartz: é uma hipótese mantida pela liderança sobre o que alcançará seus objetivos. É isso aí. Deve ser qualquer combinação de indicadores que os líderes considerem que leve a resultados mais fortes. No final, é tudo sobre experimentação. No próximo post, vamos dar uma olhada nas recomendações específicas de Schwartz.

Referências

Hunter, R. & Westerman, G. (2009). O verdadeiro negócio da TI: como os CIOs criam e comunicam o valor do negócio. Boston: Harvard Business Press.

Larman, C. & Vodde, B. (2009). Escalando o desenvolvimento Lean e Agile: ferramentas de pensamento e organizacionais para o Scrum em larga escala. Upper Saddle River, NJ: Addison-Wesley.

Schwaber, K. (2004). Gerenciamento ágil de projetos com Scrum. Redmond, WA: Microsoft Press.

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

Sutherland, J. (2013). Conheça os princípios básicos do Scrum: acerte sua velocidade. Scruminc. Consultado em 7 de dezembro de 2017 a partir de: