Não estamos em uma corrida de revezamento, como aquele quadro kanban/scrum parece sugerir de vez em quando. Esse jeito de ver o desenvolvimento de produtos e soluções deveria ter sido definitivamente escanteado lá em meados dos anos 1980, quando Takeuchi e Nonaka nos apresentaram o jeito scrum de pensar – ou, melhor dizendo, o jeito japonês de desenvolver produtos².Outro trabalho seminal da dupla, Gestão do Conhecimento (Bookman, 2008), inspirou a matriz ao lado. No eixo horizontal navegamos do entendimento de um problema (análise) até a criação da solução (síntese). Na vertical diferenciamos a natureza de nossas fontes, matérias-primas e artefatos. Eles podem ser concretos (gentes, fatos, problemas) ou abstratos (hipóteses, personas, planos).  É uma bela coincidência o encaixe sem gambiarras do ciclo OODA (Observe, Oriente, Decida, Aja) nesta matriz. Observação e Ação ocorrem aqui, no mundo real, concreto. Elas lidam com fatos e envolvem e afetam gente de carne e osso. Do outro lado, lá em cima, estão os trabalhos baseados em ideias e possibilidades. Na Orientação nós criamos opções para, logo depois, tomarmos Decisões. Os termos originais falavam com pilotos de combate. A partir deste ponto vamos chamar os trabalhos de Descoberta, Exploração, Desenvolvimento e Entrega. 

Aos Trabalhos

Os proponentes do modelo Dual Track falam em dois tipos de trabalho: descoberta (discovery) e desenvolvimento (development). Veja o desenho sugerido por Jeff Patton:Patton, no mesmo artigo, reconhece a existência de um terceiro tipo de trabalho, o design tático. Ele defende que os trabalhos são diferentes porque requerem um jeito de pensar diferente. Vamos retomar a matriz sugerida anteriormente? Não são dois ou três tipos de trabalho. São quatro! Em cada quadrante temos fontes e materiais distintos. Mais que isso, temos objetivos bastante diferentes:

• Descobrir: revelar, jogar luz, tomar conhecimento, fazer conhecer.
  É neste momento que delineamos o problema ou parte dele. É aqui que conhecemos as pessoas envolvidas (holders) e temos o primeiro contato com seus interesses (stakes) e dores. É aqui, no mundo real, que descobrimos o que precisa ser feito.
• Explorar: percorrer (região, território) para estudar, pesquisar, conhecer.
  O entendimento do problema continua e se enriquece quando começamos a cogitar alternativas de solução. Brincamos com hipóteses, rabiscamos arquiteturas e validamos protótipos. É no campo das ideias que exploramos o como fazer. 

Aquilo que Patton e Cagan apresentam como a trilha discovery é a combinação de dois trabalhos. Pense no OODA original. Observação e Orientação são trabalhos distintos. Complementares, com certeza, mas muito diferentes. Fechando a matriz:

• Desenvolver: elaborar, criar. No OODA original, é o momento das tomadas de decisão. Dentre as diversas opções sugeridas durante a Exploração, algumas começarão a ganhar vida neste quadrante. Para encontrar o mundo real logo depois. 
• Entregar: para muita gente seria apenas uma questão de “colocar em produção”, “subir pra nuvem”, “mudar de assunto”… É claro que a entrega é muito mais que isso. Pode envolver a preparação das pessoas que receberão aquela mudança. Deveria incluir o monitoramento de indicadores que vão comprovar ou não a solução do problema dado. Enfim, é botando para rodar e quebrar que nós aprendemos e justificamos nossos ganhos e choros. É aqui, no mundo concreto, que encerramos e começamos tudo de novo.

Patton e Cagan tratam os dois trabalhos acima na trilha de desenvolvimento. Nossa matriz, mais colorida abaixo, mostra como Desenvolvimento e Entrega são movimentos/momentos diferentes:

Quatro Trabalhos / Duas Trilhas

Durante muito tempo convivemos com o ciclo PDCA (Plan/Do/Check/Act) como se ele fosse o único ou o melhor molde para todos os nossos métodos. Apesar do berço esplêndido e de teimosos ilustres³, faz tempo que o PDCA deu o que tinha que dar. Os problemas que merecem a nossa atenção pedem por novos modelos mentais.

O ciclo OODA nasceu da necessidade de fazer com que pilotos de caça voltassem para casa sãos e salvos. O ciclo, naquele contexto, poderia girar dezenas de vezes em uma única missão. Tente calçar aqueles coturnos. Pense em como deve ser um combate nas alturas controlando uma máquina a, sei lá, 3.000 km/h?  Pois é, o OODA parece ser uma ideia – um jeito de pensar – bastante adequado para nossos tempos velozes e furiosos. Se você topa este entendimento, então aceita o fato de que temos quatro e não dois trabalhos. 

Quatro trabalhos em duas trilhas: Divergente e Convergente. Surrupio os termos sugeridos por Tim Brown em Design Thinking (Alta Books, 2017). Na primeira nós criamos opções. No outra, tomamos decisões. Você prefere usar Upstream e Downstream? Fique à vontade.

Como?

Reclamações acerca das dificuldades de trabalhar com “ágil” – feitas por designers, analistas de negócios e afins – foram sumariamente ignoradas por muito tempo. Foi necessária a intromissão de nomes mais conhecidos – Marty Cagan, James Coplien, Peter Morville e Jeff Patton, por exemplo – para que a sugestão do trabalho em duas trilhas fosse percebida. Aceita não, percebida. 

Confesso que ainda não vi o dual-track rodando em sua plenitude. Muitos times preferem apostar em coisas como o refinamento ou workshops de requisitos. Repare: esses eventos parecem ser espaços abertos na agenda do time – concessões? – para a realização dos trabalhos de descoberta e exploração. Como se a realização deles fosse possível em dois ou três encontros por sprint. Sei não, mas isso tem jeito e cheiro de cascata.

Descoberta e exploração deveriam acontecer todo santo dia. É por isso que a convivência diária do time com gente do negócio é um requisito para o bom uso do XisPê, Scrum etc. 

A gente tentou encaixotar o trabalho criativo em timeboxes que fazem muito sentido para desenvolvimento e entrega, mas nenhum sentido para descoberta e exploração. São ritmos diferentes, paradas e roteiros variados. 

“Em vez de considerar essa característica ad hoc como um dado de inferioridade do design, creio que isso atesta a independência epistemológica da área – o design não é necessariamente científico, mas pode estabelecer diálogos muito fecundos com a ciência”.
– Caio Adorno Vassão em Metadesign (Blucher, 2010)

Sigo confiando na proposta das duas trilhas. Aliás, dadas as críticas mais recentes?, estou disposto a dobrar a aposta. Porque elas partem de um engano: há dois times trabalhando, um em cada trilha, cada um com seu backlog!? Não foi isso que Cagan e Patton escreveram. Caramba, basta ler os artigos: há duas trilhas, não dois times. Tá todo mundo junto, o tempo todo! O tempo todo? Veja bem…

Notas

1. Marty Cagan escreveu Inspired: How to Create Tech Products Customers Love (Wiley, 2018) e Patton ficou famoso por causa de User Story Mapping (O’Reilly, 2014). Cagan escreveu o artigo Dual-Track Agile há oito anos. Patton voltou ao tema logo depois.
2. No artigo The New New Product Development Game, publicado na edição de jan-fev/1986 da Harvard Business Review.
3. O ciclo PDCA é cria de W. Edwards Deming e defendido, na comunidade Lean-Agile, por gente grande como Mary e Tom Poppendieck. Em Implementando o Desenvolvimento Lean de Software (Bookman, 2011), por exemplo. É risível a forçada de barra dada para justificar o P (plan).
4.  We Need One Complete Product Team, de Todd Lankford (27/ago/20).
     Time to Say Goodbye to Dual Track Agile?, de Alex Ballarin (12/set/20).
   
5. Foto de Henry & Co. surrupiado no Unsplash

Te quero para dar roupa e nomes novos para meus velhos hábitos e habitats. Quero tribos, guildas e esquadrões bem alinhados em minha mal disfarçada organização matricial. Assim mantenho o statu quo de um jeito SEGURo. Com certificados e atestados de maturidade. E daí se a ideia original era cancelar esse mindset de certificações e modelos de maturidade? Entenderam nada, inocentes!

Nosso rocambole é pós-moderno. Vou provar através de uma matriz 2×2 que não pode ser chamada de matriz 2×2 com um buraco no meio – saca Magritte? – que a nossa metodologia é o única que está pronta para lidar com essa tal complexidade. Prontinha: Out-of-the-box!

Ah, $cara agilidade, te quero como sombrinha e sombreiro. Faça chuva ou faça sol, seja qual for a pergunta, você será a resposta. Devidamente embrulhada num pacote de jargões, nomes esquisitos e anglicismos que vão separar nitidamente os fortes dos fracos, os verdadeiros agilistas dos céticos e patéticos cascateiros. Que venham os épicos!

Terra Arrasada

Não é por acaso que Kent Beck, um dos pais dessa ideia sem mãe, recentemente disse¹ que o Ágil “virou terra arrasada. A vida foi toda sugada para fora dele. Virou um conjunto de rituais religiosos realizado por gente que não entende o propósito original desses rituais”. 

Não é de hoje que os signatários do Manifesto Ágil lamentam o estado deplorável de sua cria. Assim como acontece com o rock’n’roll, pela enésima vez vão anunciar a morte do Agile². Só para confirmar, pela enésima vez, sua teimosia. Apesar de todos os sopapos e mal entendidos. Apesar do marketing desastrado/desastroso que o acompanha desde o berço.

Anarquistas, graças ao marketing

Dezessete caras pançudos de meia idade se reuniram em um resort para “esquiar, relaxar, colocar o papo em dia e encontrar pontos comuns em suas ideias sobre o desenvolvimento de software”. O processo durou três dias e gerou um documento de duas páginas. Em agosto de 2001 a Software Development anunciou a boa nova com a capa ao lado. O artigo, de onde surrupiei as aspas anteriores, foi escrito por Jim Highsmith e Martin Fowler, dois dos dezessete barrigudos. O que nos permite entender que eles não se incomodaram com a tag anarquistas nem com a mensagem da capa. 

Hoje, quase vinte anos depois, o manifesto segue sendo mal apresentado pra chuchu. Há poucos dias a revista EXAME colocou na conta da pandemia um crescente interesse por uma metodologia ágil. Dá a entender, por exemplo, que a adoção do modelo Spotify, algo que nem a empresa sueca faz, seria condição para a agilidade. A sucessão de mal entendidos não é exclusividade nossa. Saca só um recorte da Harvard Business Review:

Pois é, creditam Sutherland como grande liderança por trás da “invenção” da ideia ágil. Sutherland é o mesmo que promete na capa de um livro “a arte de fazer o dobro do trabalho na metade do tempo”. O faz porque parece estar apostando corrida contra o cara que pegou um time CMMI nível 5 na Índia e aumentou sua produtividade em 200%! 

Quem resiste a tanto apelo? Que pessoa de negócios em sã consciência pode se dar ao luxo de ignorar propostas tão ambiciosas? 

Só tem um probleminha: o Ágil nunca prometeu nada disso. 

Agilidade, para que serves?

Ao priorizar a gente e as nossas conversas, o resultado concreto de nosso trabalho e respostas rápidas – ciclos bem curtos de feedback, o Manifesto Ágil aponta para uma grande inimiga: a Complicação.

Nossos negócios ficaram 35 vezes mais complicados nos últimos cinquenta anos³. Esta foi a nossa resposta inconsequente à crescente complexidade: Inventamos departamentos, seções, funções, tribos, capítulos, guildas, escritórios disso e daquilo; Desenhamos processos cada vez mais prescritivos, minuciosos e paranóicos; Despejamos um sem número de políticas e regras que são cada vez mais efêmeras e frágeis; Impusemos uma enxurrada de indicadores que atestam um único fato: a nossa insegurança. Enfim, bagunçamos o coreto do negócio dificultando a convivência interna e comprometendo todas as relações que existem da porta para fora. 

A “ideia Ágil” não foi a primeira nem será nossa última invenção para combater as burocracias que emperram nossas organizações e nos dão tanta canseira. Cedo ou tarde ela merecerá uma lápide bonitinha no museu de grandes novidades onde descansam a Reengenharia, TQM, BPM, SOA, KM…

Até lá – até que se invente algo melhor – faz sentido que a gente tente tirar o melhor possível da ideia. As exigências são mínimas: 1) alinhamento: saber o que precisa ser feito e por que; e 2) autonomia: para definir a melhor maneira de realizar aquele objetivo. Repare, há apenas uma condição para a realização dos dois fatores: confiança. E como saber se podemos confiar nas pessoas? Oras, como ensinou o ágil Papa Hemingway, confiando nelas.

PS

Se a velha guarda pançuda estivesse mesmo abandonando sua cria, por que então se preocuparia em escrever e receber tão bem um trabalho como Clean Agile – Back to Basics (Robert Martin – Pearson, 2020)? É claro que a Ideia Ágil merece uma nova chance. Porque, quando bem entendida, ela é muito boa. 

Curioso é vê-la muito bem entendida e aplicada numa seara que não tem nada a ver com software nem com negócios. É o que documenta Zaid Hassan no livro The Social Labs Revolution (Berrett-Koehler, 2014) sem disfarçar seu entusiasmo: “o Ágil come cisnes negros no café da manhã”. 

Notas

1. Nesta entrevista publicada pela Built In no último dia 18/08/2020.
2. Há uma extensa coletânea de obituários neste artigo publicado no LinkedIn.
3. Segundo pesquisa do Boston Consulting Group apresentada em Six Simple Rules, de Yves Morieux e Peter Tollman (HBR Press, 2014 – p. 7).
4. Foto de Kelly Sikkema no Unsplash

“A correta definição do que precisa ser feito é a etapa mais difícil do desenvolvimento de sistemas. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.”

O que fizemos de lá para cá?

• Distorcemos todos os currículos relacionados com a formação de engenheiros e analistas de sistemas. Enfatizamos o domínio da solução – programação e mais programação – em detrimento do domínio do problema.
• Mas a Academia, apressada, estava apenas seguindo o mercado. Um mercado que inventou, em meados dos anos 1990, um tal de analista-programador. Isso tem reflexos negativos até hoje. Basta ver a reincidência de um álibi fajuto: “o cliente/usuário nunca sabe o que quer”. Quem aprendeu a perguntar? Quanta ajuda o cliente/usuário tem merecido?
• De repente, ganhamos Agilidade. Com muitas propostas que parecem ser “do desenvolvedor, pelo desenvolvedor, para o desenvolvedor”. A coisa só piorou.
• E tocou o fundo do poço quando alguém acreditou que um Business Model Canvas –  uma cortina feita de papel sulfite – seria capaz de esconder aquele imenso buraco.
• Oras, e se o buraco for apenas uma hipótese? Vamos todos fingir que o buraco não existe; Ou é parte da decoração; Ou é só a opinião de alguém.
• Por fim, se o tal Upstream Kanban pretende, ainda que parcialmente, tratar do domínio do problema, então ele não pode começar se apresentando como um “processo de triagem”. Que vai da síntese para a análise? Fixando CONWIPs?!?²

A Acusação Comum

Um efeito esquisito do movimento Ágil, que contradiz sua intenção de ser Sistêmico, é a percepção generalizada de que tudo o que não é construção é desperdício. James Coplien e Gertrud Bjørnvig reclamam disso em Lean Architecture (Wiley, 2010). Peter Morville, falando de Arquitetura de Informações, relata o mesmo problema (Intertwingled, 2014). E o que dizer da Análise de Negócios? Que ela deu um tiro no pé quando publicou uma Extensão Ágil. Confessou uma culpa que não deveria ter. Pau que nasce torto…

A acusação ficou chique e mereceu até sigla: BDUF (Big Design Up Front). É importante destacar que a acusação não é vazia. É preciso lembrar o contexto que motivou o Manifesto Ágil. Era comum, naquele tempo, um mal conhecido como Analysis Paralysis. A burocracia emperrava pacas. Projetos entregavam bulhufas.

A diferença entre o remédio e o veneno é o tamanho da dose. Erramos a mão e criamos outro mal, a Agile Death Spiral. Sprints sem fim ou fins. Pivots mil. Um desastrado foco na eficiência que ignora o primordial: ao fazer a coisa errada do jeito certo, só estamos acelerando rumo ao desastre.

Entre a cascata congelada no tempo e o pós-moderno ciclone da morte deve haver um caminho.

Equilíbrio

A sugestão do Yin-Yang é de Peter Morville, no livro já citado. A imagem combina bem com a matriz apresentada no artigo anterior. Que esteja subentendida a necessidade de iterações. O ícone também informa que há construção nos momentos iniciais. E que não é proibido rever o problema e repensar os planos nos momentos seguintes.Esse equilíbrio bem zen seria perfeito se o alerta do Brooks não continuasse verdadeiro: aquela primeira metade (escura) é a mais crítica para o sucesso de um projeto ou produto. Mas ela não existe no Scrum, por exemplo³. O que nos levou a entender que bastaria puxar para o domínio do problema o mesmo esquema utilizado no domínio da solução. Vêm daí os sprints 0, -1 etc. Essas iterações podem ser úteis para a realização de spikes (experimentos), configuração do ambiente e coisas do tipo. Mas não têm nada a ver com o domínio do problema. O que é conhecido como grooming também não.

Sprints com duração fixa de uma, duas ou quatro semanas fazem muito sentido nos trabalhos de DESENVOLVIMENTO e ENTREGA. Mas viram camisas de força nos trabalhos de DESCOBERTA e EXPLORAÇÃO. Nesses momentos, é comum a necessidade de cinco ou dez iterações em uma única semana. Marty Cagan, em Inspired (Wiley, 2017) fala em até vinte iterações. Jake Knapp, em Sprint (Intrínseca, 2016), nos mostra um ciclo completo acontecendo em uma semana. Enfim, a variedade aqui é grande. E necessária.

O Design Thinking nos oferece ampla variedade de métodos e ferramentas para o Domínio do Problema. Não foi por outro motivo que Jonny Schneider, da Thoughtworks, propôs a seguinte combinação:

• Design Thinking: para explorar o problema
• Lean: para construir a coisa certa
• Agile: para construir do jeito certo

Legal. Mas o Manifesto Ágil não fala em eficácia logo no seu primeiro princípio? As propostas Lean não parecem preocupadas com eficiência? O Design Thinking não tem o que contribuir para o domínio da solução? A ideia do Schneider é promissora. A mensagem “Lean E Agile” ao invés do OU é correta. Mas a divisão de responsabilidades proposta acima não faz o menor sentido. 

Acho que nós precisamos de outro enfoque, mais amplo e inclusivo. Precisamos de um modelo que incorpore, sem puxadinhos, uma legítima preocupação com o domínio do problema. Que faça a gente “se apaixonar pelo problema, não pela solução“.  Bom tema para o próximo artigo.

Notas

1. No artigo No Silver Bullet, transformado em capítulo da edição comemorativa de The Mythical Man-Month (Addison-Wesley, 1995). Este trabalho, lançado originalmente em 1975 (!), acaba de ganhar nova edição em pt-br: O Mítico Homem-Mês (Alta Books, 2018). Parafraseando Brooks: “a longevidade desse livro atesta que a gente continua caindo nos mesmos buracos…”
2. São algumas sugestões apresentadas por Patrick Steyart em Essential Upstream Kanban.
3. Que fique claro: não se trata de um bug do Scrum. A omissão é intencional. E só vira um problema se a gente a ignorar. Ou, pior ainda, se a gente esticar o Scrum para cobrir o buraco.
4. “Se apaixone pelo problema, não pela solução” é uma das dicas de Marty Cagan em Inspired (Wiley, 2017).
5. hole in the wall é o título da óbvia imagem de hoje.

Entre todos os grandes pensadores sistêmicos, Ackoff foi o mais incisivo¹: devemos dissolver problemas. Devemos redesenhar o sistema de forma a evitar reincidências e efeitos negativos. O Pensamento Sistêmico nos dá essa visão privilegiada: de longo alcance, inclusiva e obrigatoriamente atenta à dinâmica das relações entre todos e tudo o que está envolvido em dada situação.

O mundo Ágil, através de livros e propostas, gosta de apontar o Pensamento Sistêmico como uma de suas bases. É uma pena que, quase sempre, tal referência se limite a um capítulo ou nem isso². Pior ainda é quando o Pensamento Sistêmico é interpretado através de uma visão curta. Vira mera etiqueta que tenta dar ares de coesão e coerência para ideias frouxas. Nesses casos é sempre bom relembrar a Lei de Durden.

Retomando: como criamos e entregamos valor? Como trabalhamos? Estamos de fato dissolvendo problemas? Ou simplesmente criando outros?

Método

O Design Thinking, também derivado do Pensamento Sistêmico, foi feliz ao escolher um losango como representação de um jeito de pensar e eliminar problemas. E muito desastrado quando resolveu trocá-lo por um squiggle. Sigamos com o losango. Na primeira metade temos a compreensão. Na outra, criação. Na primeira metade criamos opções. Na outra, tomamos decisões. Convenhamos, isso é tão antigo quanto andar para a frente. O que o mundo do design nos deu foi uma imagem e termos sofisticados: movimento divergente, movimento convergente. No fundo isso é, sempre foi e sempre será uma sequência de ANÁLISE e SÍNTESE. Necessariamente nessa ordem³.O losango perde sua utilidade quando nos deparamos com dois problemas. Primeiro: esse pensamento é linear. Os problemas que justificam os nossos salários e lucros não são eliminados assim. Eles pedem por iterações porque, como humanos, a chance de acertarmos na primeira tentativa é quase nula. Uma imagem bem melhor é a do semi círculo ornamentado por uma seta que aponta para o início e diz: vamos experimentar, aprender e tentar de novo. E de novo…

O segundo problema é a necessidade de uma segunda dimensão. Um eixo que nos permita separar o que é CONCRETO do que é ABSTRATO. Dados, fatos, pessoas e soluções são coisas concretas. Ideias, hipóteses, opções, oportunidades e experimentos são abstrações. Acabamos de ganhar mais uma matriz 2×2.Quase todos os frameworks e métodos propostos nas últimas décadas apresentam, em seus próprios termos, a visão acima. O que não se encaixa ali é o jeitão antigo – linear, mecanicista e reducionista – de fazer as coisas. Até o ciclo PDCA (Plan-Do-Check-Act), por exemplo, não combina. Apesar de suas origens sistêmicas e, como tal, ser iterativo. OODA (Observe-Orient-Decide-Act), por sua vez, se encaixa perfeitamente. Se uso outros nomes é para aproximar o modelo de nosso contexto. OODA foi sugerido por um piloto de caças.

Talvez alguém queira apontar a coincidência dos quadrantes acima com aqueles do Cynefin: Descoberta é Caótica, Exploração é Complexa, Desenvolvimento é Complicado e a Entrega é Simples. A coincidência é feliz. Aliás, esse caminho seria feliz… se não fosse equivocado. Se o problema que pretendemos resolver é complexo, ele não deixa de sê-lo só porque se encontra em outro momento (quadrante) daquele ciclo.

No próximo artigo nós vamos esticar esse papo. E ver como Scrum, Kanban e derivados compartilham problemas semelhantes. Agora é hora de uma segunda rodada de nosso autoexame.

Autoexame

Como a sua organização CRIA e ENTREGA valor?

• O trabalho executado no lado esquerdo do diagrama acima obedece ao mesmo ritmo e às mesmas restrições daquele que é executado no lado direito? As Sprints têm a mesma duração nesses dois hemisférios?
  Obs.: aos adeptos do Kanban deixo minha desconfiança de que o que chamo de lados esquerdo e direito são, respectivamente, o que vocês tratam como upstream e downstream Kanban. Mas vem coisa nova por aí, um tal Discovery Kanban. O nome não é mera coincidência. A necessidade, tardia, parece óbvia.
• Você usa sprints 0, -1 e afins para tentar entender o problema?
• Como são iniciados os seus projetos? Com Histórias de Usuários? Com hipóteses? Com planos?
• Todas as hipóteses se tornam experimentos?

Qualquer SIM não é bom sinal.

Notas

1. Dois trabalhos sintetizam bem as propostas de Russell Ackoff: Ackoff’s Best (Wiley, 1999) e, para os apressados, Differences that Make a Difference (Triarchy Press, 2010).
2. Craig Larman e Bas Vodde vão um pouco além de um capítulo em Scaling Lean & Agile Development (Addison-Wesley, 2009) e Large-Scale Scrum – More with LeSS (Addison-Wesley, 2017). O mesmo pode ser dito sobre Managing the Design Factory (Free Press, 1997) e The Principles of Product Development Flow (Celeritas, 2009) ambos de Donald Reinertsen. No entanto, para perceber a aplicação do Pensamento Sistêmico como um todo e no todo (e como é estranho escrever isso) vale a pena ler The Journey to Enterprise Agility: Systems Thinking and Organizational Legacy (Springer, 2017) de Daryl Kulak e Hong Li.
3. Aquela frase não seria necessária caso eu não tivesse me deparado com Essential Upstream Kanban, de Patrick Steyart. O cara tá falando que a síntese antecede a análise?!?
4. 4 Windows, compartilhada por gmahender no flickr, ilustra este artigo.

Valor

O Manifesto Ágil diz que a “nossa principal prioridade é satisfazer o cliente através da entrega adiantada e contínua de software de valor”. Fica por nossa conta descobrir o que significa software de valor. E entender que existem mais valores em jogo: há o VALOR PARA O CLIENTE, claro, mas não podemos ignorar o VALOR PARA O NEGÓCIO e o possível VALOR PARA O TIME. Mais que isso, é crucial entender as relações entre esses valores.

Apesar das diversas e desastradas manifestações ao contrário¹, VALOR é o nosso mais importante sinal vital. Mas, como vimos, não há um valor único. Muito menos um entendimento compartilhado sobre o que ele significa. Vamos por partes.

Valor é a medida da importância de algo. Até que ponto aquilo que vale para o seu negócio (departamento ou time) é valorizado pelo seu cliente (ou usuário)? Convenhamos, há poucas chances de acordo ou coincidência. Por isso não devemos confundir VALOR PARA O NEGÓCIO com o VALOR PARA O CLIENTE e/ou USUÁRIO. Cada um puxará a sardinha para o seu lado. Todos repletos de razão.

O que significa VALOR PARA O NEGÓCIO? Mark Schwartz, em The Art of Business Value (IT Revolution Press, 2016), escreve que o valor para o negócio é “uma hipótese formulada pela liderança sobre a melhor maneira de realizar os grandes objetivos da organização”. Hipótese? Está aqui um terrível legado da moda Lean Startup: parece que tudo virou hipótese. O que tem valor para você é apenas uma hipótese? Duvido. Mas, como comprova o livro do Schwartz, quanto mais pessoas envolvemos, mais esse papo sobre valor fica variado, estranho e difícil.

Donald Reinertsen (em Managing the Design Factory – Free Press, 1997) tem uma navalha para cortar toda essa variedade: “somos apenas filósofos enquanto não começamos a usar números”. Então, vamos aos números!

Números

Como você mede e apresenta o VALOR PARA O NEGÓCIO? Quais números fazem mais sentido? ROI (Retorno sobre o Investimento) e NPV (Valor Presente Líquido), por exemplo, são proxies que se sustentam em previsões. Nós humanos não somos muito bons nisso, em fazer previsões. Segundo Schwartz, “ROI e NPV são o waterfall do mundo financeiro”. Ainda mais importante: o cálculo de ambos, ROI e NPV, exige um numerador que é a representação do valor. Oras, então por que não nos contentamos com ele?

O uso do Custo do Atraso (CoD – Cost of Delay) é defendido por Reinertsen e Schwartz. Mas ele também depende de uma definição prévia do Valor. Se não sabemos quanto vale, como podemos afirmar ou ao menos prever o custo de seu atraso? Estamos andando em círculos?

ROI, NPV, CoD e afins representam hipóteses. Carregam incertezas e podem, dependendo do nível de sofisticação, dificultar a comunicação entre os envolvidos em determinada iniciativa. Não pretendemos filosofar. Mas que valor tem uma sequência de cálculos que poucos entendem? É sempre bom relembrar o décimo princípio do Manifesto Ágil: “Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” Conseguimos exprimir o VALOR PARA O NEGÓCIO de forma simples e direta?

Histórias de Valor

Como a Natureba S/A
nós precisamos de um app que permita que as nossas consultoras registrem e transmitam pedidos em tempo real
para encurtar o ciclo de vendas em 50% e cortar algo entre R$15M e R$25M dos custos anuais de processamento de pedidos.Como a Webchuteira LTDA
nós precisamos de um programa de fidelidade vinculado aos sistemas sócio-torcedor dos grandes clubes nacionais
para aumentar o nosso market share em 40% e o faturamento em, pelo menos, R$100M no próximo ano.Não é curioso que essa proposta simples, derivada do formato clássico das User Stories, seja tão pouco conhecida? Aliás, por favor, não se apegue ao formato. O importante aqui é o que essas histórias nos contam. Conversaremos mais sobre isso no próximo artigo. Porque agora é um bom momento para um autoexame.

Autoexame

Você e seu time sabem quanto VALOR estão criando e entregando?

Se sim:

• Esse entendimento é compartilhado por todas as pessoas envolvidas?
• A sequência do roteiro (roadmap e backlogs) reflete nitidamente essa preocupação com a entrega antecipada e contínua de valor?

Se não:

• O que diabos está orientando as milhares de decisões que vocês tomam todo santo dia?

Notas & Esculachos

1. D’ A Startup Enxuta, de Eric Ries (Leya, 2012), ganhamos essa perigosa e triste mania de achar que tudo é hipótese.
2. De Jeff Sutherland, cocriador do Scrum, herdamos o peso da promessa do título de seu último livro: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. O sonho dos tayloristas deveria ser o pesadelo dos agilistas. Afinal, estes se comprometeram com outra arte, a de “maximizar a quantidade de trabalho que não precisou ser feito”.
3. No Kanban, de David Anderson (Blue Hole, 2010), aprendemos uma “Receita de Sucesso” que só permite conversar sobre VALOR no penúltimo passo de um total de seis. Orientado por uma mentalidade que não tem muito a ver com o trabalho criativo, o último passo da tal receita ainda pede que “ataquemos as fontes de variabilidade”. Não surpreende que o mesmo autor ressuscite agora uma conversa sobre Modelos de Maturidade. O Kurt Cobain vem junto? No carro preto do Ford? Nevermind…
4. Stickynotes, de Martijn Veening, ilustra este artigo.