Robert ‘Uncle Bob’ Martin gasta um tempinho em seu Clean Agile (Pearson, 2020) para nos lembrar:

“Algumas pessoas acham que Agile é sobre ir mais rápido. Não é. Nunca foi. Agile é sobre saber, o quanto antes, o quão ferrados estamos.” 

Saber, o quanto antes, o quão ferrados estamos. Esse é o espírito da coisa Ágil. Pragmático e poético como ele só. Na Toyota há um mecanismo que ilustra bem essa atenção com as más notícias. É a Corda Andon, que pode – deve! – ser puxada por qualquer pessoa que veja qualquer problema na linha de produção. O acionamento da corda simplesmente para tudo. Ela funciona bem em um fluxo linear, previsível pra chuchu e de baixa variabilidade. Ou seja, funciona em fábricas. Uma versão adaptada da corda funcionaria em um contexto não linear, cheio de incertezas e dependente de variedade? É pouco provável.

Ainda que a gente faça de conta que as nossas burocracias não detestam más notícias. Ainda que todos trabalhemos em ambientes psicologicamente seguros onde as cagadas são recebidas sem choro nem vela, sem chiliques nem berros. Ainda assim, qual é a chance de nossas organizações ou times desenvolverem um reflexo que simplesmente pare tudo quando se deparar com um problema? 

Um reflexo é automático, inconsciente e inconsequente. Apesar de mirar isto, funcionar como se fosse um reflexo, o acionamento da corda Andon é uma reação. É um hábito que precisou ser treinado. Ainda mais lentas que as reações são as respostas. Porque elas sempre significam um esforço consciente, uma tomada de decisão. Respostas requerem o uso do nosso lento e preguiçoso Sistema 2².

Uma típica instância Ágil dedica pelo menos três cerimônias para a celebração das más notícias: a Diária, a Revisão e a Retrospectiva. Nenhuma delas aparenta a ambição de ser um reflexo ou pelo menos um reação. São respostas e isso não é necessariamente ruim. Desde que a gente saiba que:

• Diária: é totalmente desnecessária quando o time coopera de verdade. Por favor entenda que POs, ANs e/ou outros representantes do negócio são parte indissociável de um time. De uma maneira ou de outra, tratar as Dailys como se fossem um tipo de prestação de contas para um cliente ou gerente é desvirtuar sua intenção original: saber o quão ferrados estamos ou podemos ficar. Quando um time de fato co-opera, os problemas e riscos pipocam na cara de todos, dispensando um evento ou comunicação formal. O distanciamento de membros ou pares pode justificar a realização das Diárias. Ainda assim, é bom entender que má notícia que se preze não pode e não vai esperar pela manhã seguinte.
• Revisão: Encontro periódico que deveria envolver o maior número possível de interesses. Na Revisão nós validamos a eficácia do time, ou seja, se ele está fazendo a coisa certa. Tem potencial para se transformar em um festival de saias justas se este for o único momento da iteração ou sprint em que a turma do negócio vê a evolução de sua cria. Tanto pior se a experiência se resume à uma demo pilotada por devs. O time, neste encontro, deveria ser a parte passiva. O comando da festa deve ficar com quem está pagando. Enfim, a Review deveria ser uma celebração totalmente livre de surpresas. Isso só vai acontecer se a patota de negócios interagir diariamente com o time e o produto. Testando – ou seja, gerando más notícias. Todo santo dia.
• Retrospectiva: Tem má notícia que a gente só entende plenamente em retrospecto, depois de um certo tempo. Com calma é possível avaliar causas e efeitos. É por isso que todos os times, particularmente os piores, merecem um refresco recorrente chamado Retro. É um momento de reflexão, quando o time avalia a sua eficiência, ou seja, se ele está trabalhando do jeito certo. A gente sabe, ele nunca está! Sempre, sempre haverá algo para melhorar. Uma boa retrospectiva não fica ensanduichada entre uma review e uma planning. Refresco, gente. Entre sprints, todo time merece um refresco. Senão não aprende, não melhora, e as más notícias seguirão evoluindo como bolas de neve.

PS, post-mortem

Alguém pode concluir que a reincidência desse assunto, nesta altura do campeonato, é uma prova de que estamos bem ferrados em relação ao entendimento da Ideia Ágil. Pode até ser. Mas a teimosia também pode confirmar que o assunto vale a pena, a atenção e o nosso tempo. Afinal, acho que ninguém em sã consciência quer voltar para a época em que as más notícias só circulavam formalmente, com muitos choros e velas, numa reunião chamada post-mortem. 

Notas

1. Anedota contada por John Seddon no ótimo Freedom from Command and Control: Rethinking Management for Lean Service (Productivity Press, 2005). Ótimo ao ilustrar o Lean funcionando bem longe do chão de fábrica.
2. O papo sobre reflexos, reações e respostas eu aprendi com Russell Ackoff em Differences that make a Difference (Triarchy, 2010). O preguiçoso Sistema 2 é apresentado por Daniel Kahneman em Rápido e Devagar (Objetiva, 2012).
3. Foto de Jan Kop?iva no Unsplash.

Do Sistema Toyota derivamos o Lean e muito do que vemos no mundo Agile. A grande constante — obsessão? — é o tempo. Por isso falamos tanto sobre fazer o dobro do trabalho na metade do tempo, otimizar fluxos, entregar continuamente etc. Talvez tenha chegado a hora da China nos sugerir um modelo — um sistema. A obsessão é outra: espaço. E isso pode mudar bastante as nossas conversas.

Rén d?n hé y? (????), segundo o Google Translate, significa um único. Se Ohno brigava para reduzir o tempo entre o pedido e a grana embolsada, a proposta chinesa visa eliminar a distância entre o cliente e o negócio. Gary Hamel e Michele Zanini explicam assim²: “transmite a ideia de uma relação estreita entre o valor criado para o cliente e o valor recebido pelos funcionários.” É provável que aqui no ocidente a gente comece a falar em Distância Zero. A conversa já começou³.

E vem de uma maneira muito diferente da forma como iniciamos o movimento Ágil. Porque tudo na China parece superdimensionado. O RenDanHeYi nasceu grande. Hamel e Zanini estudaram a Haier, a maior fabricante mundial de eletrodomésticos. Ela tem 75 mil funcionários. Todos organizados em microempresas que têm entre 10 e 15 pessoas. Ou seja, aquele imenso dragão é um emaranhado com mais de 4 mil microempresas (MEs).

Existem apenas três tipos de MEs: usuária (200), incubação (50) e junção (3800). As primeiras estão na linha de frente, voltadas para o mercado. Em incubação ficam as novas ideias e apostas (startups, como queira). As junções (nodes) são contratadas — e demitidas — pelas outras duas. Elas representam todo o resto da organização: vendas, design, manufatura, apoio (RH, contabilidade, TI etc). O artigo de Hamel e Zanini detalha os sete fatores que fazem o modelo funcionar. Não vou chover no molhado².

Coincidências Felizes

O modelo, por querer, lembra a Web. São diversas partes pequenas fracamente acopladas e organizadas em plataformas. Existem apenas dois níveis hierárquicos entre as MEs e o CEO. O que sugere bastante autonomia e alinhamento. A organização é fractal e a existência de um sistema 4 de verdade — as MEs de incubação — deixaria Stafford Beer feliz da vida. Não apenas por isso, mas principalmente porque parece que a Haier entende e aplica a Lei de Ashby: “Só a Variedade absorve Variedade”.

Preciso repetir a primeira frase acima: o modelo da Haier copia a Web. É uma grande fábrica que não se vê em uma cadeia de valor e sim numa Rede de Valor. Tom Stewart, que inspirou este velho post, deve ter dado um sorriso sarcástico: uma fábrica funcionando como rede de valor! Dave Gray, de A Empresa Conectada (Novatec, 2013), rabiscou a diferença e riu junto.

Não há monopólios internos. As MEs usuárias nunca se tornam reféns de junções que não entregam. Elas têm total autonomia para contratar alternativas, estejam elas dentro ou fora da Haier, num desenho que deixaria Russell Ackoff muito satisfeito. Porque ele escreveu, há muito tempo, que essa seria uma característica fundamental de uma organização do século 21. Oras, se realmente acreditamos na economia de mercado, o que justifica a existência de monopólios dentro das nossas empresas?

Talvez os links dos três parágrafos anteriores apenas dedurem um viés de confirmação. Eu desconfio que eles apontam padrões que a Haier, em uma década, descobriu ou desenhou de forma empírica.

Seja como for, o fato é que a Haier não é apenas uma colcha de ideias e padrões relativamente raros. O que dá cola e sentido para todo o modelo é a sua diretriz principal, a Distância Zero. E isso é novo.

Ainda é muito cedo para dizer se este modelo será tão influente quanto o Sistema Toyota. Mas vale a pena prestar atenção³.

Notas

1. Citação encontrada em Freedom from Command and Control, de John Seddon (Productivity Press, 2005). Se você quer ter uma visão mais prática do que significa Lean na área de serviços, este é o livro. Que apresenta outra possível coincidência: Seddon insiste bastante na proximidade com os clientes. Sua leitura do que é ser Lean, se devidamente espalhada no mundo ágil, nos teria poupado de alguns mal entendidos. Como algumas brigas contra a variedade, por exemplo.
2. Em artigo de capa da edição de nov/18 da Harvard Business Review. A versão em inglês está disponível para leitura. Hamel e Zanini vão detalhar a proposta em Humanocracy: creating organizations as amazing as the people inside them(programado para jan/2020).
3. Em 9/mar uma busca no Google por rendanheyi retornou 7.410 resultados. Hoje (23/mar) já são 43.300.
4. O Six Sigma abre espaço para o Rendanheyi na GE. Artigo da Bloomberg, de 8/2/19. (Obrigado Cattai!)
5. Ilustrei aqueles artigos de cinco anos atrás com imagens do QThomas Bower. Faz sentido manter o padrão com a bela Lemon Lime — Fractal Mosaic.

É certo que o jeito Ágil de pensar – com iterações curtas e feedback rápido – nos ajuda a compreender e delimitar melhor o problema enquanto desenvolvemos e entregamos a solução. Mas qual é o marco zero? Qual deve ser o nosso ponto de partida? Se a gente soubesse o quanto esse primeiro passo influencia o desenho da solução seríamos um tanto mais cuidadosos.

Qual é o problema? Por que é um problema? Quem é afetado por ele? O que está envolvido? O que pode acontecer se a gente não resolver o problema?

Desenvolver o sistema X ou o app Y; Aumentar o market share; Reduzir os custos do processo Z; Melhorar a nossa imagem; Aumentar o faturamento em tantos milhões. Nada disso é problema.

Todas as frases acima sinalizam possíveis soluções. Mas dizem muito pouco ou nada sobre o problema. Foi por isso que o pessoal da Toyota inventou o 5 Porquês. Porque geralmente precisamos de cinco enxadadas para alcançar a raiz do problema.

Tratar a ferramenta 5 Porquês como guia para uma entrevista 1:1 é um desperdício e tanto. Porque ela só prova todo o seu potencial quando é combinada com outras ferramentas em uma Investigação Sistêmica². Este processo de descoberta deve envolver o maior número possível de interessados, interesseiros e encrenqueiros. Todos juntos no mesmo lugar. As respostas para cada porquê se desdobram em potenciais componentes do verdadeiro problema.

É um engano relativamente comum entender o Pensamento Sistêmico como uma forma de “ver o todo”. Ver o todo é só uma PARTE desse jeito de pensar. Se vemos só essa parte, perdemos o TODO do Pensamento Sistêmico.
(A recursividade é intencional. Na dúvida, releia o parágrafo).

Uma Rica Fotografia

Orientados pela ferramenta 5 Porquês podemos desenvolver uma Rica Fotografia (Rich Picture, no original em inglês). Esse modelo vem de uma das diversas propostas do Pensamento Sistêmico, a Soft Systems Methodology (SSM), de Peter Checkland. A fotografia é rica porque apresenta o contexto em toda a sua riqueza de diversidade, estrutura, relacionamentos e pontos de vista. DSRP: Distinções | Sistemas | Relacionamentos | Perspectivas. São as quatro regras que, em conjunto, nos ajudam a enxergar e compreender o mundo como ele realmente funciona. Ou seja, nos ajudam a pensar sistemicamente.

Devemos evitar a definição prévia do tipo de fotografia que queremos. Processos ou cadeias de valor não são indicados porque restringem, logo de partida, a forma como vemos o problema. Além disso, passa da hora da gente entender que esse jeito linear de criação de valor não é onipresente, muito pelo contrário. Enfim, a Fotografia Rica deve nascer sem moldura, grades ou guias. As fronteiras e a lógica do modelo devem emergir. Partimos do problema como apresentado na primeira vez – mesmo que seja um simples “precisamos de um app” – e perguntamos: Por que precisamos de um app?

As discussões em torno das respostas nos permitem identificar as partes envolvidas e as relações entre elas. A classificação dos relacionamentos – forte, fraco, direto, indireto, entrada, saída, colaborativo, conflituoso, rápido, devagar etc – enriquece a fotografia. Parte da fotografia pode ser capturada na forma de um Mapa Causal (CLD – Causal Loop Diagram). Assim o modelo fica com um jeito de filme – ganha dinâmica.

Como essa fotografia é produto de um processo colaborativo, é de se esperar que ela capture diversos pontos de vista. Condenamos o processo e o ambiente se alguma perspectiva for favorecida ou ignorada. Se uma pessoa chave não puder participar, adie o encontro. Aliás, a falta de agenda pode ser um sinal de que o problema não é assim tão relevante. Pelo menos, não para aquela pessoa.

Um subproduto desejável da elaboração da Rica Fotografia é uma igualmente rica análise dos stakeholders (ou partes interessadas). Em uma única reunião somos apresentados não apenas às pessoas envolvidas (holders) mas também ao seu grau de envolvimento, aos seus pontos de vista e interesses (stakes). Isso é de suma importância em qualquer iniciativa porque, como ensinou Gerald Weinberg em The Secrets of Consulting (McGraw-Hill, 1985), “a despeito do que o cliente possa lhe dizer, sempre existe um problema. Não importa o que pareça a princípio, o problema é sempre com as pessoas”.

A bola chega redonda para DeMarco e Lister, que em Peopleware (Makron Books, 1990) emendam: “os principais problemas de nosso trabalho não são de natureza tecnológica mas sim sociológica”.

Conclusão

Vale a pena repetir sempre: não é o modelo; não se trata do entregável (sic). É o processo de elaboração que nos interessa. São as conversas que importam. É a criação de uma visão compartilhada do problema o que buscamos. Isso, por si só, fará você se apaixonar pelo problema? Talvez não. A sugestão aqui apresentada deve te deixar mais íntimo do problema. E problemas, assim como as pessoas, podem nos decepcionar quando desnudados. O que fazer com essa desilusão é outra conversa.

Que não será a próxima. Se hoje apresentei uma sugestão para tratar de um problema interno e específico, no próximo artigo eu pretendo falar sobre problemas externos e gerais – problemas que nos motivam a criar produtos ou serviços. Desconfio que eles sejam um tanto mais atraentes. Veremos.

Notas

1. Gerald Weinberg? Russell Ackoff? Tantos já falaram sobre isso que fica difícil decidir a quem creditar aquela frase.
2. Como eu queria que a gente tivesse adotado em português um termo bastante comum entre os pensadores sistêmicos: Inquiry – investigação, pesquisa. É bem melhor que análise, descoberta e exploração. Porque explica melhor o trabalho que realizamos.
3. Heart-it foi compartilhada por The ReflexMan no flickr.

“Para o observador casual, definições do problema podem parecer desperdício. É tempo gasto longe do teclado e a educação ocidental nos ensina que estamos enrolando ou sendo improdutivos quando estamos ‘só conversando’. Mas o Lean é cheio de paradoxos como esse.”

“Muito do Lean é baseado no Pensamento Sistêmico e uma definição de problema bem colocada pode levar o time para além de suas preocupações com a solução – para uma compreensão mais ampla do contexto.”

“O Lean nos pede para reduzir tensões e inconsistências no sistema. A definição do problema articula um objetivo consistente. São comuns os projetos que sofrem porque seus participantes não estão resolvendo o mesmo problema. Uma definição de problema bem escrita oferece uma visão consistente de direção. Como tal, ela pode ser uma poderosa ferramenta para o time e para a gestão.”

“Uma boa definição do problema pode funcionar como um catalisador para a auto-organização.”

“Em uma verdadeira organização Ágil aqueles que são responsáveis pela solução do problema participam da definição do problema. Essa definição deve ajudar a canalizar a energia da organização na direção correta.”

Lean Architecture | James Coplien e Gertrud Bjørnvig
Wiley, 2010 – Págs. 68~74

Eu sabia que não estava sendo original quando escrevi que Histórias – de Valor ou de Usuários – são catalisadoras. Só não lembrava a origem.“Antes de iniciar um sprint de criação-de-valor-para-o-cliente precisamos de um backlog inicial do produto. E para gerar esse backlog nós precisamos da visão do produto. Muitas organizações também acham útil a criação de um roadmap preliminar, definindo uma série de releases incrementais. Chamo as atividades que criam esses artefatos de envisioning ou product-level planning.”

“O envisioning não deve ser confundido com um pesado e cerimonioso processo de planejamento. No Scrum, nós não acreditamos que podemos (ou devemos) conhecer todos os detalhes de um produto antes de começarmos. Entretanto, nós entendemos que o financiamento de um produto não pode começar sem uma visão; sem um entendimento adequado acerca dos clientes, das features e da solução em alto nível; nem sem uma ideia de quanto o produto vai custar.”

“Não gastamos muito tempo ou esforço no envisioning porque queremos rapidamente passar do estágio do achismo – quando a gente pensa que conhece as necessidades dos clientes – para as etapas de feedback rápido – para os sprints de criação de valor.”

Essential Scrum | Kenneth Rubin
Addison-Wesley, 2013 – Pág. 287

“O primeiro passo no Scrum é a elaboração da Visão do Produto pelo Product Owner.”

Scaling Lean & Agile Development | Craig Larman e Bas Vodde
Cap. 12 – Scrum Primer, por Pete Deemer & Gabrielle Benefield
Addison-Wesley, 2009 – Pág. 311

1. Uma VISÃO projeta um futuro onde determinado problema deixa de existir. Uma VISÃO assume o entendimento prévio desse problema.
2. Ignorar a definição do problema e tratar o envisioning como o “estágio do achismo” (guessing, no original) é frágil e perigoso.
3. Entender que a elaboração da VISÃO é responsabilidade exclusiva de um PO é detonar, logo de cara, uma boa oportunidade de formar um time de verdade.

“A diretriz fundamental de qualquer sistema verdadeiramente enxuto consiste em estabelecer e entregar valor definido pelo cliente”.

“ não devemos gastar esforços ou recursos antes de termos um profundo entendimento do valor definido pelo cliente.”

Sistema Toyota de Desenvolvimento de Produto | James Morgan e Jeffrey Liker
Bookman, 2008 – Págs. 45~46

“A característica organizacional definidora do modelo do Spotify é o conceito de squads com ‘baixo acoplamento e alto alinhamento’. A tese central aqui é que ‘alinhamento permite autonomia – e quanto maior o alinhamento, mais autonomia é possível dar’. É por isso que a empresa passa tanto tempo alinhando todos com objetivos e metas antes de iniciar um trabalho.”

Tempo Talento Energia | Michael Mankins e Eric Garton
figurati, 2017 – Pág. 163

1. A distância que separa a Toyota do Spotify é a mesma que separa o Japão da Suécia. Mas uma coisa elas parecem ter em comum: tempo pra pensar.
2. Não é curioso que esse tempo para pensar não seja considerado trabalho? Repare na frase destacada no último parágrafo acima. Coplien e Bjørnvig, citados lá no início, já haviam alertado para essa característica bem ocidental de não relacionar esse tipo de conversa com trabalho.

“Quando você dispara qualquer coisa nova, há forças te puxando para todas as direções. Há coisas que você pode fazer, coisas que você gostaria de fazer e coisas que você precisa fazer. Comece pelo que precisa ser feito. Comece pelo epicentro.”

Rework | Jason Fried & David Hansson
Crown Business, 2010 – Pág. 72

“Tome uma grande decisão sobre sua Visão de forma antecipada e todas as futuras pequenas decisões se tornarão bem mais fáceis.”

Getting Real | 37signals
37signals, 2006 – Pág. 43

“Todo o trabalho com requisitos é precedido por algum tipo de processo de iniciação: alguém tem uma ideia de que algo deve ser desenhado e construído.”

“Se não formos cuidadosos, a ideia inicial vai colocar todo o processo em um caminho improdutivo do qual nunca vamos nos recuperar. Se os participantes não começarem pensando em conjunto, vamos perdê-los antes de ganhá-los.”

“Como podemos sintetizar a grande variedade de pontos de partida potenciais em uma plataforma única e sólida para a exploração de requisitos? Uma solução possível é entender cada projeto como uma tentativa de resolver algum problema e então reduzir cada ponto inicial a uma forma comum de descrição do problema.

“Um problema pode ser definido como: A diferença entre as coisas conforme são percebidas e as coisas conforme são desejadas.”

Exploring Requirements: Quality Before Design | Donald Gause e Gerald Weinberg
Dorset House, 1989 – Pág. 49

“A palavra problema sempre significa algo ruim, como em ‘Houston, temos um problema’ Mas as inovações bem sucedidas sempre envolvem mais atenção ao problema do que às soluções. Einstein um dia disse, “Se eu tiver 20 dias para resolver um problema, gastarei 19 para defini-lo”.

The Myths of Innovation | Scott Berkun
O’Reilly, 2007 – Pág. 127

“O problema não é o problema. O problema é a sua atitude em relação ao problema.”

– Capitão Jack Sparrow

1. Pois é, terceirizei a argumentação. Parti dos originais e a tradução é livre, provavelmente enviesada e eventualmente desastrada. Por  favor, não morda o meu dedo.
2. Se você não entendeu minha motivação, por favor, veja o artigo anterior.
3. Se tem o que acrescentar, por favor, comente!
4. Aquela foto bem sacada de dentro do buraco é da Alexandra Brovco.