O sobrenome Poppendieck ganhou notoriedade em 2003 com o lançamento do premiado livro "Lean Software Development: An Agile Toolkit”, no qual Mary e Tom discutiram como os princípios Lean aplicáveis na manufatura, poderiam ser úteis no ambiente de desenvolvimento de software. O implacável sucesso deste livro lançou luz sobre muitas questões que atormentaram gerentes e equipes de desenvolvimento na última década: requisitos ultrapassados, sistemas inconsistentes, clientes insatisfeitos, negócios perdidos e dinheiro desperdiçado são apenas alguns exemplos desta "era desperdiçada".
Após o primeiro best-seller, a trajetória de sucesso do casal Mary e Tom Poppendieck foi consolidada com a publicação de mais três obras impressionantes: Implementing Lean Software Development: From Concept to Cash, 2006; Leading Lean Software Development: Results are Not the Point, 2009; e Ask the Right Questions, 2013. Entretanto, ao longo deste período, o termo Lean tem sido usado indiscriminadamente. Enquanto alguns veem em seus princípios uma condição (não exclusiva) para as organizações prosperarem na dinâmica empresarial, baseada em um avanço tecnológico sem precedentes, que se estabeleceu no novo século, tantos outros distorcem seus preceitos e utilizam a filosofia Lean como uma cortina de fumaça para práticas antigas sobre uma nova terminologia.
Em uma entrevista concebida para Rodrigo Aquino, diretor da Lean IT e uma das mais maiores referências brasileiras em Lean IT, Mary e Tom Poppendieck exalam simpatia e vasto conhecimento ao abordar temas sensíveis para desenvolvedores, gerentes, inovadores, amantes do Lean, mas especialmente para os agilistas de plantão. O esforço para fazer as perguntas certas (mesmo sem ter certeza disso) foi recompensado com as melhores respostas desses dois gigantes de renome mundial na indústria de software e negócios.
Aproveitem! Márcio Gandara.
Rodrigo Aquino: No livro “The Lean Mindset: Ask The Right Questions”, você e Tom discutem a importância do Mindset Lean para que as organizações possam ser eficientes, mas ao mesmo tempo sustentáveis, o que não tem nada a ver com corte de custos, redução de salários, ou terceirização de serviços. Você pode nos dizer o que significa ter um Mindset Lean?
Mary Poppendieck: Preciso ser cautelosa ao falar sobre o Lean porque ele veio da manufatura, e então, no início dos anos 2000, foi adaptado ao mundo do software, quando o Agile também foi adotado e usado para resolver os problemas dos anos 90.
Por isso, às vezes significa alta eficiência, dispensando as pessoas de práticas que são especificamente destinadas a vários processos, como, digamos, cartões Kanban ou coisas do gênero. Às vezes, Lean não é pensado como uma forma de ver o mundo, como um conjunto de princípios.
Eu acho importante pensar em Lean como um conjunto de princípios para pensar como você ataca as questões de seus produtos no trabalho que você está tentando fazer, ao invés de um conjunto de coisas que você faz.
Mesmo na manufatura, o Lean foi mal interpretado como "Vamos fazer o que vemos essas outras pessoas fazerem”, ao invés de ser interpretado como "Eu me pergunto como essas pessoas resolvem seus problemas, talvez pudéssemos resolver os nossos da mesma forma".
Se você pensa em Lean como uma maneira de pensar sobre a solução de seus problemas, então você não vai copiar como outras pessoas resolvem seus problemas; você vai ver como elas pensam sobre melhorias. Parte disso é o foco em ensinar as pessoas a resolver os problemas que elas têm em mãos.
E a segunda parte sobre o Mindset Lean é ter respeito pelas pessoas. Uma das coisas interessantes é que na Toyota, quando desenvolveram muitos dos processos de manufatura Lean, eles estavam dizendo às pessoas que estavam trabalhando no chão de fábrica para descobrir como fazer as coisas melhor. Não vamos lhe dar uma maneira de fazer isso. Não vamos lhe contar o processo. Vamos ensiná-lo a resolver problemas, ensiná-lo a fazer experiências.
E o que precisamos assegurar no Lean é que não desperdicemos o tempo das pessoas, mas pensamos nelas como adultos competentes, adultos que não dizemos o que fazer. Em vez disso, ensinamos a eles como fazer a resolução de problemas para resolverem seus próprios problemas.
A última parte sobre Lean é como você olha para as métricas. Então, o que você mede? O Lean sempre se concentra na métrica orientada ao cliente. Nós nos preocupamos quando falamos de eficiência? Preocupamo-nos com quantos de nossos recursos utilizamos? Os clientes não se preocupam com isso. Os clientes se preocupam com a rapidez com que resolvemos seus problemas. Podemos fazer isso a um preço que eles acham adequado?
Nossas métricas não são eficiência de recursos, mas quão rápido respondemos aos problemas dos clientes; o quão bem respondemos às suas expectativas de preço. Você tem que pensar em Lean em termos de métricas orientadas ao cliente, e então você recebe ideias como fluxo, porque os clientes não se importam em esperar e esse tipo de coisa.
Portanto, o conceito de Lean não é um conjunto de coisas que você faz. É um conjunto de maneiras de focar nos clientes. Você torna (através do Lean) um lugar atraente para as pessoas trabalharem, desafiando e engajando, e basicamente adota e melhora constantemente a atitude de resolução de problemas.
E você pode conseguir muitas coisas diferentes com isso. Muitas práticas diferentes saem disso. Mas, no que diz respeito ao Lean, isso acaba sendo praticamente a maneira essencial de fazer as coisas e resolver os problemas. Isto é, permitir que as pessoas que fazem o trabalho resolvam seus próprios problemas.
Tom Poppendieck: Uma das finalidades da métrica é identificar problemas, identificar oportunidades, ao invés de criá-las. Em muitos casos, as métricas, se forem baseadas principalmente em retornos financeiros, causam problemas. Impulsionam más decisões que prejudicam e desencorajam as pessoas, e não acabam ajudando ninguém além dos proprietários e acionistas a curto prazo.
Rodrigo Aquino: Quando vocês falam de respeito, Mary e Tom, me vem à mente os cinco porquês. Quando perguntamos os cinco porquês, por exemplo: por quê? por quê? por quê?.... Às vezes, podemos não demonstrar respeito. Precisamos imaginar outra forma de perguntar os cinco porquês, mas não exatamente como prescrito.
Mary Poppendieck: Por que cinco? De onde veio isso? Talvez esse seja o número correto para o mundo em que eu vivo! Talvez eu possa descobrir isso só de olhar a situação.
Tom Poppendieck: As crianças são muito boas em perguntar por quê? por quê? por quê? Elas não são muito boas em tentar responder ao primeiro porquê para moldar o segundo porquê. Elas não são muito boas em ouvir e tentar explicar. E conforme as pessoas crescem, conforme se tornam mais maduras, elas ficam melhores em se adaptar ou em obedecer (cegamente). E obedecer (cegamente) não é o caminho para melhorar.
Mary Poppendieck: A ideia é entender o que realmente está causando algo para se ter uma visão sistêmica. E essa é uma ferramenta ou técnica que tem ajudado algumas equipes. Na verdade, em nossas oficinas, descobrimos que quando tentamos fazer os exercícios dos "cinco porquês", eles não funcionaram muitas vezes. Eles não foram úteis. Encontraríamos um problema: as pessoas não querem fazer testes de software, e então diríamos, bem, vamos à causa raiz. Eles tentariam marchar através de cinco porquês e não chegariam perto da causa raiz.
Mas se você dissesse, por que você realmente acha que as pessoas não querem "testar"? O que está realmente causando isso? Elas saberiam. Mas o exercício (5 porquês) os manteve longe de chegar a essa resolução.
Técnicas como essa podem ajudar, ou não. Mas o que você está tentando fazer é dizer, olhe para todo o sistema, não olhe apenas para a peça minúscula. Não se limite a pegar a primeira coisa que você vê e pensa. A perspectiva sistêmica pode ou não usar uma ferramenta como cinco porquês, mas não evitará que precisemos entender a causa se quisermos fazer algo a respeito.
Se olharmos apenas para os sintomas, isso não ajuda. Todos sabem disso, mas é mais fácil olhar para os sintomas do que tentar encontrar o verdadeiro problema.
As boas habilidades de solução de problemas ensinam as pessoas, antes de tudo, a entender e a fazer a pergunta fundamental: Qual é realmente o problema? E não continuar antes que elas realmente entendam a resposta a essa pergunta.
Rodrigo Aquino: O ambiente de negócios atual é altamente dependente da tecnologia, o que naturalmente envolve o desenvolvimento de software e sistemas para os mais diversos fins. Então, até que ponto você considera crítica a filosofia Lean para que as organizações sejam mais competitivas neste cenário cada vez mais dinâmico, impulsionado por avanços tecnológicos sem precedentes?
Mary Poppendieck: Uma advertência. Descobri que algumas das técnicas ágeis (não Lean, mas ágeis), evitaram completamente até mesmo falar sobre o fato de que estamos trabalhando em uma área profundamente técnica. Se você não tem habilidades técnicas, na verdade não pode começar a tratar de algumas das questões.
Você pode ter aquelas coisas que eu descrevi acima: respeito pelas pessoas, muito boa habilidade na resolução de problemas e uma boa abordagem da métrica, o que leva a uma visão sistêmica. Mas você também tem que entender que quando estamos em uma área de tecnologia como software, estamos em uma área profundamente técnica onde as habilidades técnicas são fundamentais.
Você não pode esquecer a arquitetura. Uma das coisas que aprendemos nos últimos 20 anos é que a arquitetura de software dos anos 90 não é muito relevante em 2020.
Havia uma metáfora chamada Catedral e o Bazar. Portanto, a Catedral (Notredame ou algo parecido) é muito estruturada e cuidadosamente arquitetada. É assim que nossos monólitos são. E era assim que costumávamos construir software, através de uma grande descrição do que queríamos, tudo o que lá estava contido. Desvende tudo isso, escreva tudo e faça acontecer. E isso era orquestrado por uma pequena equipe de arquitetos.
Mas quando o código aberto veio nos anos 90, havia um livro chamado The Cathedral & the Bazaar. O Bazar é como um mercado onde se pode pensar em pequenos estandes onde as pessoas vendem vegetais, roupas e todo tipo de coisas. E ele pode se expandir para o tamanho que você quiser. Basta ter um pouco mais de espaço. Há algumas regras: isso tem que ser na terça-feira, ou talvez seja no sábado, mas é quando todos vêm, e as carnes aqui e as verduras estão lá, ou o que quer que seja.
Mas basicamente, cada loja é a sua própria loja. O dono da loja toma suas próprias decisões. Eles decidem o que levar; eles decidem se vão ou não; eles decidem o que cobrar. Todas as decisões são tomadas localmente pelo proprietário da loja.
Agora, a arquitetura atual do software mudou da Catedral para o Bazar. Se você tem uma infraestrutura de Cloud, sua arquitetura de software precisa ter um estilo bizarro. E se sua arquitetura de software é um estilo bizarro, estilo de mercado, então sua estrutura organizacional precisa ser "estilo bizarro", porque o software segue o caminho de comunicação da organização.
Portanto, uma estrutura organizacional que permita que pequenas equipes independentes tomem decisões é muito importante e não podemos ignorá-la ao olharmos para o sistema.
Outra área em que precisamos pensar é na necessidade de habilidades técnicas profundas. No início do Ágil, havia a ideia de que tudo o que se precisava era de generalistas. E então eles podiam desvendar as coisas. Bem, deixe-me perguntar-lhe, Tom acabou de fazer uma cirurgia de catarata em seus olhos, certo? Será que ele teria permitido que um cirurgião generalista operasse os olhos dele? Não.
Quando você faz uma cirurgia de catarata ou qualquer outro tipo, eu quero um especialista porque você não pode ser muito bom em algo muito difícil, a menos que você tenha muita experiência. E isso é verdade em muitas, muitas áreas de software.
É verdade nas áreas de segurança e em quase todas as áreas de software. Uma profunda experiência técnica é fundamental. A ideia de que os generalistas podem fazer tudo é um absurdo. Temos este conceito de uma pessoa em forma de T, o que significa que ela é muito especialista em alguma área profunda, mas também capaz de entender uma perspectiva mais ampla. E isso é importante. Mas queremos ter certeza de que as pessoas realmente apreciam as profundas habilidades técnicas que um ambiente técnico muito sofisticado e complexo exige. Você precisa de algumas habilidades (técnicas) realmente boas, não apenas superficiais.
A terceira coisa que eu gostaria de dizer em uma área técnica profunda é que você tem que estar ciente dos “proxies”. É preciso ter cuidado com os “proxies”. É muito melhor ter a equipe interagindo diretamente com o cliente do que ter um intermediário. Isso se aplica em muitas áreas do que fazemos. Quanto mais técnico você for, mais crítico é não haver “proxies”.
Se olharmos para os projetos, eles possuíam coisas chamadas de custo, cronograma, escopo; e essas eram as coisas importantes. Por que são importantes? Quer dizer, são “proxies” para o que você está tentando fazer. Talvez sejam “proxies” ruins. Quem sabe? Em vez de existirem “proxies” entre uma equipe e o que ela está tentando fazer, precisamos conectar as equipes diretamente com as pessoas para quem estão resolvendo um problema ou com as áreas para as quais estão resolvendo um problema.
Precisamos deixar de ter intermediários. Temos engenheiros de software inteligentes, designers inteligentes, pessoas inteligentes que podem formar uma equipe e se envolver diretamente com o problema sem intermediários.
Infelizmente, o “Agile” tem tradicionalmente introduzido intermediários demais. Isso é uma ressaca dos anos noventa e antes. Outra coisa que um ambiente técnico complexo não pode tolerar.
Tom Poppendieck: Sempre lidamos com ambientes técnicos complexos. Nas décadas de 80 e 90, os ambientes técnicos eram frequentemente mecânicos. Eles provinham freqüentemente da cadeia de suprimentos, eram igualmente difíceis e exigiam uma experiência igualmente profunda, mas um tipo diferente de experiência.
Os problemas que enfrentamos hoje são menos profundamente mecânicos ou estão menos relacionados à cadeia de suprimentos. Eles ainda são técnicos, mas exigem um contexto diferente hoje em dia. Diferentes tipos de especialização e diferentes práticas são necessárias para lidar com eles de forma eficaz. Portanto, é mais uma questão de mudar o foco do que a complexidade com a qual temos que lidar.
Nos anos 60, quando comecei a estudar física como estudante do ensino médio, a complexidade era colocar um homem na lua. Mais tarde, trabalhei com algumas das pessoas que trabalharam nesse projeto. E acredite em mim, a complexidade com que eles lidavam, a competência que eles demonstravam, corresponde a qualquer coisa que temos hoje. Mas era um conjunto de ferramentas muito diferente, um contexto muito diferente com o qual eles tinham que trabalhar. Mas, como sempre, as pessoas trabalham nos limites da capacidade da mente humana ou de grupos de mentes humanas.
O que mudou é que as ferramentas com as quais temos que pensar estão evoluindo, e temos que manter nossas práticas para obter os melhores resultados possíveis a partir das ferramentas com as quais temos que pensar atualmente. Hoje, como Mary mencionou, isso tende a ser cloud, inteligência artificial, talvez.
Embora eu terei mais fé na inteligência artificial quando eu começar a ver mais da inteligência real. Mas ainda estamos nos limites do que grupos de pessoas podem realizar com suas mentes humanas. E eu não acho que isso vai mudar.
Rodrigo Aquino: O que você pensa sobre o papel de um gerente de fluxo (flow manager)? Faz sentido?
Mary Poppendieck: Eu tenho uma proposta diferente de um gerente de fluxo. Acredito que na maioria dos empreendimentos, o que se pretende fazer é realizar experiências constantes para fazer as coisas avançarem. Vou lhe dar um exemplo. O gerente de fluxo, neste caso, não é uma pessoa, é um conjunto de eventos integradores. Então, vejamos o SpaceX, muito bem! Quando a SpaceX começou, eles decidiram que as viagens espaciais seriam bem menos caras. Portanto, eles tiveram que parar de jogar tudo fora em cada lançamento. Eles tinham que pegar seus veículos de lançamento, trazê-los de volta, aterrá-los, usá-los novamente, ou nunca mais cobrir seus custos.
Ninguém tinha a menor ideia de como pousar esses foguetes ou como eles deveriam ser. Eles passaram provavelmente dois anos, em cada talvez três ou quatro meses, fazendo um lançamento de teste, e você pode ver um vídeo online. Você já o viu alguma vez? Todos esses lançamentos de teste? E eles caíram! E depois outro, e depois se espatifou. Para muitos lançamentos, eles não foram bem-sucedidos. Mas a cada três ou quatro meses, havia um lançamento.
Havia muitas equipes trabalhando nesse lançamento. Todos eles sabiam a data e o objetivo. Se ele espatifasse, e a peça pela qual você é responsável tivesse alguma coisa a ver com aquele acidente, você teria 24 horas antes de ligar para Elon Musk e dizer: "Foi isso que aconteceu, e é por isso que nunca mais vai acontecer de novo". E foram esses constantes lançamentos de testes que os fizeram encontrar os problemas muito mais rapidamente do que se tentassem pensar em todos eles ou os atraíssem para o papel. Eles testaram, e eles testaram. E ficaram cada vez melhores e melhores.
Portanto, quando você tem uma coisa muito grande e complicada em uma tecnologia muito sofisticada, talvez a melhor maneira de fazer isso seja fazendo-o. Esta é realmente uma abordagem padrão de engenharia. Você o faz através de três ou quatro meses de intervalo integrando eventos, mesmo que seja um programa de cinco anos. Você sabe o que vai fazer daqui a três meses, e você o testa. E esses testes se tornam sua gestão de fluxo. "Isto é o que vamos fazer em janeiro; este é nosso objetivo em junho; isto é o que poderíamos acreditar que podemos fazer em setembro". E então descobriremos a partir daí aonde ir com base em quão longe chegamos".
A gestão lá é o evento integrador que faz as coisas se sincronizarem. Agora, se você tem uma orquestra, e quer que 50 pessoas toquem instrumentos juntos, você precisa de um maestro. O Maestro não é uma pessoa intermediária, mas aquele que mantém todos juntos. Se é isso que o gerente de fluxo faz, nós sabemos que precisamos de um maestro. E se o gerente de fluxo trabalha como um maestro, tudo bem.
Mas se o gerente de fluxo disser: "isto é o que você deveria estar fazendo e tenta organizar entre todos, isso não está bem". Portanto, quando se tem muitas pessoas, é preciso um mecanismo de coordenação, mas não um intermediário. O intermediário deve ser a experiência real que as pessoas fazem, não a pessoa.
Tom Poppendieck: Os experimentos só falham se nada tiver sido aprendido. Todo o propósito do experimento é aprender com ele. O brilhantismo das boas experiências é que elas podem ser feitas rapidamente, de forma barata e proporcionar o máximo de aprendizado possível. Agora, no caso do SpaceX, o tamanho do experimento é necessariamente bastante grande.
Não se pode aprender com pequenos foguetes construídos em uma tarde. Em software, por outro lado, é possível realizar experimentos muito mais rápidos; (realizar) pequenos experimentos muito rapidamente. Isso se tornou óbvio há dez anos, quando a integração contínua se tornou muito viável. Hoje, você mal pode afirmar ser uma pessoa de software se não estiver usando a integração contínua.
Mary Poppendieck: O Agile e o Lean começaram há 20 anos no software. A ideia de que você poderia implantar as coisas automaticamente com testes automáticos ao longo da cadeia (pipeline) não existia. Foram necessários dez anos de reflexão para resolver este problema de implantação rápida antes que o livro Continuos Delivery (Entrega Contínua) fosse lançado. Se você ler a introdução do livro de Entrega Contínua, ela foi baseada em uma pergunta que eu fiz em meu primeiro livro: “Quanto tempo leva se você quiser mudar uma linha de código em seu software de acordo com seu processo normal?”
E naquela época, você não podia fazer isso por meses. Você tinha este grande processo de construção. Eu tinha codificado em grandes máquinas de processo com software, 10, 20, e 30 anos mesmo antes disso.
Se eu precisasse fazer uma mudança, eu poderia desligar aquela peça, fazer a mudança, testá-la, voltar a colocá-la dentro, e eu poderia fazê-lo em cinco minutos se quisesse. E nós tínhamos perdido isso, e em vez disso tínhamos estes grandes processos de construção. E assim, nos anos 2000, o conceito de Lean significa: Voltemos ao fato de que se o cliente tem um problema e é uma peça de código de uma linha, podemos resolvê-lo em cinco minutos.
E isso levou dez anos para reunir nossa tecnologia até mesmo para considerar a entrega contínua nas empresas. Hoje em dia, é bastante comum. O cliente tem um problema que qualquer pessoa deve ser capaz de resolver em cinco minutos. Por que leva cinco meses?
Tom Poppendieck: O problema de hoje não é o fluxo de requisitos de código de alguma fonte para uma equipe encarregada de implementar a solução desses requisitos. O problema de hoje é descobrir os problemas, e ninguém pode fazer isso. Não há sequer uma especialidade técnica que possa fazer isso. Agora que podemos fazer a integração contínua e aprender muito rápido, precisamos reunir grupos de pessoas que possam descobrir em conjunto os problemas reais.
E o fluxo tem que ser feito por grupos de pessoas que incluem não apenas pessoas tecnologicamente sofisticadas, mas também por pessoas que são especialistas no assunto. Pessoas responsáveis pelas operações de uma organização, para garantir que ela seja financeiramente sustentável, que estejam bem conscientes das restrições legais em que a organização opera, e muitas outras áreas.
O que está acontecendo hoje às vezes é chamado de digitalização das organizações, o que significa que o silo de especialização técnica não requer nada parecido com alguém gerenciando o fluxo de coisas que entram ou saem dele. Ele requer uma interface entre todas as capacidades que uma organização pode dominar e o mercado ao qual se dirige para ser feito da maneira mais eficaz possível.
Rodrigo Aquino: Você e Tom viajaram por todo o mundo. Qual foi o maior ganho que vocês observaram nas empresas que usaram Lean?
Mary Poppendieck: Nós nunca atuamos como consultores, apenas como professores. Nunca ficamos muito tempo com uma empresa. Portanto, é meio difícil conhecer qualquer empresa que começou com algo chamado Lean, e depois saber para onde foram. É uma pergunta difícil de responder, mas vou falar sobre um par de empresas que vimos.
Curiosamente, a primeira se chama Tandberg. Na época, era uma pequena empresa na Noruega que fazia videoconferência. Agora estamos no Zoom, e as raízes do Zoom estão nessa empresa, mas em seu processo, eles nunca ouviram falar de Agile, nunca ouviram falar de Lean, e seu processo era incrível. Era rápido e flexível.
Eles podiam fazer um cartão com um chip ISIS, que é algo que normalmente leva (apenas um chip) 12 meses para ser projetado. E eles foram capazes de colocar um novo produto com este chip muito sofisticado no mercado em nove meses porque no meio de uma atualização e disseram: "Vamos adicionar este chip. Eles eram muito, muito flexíveis, muito orientados ao cliente. E nunca ouviram falar em Lean e nunca ouviram falar em agile. Eles só estavam fazendo isso.
Outra empresa que eu diria que tem um dos ambientes de software mais enxutos que eu conheço é a AWS (Amazon Web Services).
A Amazon Web Services nunca usa o termo Lean. Seus processos são de tal modo que permitem que a equipe determine e melhore seus próprios processos. Cada uma de suas equipes é formada por um pequeno grupo de doze, dez, seis pessoas, ou algo parecido, com uma métrica de foco no cliente que eles devem trabalhar juntos para melhorá-la.
Eles têm um líder de equipe, como um mini CEO ou talvez o maestro. E eles possuem quaisquer que sejam as habilidades técnicas ou operacionais que precisam para realizar seu serviço, trabalhando com objetivos do cliente e SLAs (Service Level Agreements).
Essas são as coisas que se espera que eles mantenham com seus “upstream clients” e depois forneçam as especificações para seus “downstream clients”. Eu não vi uma empresa de software tão grande crescer tão rapidamente e, no entanto, ser tão flexível como a Amazon Web Services.
Se você pensar nisso, há uma empresa que sabe como escalar. Falamos em escalonar sendo um processo fantasioso. Bem, isso é errado. Escalar é, na verdade, um monte de equipes semi-autônomas que podem tomar suas próprias decisões e fazer as coisas acontecerem muito rapidamente. Esse é um conceito de escala muito melhor do que ter um processo grande, coordenado e orquestrado. No mundo do software, é isso o que eu vejo.
Se você olhar para as raízes da Amazon, estão na manufatura/sistemas de produção. Se você olhar para as coisas que influenciaram a realização, é basicamente um conceito de logística.
Todas as primeiras coisas que a Amazon fez foram baseadas nos princípios Lean. Jeff Bezos chegou a passar uma semana trabalhando em uma fábrica, e estava trabalhando para um "Lean sensei". A certa altura, ele foi varrer o chão do armazém. O Lean Sensei se aproximou dele e disse: "Por que você está varrendo o chão"? E ele respondeu: "Porque ele precisa de limpeza". E ele (o Lean Sensei) disse: "Por que você está varrendo o chão"! "Tudo bem, mas se você realmente quisesse fazer algo útil, você descobriria porque fica sujo e evitaria que isso acontecesse".
Assim, ele (Jeff Bezos), em toda a área de produção, usa muitos princípios Lean para descobrir como acelerar e reduzir o custo do Lean, e você pode dizer que eles não tinham uma maneira padrão de enviar.
Cada vez que eu recebo uma caixa, você pode dizer que ela veio de uma equipe diferente experimentando uma maneira diferente de reduzir o custo de envio. E até hoje, eu continuo me maravilhando: "Oh, isso é um novo conceito". Como você pode ter um novo conceito em transporte marítimo? Mas cada equipe individual tem a autoridade e a expectativa de que constantemente descobrirão como melhorar sua área.
Acho que existem, definitivamente, princípios Lean que também influenciaram como a AWS se reúne. A AWS é um monte de equipes independentes sem processo padrão, com métricas de foco no cliente, e um monte de solução de problemas, treinamento e ajuda. Mesmo que eles não utilizem o termo Lean, eu acho que eles são Lean.
Eu já falei sobre a SpaceX, outra empresa que eu acho que realmente sabe como colocar hardware e software juntos em uma escala maciçamente complexa. E eles reduziram o custo de lançamento de um foguete, em um fator de sete.
O custo de lançamento de um quilo no espaço ficou em 18.000 dólares americanos por quilo por 30 anos. Agora é sete vezes mais barato, e eles fizeram isso em cinco anos. Agora qualquer um pode lançar qualquer coisa para o espaço porque é tão barato. Eles descobriram como reduzir isso. Esse era o objetivo. E eles descobriram que para ser uma empresa espacial, seus clientes não podiam tolerar os custos atuais. Eles descobriram como fazer isso mais barato.
Esse era o mantra deles, não porque barato era bom, mas porque os clientes não podiam pagar as tarifas atuais. Agora eles são sete vezes mais baratos e estão ficando menos caros. Todos os tipos de empresas diferentes podem agora lançar um satélite para o espaço, onde quer que estejam. É muito mais acessível porque eles se concentraram muito no material reutilizável. Esse é um conceito Lean. Vamos dar uma olhada em todo o sistema. Quais são as limitações que impedem que os clientes possam usar o que temos? Como podemos, mesmo que levemos dez anos, mudar essa dinâmica?
Tom Poppendieck: Eu nunca vi uma empresa Lean de sucesso (se você definir uma empresa Lean como uma empresa que pratica Lean). A razão é que as práticas não são Lean, mesmo que algumas empresas as utilizem.
Olhando para empresas de sucesso que aplicam o pensamento Lean para desenvolver suas práticas, elas normalmente são muito casuais em permitir que seus concorrentes venham ver o que estão fazendo porque sabem que seus concorrentes irão copiar suas práticas. E quando copiarem suas práticas, elas falharão. Porque a questão não são as práticas, mas sim o pensamento. É a busca (pesquisa, investigação). São as perguntas que você faz e como você remove os obstáculos que impedem as pessoas de resolvê-las. Portanto, não há uma maneira Lean.
Há uma maneira Toyota. Há um caminho Tandberg. Há um jeito Scania. Há um caminho Steelcase. Há um jeitinho John Doerr. Todas as formas diferentes de aplicar os valores Lean a contextos e indústrias diferentes, em momentos diferentes na evolução da tecnologia.
Mary Poppendieck: E eu pensei que você ia dizer: "você nunca viu uma empresa Lean"! Porque nenhuma empresa que realmente é Lean está satisfeita com o ponto em que se encontra. Elas sempre têm muito mais a melhorar, para estar ainda mais perto (de ser Lean).
Tom Poppendieck: Mesmo a Toyota nunca escreveu à maneira Toyota porque seria diferente quando eles terminassem um livro.
Rodrigo Aquino: Como a filosofia Lean é capaz de contribuir para a inovação?
Mary Poppendieck: Inovação, por definição, significa algo que não existia e que então passa a existir. Lembre-se, temos todos os tipos de pessoas no mundo que estão lutando com qualquer tipo de problema, e muitas pessoas estão tentando encontrar maneiras de resolvê-lo. De alguma forma, apenas algumas poucas pessoas o fazem. Apenas algumas poucas empresas o fazem. Mas as empresas que são realmente boas em inovação não têm um programa de inovação. Elas descobrem como ter muitas mentes tentando muitas experiências.
Eu estive na 3M por 20 anos, e no tempo em que estive lá, eles colocavam todos os anos, muitos, muitos, muitos produtos novos no mercado. Todos os tipos de vários produtos inovadores. E como eles fizeram isso? Basicamente disseram: "qualquer pessoa que tenha uma boa ideia e possa reunir uma equipe, pode gastar algum do seu tempo livre para descobrir como fazer um produto". E um produto tem suas margens e utiliza alguma tecnologia própria. E se você acha que tem uma boa ideia, vá em frente.
Havia um monte de mentes diferentes que se soltaram para descobrir por si mesmas que tipos de problemas interessantes eles poderiam resolver. Quando você tenta coordenar e centralizar a inovação, ela não funciona. Quando você torna possível que todas as pessoas inteligentes da empresa usem seus cérebros para apresentar ideias interessantes sobre como resolver problemas de clientes ou problemas que os clientes em potencial possam ter, é quando você obtém inovação.
Inovação é sobre tentar muitas coisas e continuar melhorando.
A última coisa sobre inovação é: a inovação sempre requer que as pessoas pensem de forma sistêmica. Se você pensa em inovação, parte do tempo está trazendo coisas de outros campos. Eu tenho um background em uma área diferente, mas se eu olhar para meu passado e para um problema, eu poderia aplicar isso (a experiência). Às vezes, significa dar uma olhada no problema, ver um problema mais profundo, e atacar o problema mais profundo em vez do problema superficial.
Portanto, o pensamento sistêmico também é um aspecto essencial da inovação. E pensar holisticamente, em vez de focalizar apenas uma peça.
Tom Poppendieck: Um Lean sensei não dá respostas. Um Lean sensei faz perguntas. O objetivo dessas perguntas não é evocar uma resposta, mas remover uma barreira ao pensamento da pessoa. O objetivo da inovação é questionar suas suposições. Para questioná-las, você tem que identificar quais suposições você está realmente fazendo que o impedem de pensar de forma diferente. Uma vez que você compreenda suas suposições questionáveis, então você estará imediatamente livre para pensar de forma diferente. E é de lá que vem a inovação.
Mary Poppendieck: Deixe-me voltar para os anos 2000. Eu já estava escrevendo código em um departamento de engenharia (não em um departamento de TI), onde meu software controlava grandes equipamentos por algumas décadas. E então descobri que havia este processo no qual as pessoas tinham estes grandes projetos e exigências. Eu pensei, como isso poderia funcionar? Eu nunca tinha visto isso antes porque minha formação é em programação de engenharia, não em programação de TI.
Eu havia estado em uma fábrica onde instituímos um programa just-in-time, que eventualmente outras pessoas poderiam chamar de Lean, e foi um sucesso fenomenal. Fizemos isso porque estávamos em concorrência com os japoneses, tornando o que estávamos fazendo (videocassete) muito mais barato.
Precisávamos ser capazes de descobrir o que eles estavam fazendo para que pudéssemos competir. E fizemos isso com sucesso. Assim, combinar minha experiência em manufatura com minha experiência em programação e ver como as pessoas estavam desenvolvendo software no final dos anos 90, foi chocante. Peguei ideias de domínios completamente diferentes e tentei aplicá-las a software apenas para que as pessoas pensassem de forma diferente.
O ponto é que hoje desenvolvemos algumas ideias “totalmente novas” sobre a maneira correta de fazer as coisas. E você sabe o que mais? A maioria delas está errada.
É por isso que eu me preocupo um pouco com o uso do Lean; porque as pessoas fizeram com que ele significasse as coisas erradas. Portanto, você tem que ter cuidado com o que quer que esteja fazendo. Se as práticas que você está fazendo vêm de 10, 20 anos atrás e você está em software, elas estão desatualizadas. Você precisa descobrir como pegar os problemas de hoje e olhar mais amplo e profundo e dizer, o que está errado sobre essas coisas que temos feito? Onde eles estão saindo dos trilhos? Onde eles estão nos tropeçando?
Porque agora desenvolvemos uma nova cultura em torno do Ágil, e falamos sobre problemas com o Ágil. Por quê? Não porque Agile é errado ou ruim, mas porque ele resolve os problemas dos anos 90. Precisamos resolver os problemas de 2020. Não precisamos mais resolver os problemas da década de 90 porque nosso domínio se move muito rápido. Precisamos ver quais são os problemas de hoje. Muito está sendo investido em maneiras de resolver os problemas de 15 anos atrás. Asseguro-lhes que os problemas são diferentes.
Precisamos dar vários passos para trás, olhar para outros campos e o que eles estão fazendo, e como eles estão gerenciando tipos similares de problemas. É de lá que vem a inovação. Precisamos descobrir para onde o futuro está indo. Onde estarão as crianças que saem da escola daqui a 10 anos?
Rodrigo Aquino: Sempre que estou com vocês dois, eu aprendo a cada minuto. Acredito que você e Tom já responderam a essa pergunta, mas vamos ao que interessa. Que conselho você daria a um gerente que deseja iniciar uma jornada de Lean em sua organização?
Mary Poppendieck: Estivemos em uma conferência na França, sobre Lean, em Paris, e algumas pessoas de um banco chamado ING, na Holanda, estiveram lá, e deram uma palestra. Isto foi, talvez há 10 anos, ou algo parecido. E durante a palestra, eles disseram que tinham métricas que deveriam encontrar, mas todos os outros abaixo deles teriam apenas duas métricas. Apenas duas métricas.
A primeira era que você deveria fazer uma mudança de código toda semana.
E a segunda dizia: “é melhor não causar nenhum problema de qualidade.” Eles apenas disseram: "mude alguma coisa toda semana, e não se atreva a fazer com que o sistema caia". Estas foram as instruções deles para as pessoas que trabalham para eles. Eles disseram que o mais interessante foi que todas as métricas que estavam medindo começaram a melhorar drasticamente quando fizemos isso.
O que eu digo é: não passe suas métricas para as pessoas abaixo de você. Em vez disso, desafie-os de uma forma que os leve a serem criativos e atenciosos. Eles nem mesmo disseram que tipo de mudança tinha que ser. Eles não lhes disseram nada sobre o tipo de mudança que deveria ser percebida por eles.
Deixe que as pessoas inteligentes que trabalham para você descubram o que fazer. Dê-lhes alguma liberdade e algo para energizá-los e desafiá-los. Comunique o propósito, o que você está tentando alcançar, ao contrário da maneira como você quer que eles se comportem ou as coisas que você quer que eles façam. Comunique o que é importante sobre o que sua empresa está tentando entregar aos clientes e faça-os pensar em maneiras criativas de fazer isso, em vez de dizer-lhes como resolver os problemas. Deixe-os ser inteligentes. E não deixe que suas métricas se interponham no caminho.
Tom Poppendieck: Um dos papéis mais críticos de gestão e liderança é não dizer às pessoas o que fazer, mas, em vez disso, dizer-lhes quais são as restrições, estabelecendo o domínio em que seu pensamento precisa trabalhar.
O papel básico aqui é que sempre que você tem que pensar em um problema, você tem suposições sobre a natureza do problema, a natureza das soluções possíveis: as competências do software, as habilidades de seu cliente para se adaptar a novas formas de pensar. E essas suposições são geralmente tão necessárias quanto equivocadas. Elas mudam com o tempo, e você tem que capacitá-las a mudar enquanto as alavanca para manter contato com a realidade em que a organização está trabalhando.
Mary Poppendieck: E elas devem ser restrições válidas. Uma vez, estávamos no Rio em uma empresa de televisão (Globo), e eles iriam transmitir a Copa do Mundo em 8 meses. Eles teriam que encontrar uma maneira de transmitir todos os jogos dinamicamente de uma maneira que nunca fizeram antes e ainda escrever todo o software para fazer isso. E você sabe o que mais?
Eles tinham um prazo, e esse prazo não ia se mover. O tempo todo, muitas equipes ágeis pediam para alongar o prazo, mas os jogos iam acontecer quer eles estivessem prontos ou não, então eles tinham que estar prontos. Devido a essa restrição, este prazo não se move.
Eles tinham muitas outras coisas que lhes era permitido fazer porque o prazo não ia se mover. Ninguém tentou dizer a eles exatamente como deveria funcionar. Eles deveriam apenas se certificar de que estavam prontos para transmitir os jogos na TV quando a copa começasse e, nesse nível de restrição, eles eram muito criativos porque não tinham restrições desnecessárias.
E eles estavam trabalhando muito agressivamente para encontrar maneiras de provar que podiam fazer as coisas e depois melhorar o que faziam. E tenho certeza de que quando estes jogos chegaram, você os viu na TV. Portanto, quando você está em um ambiente de negócios, há alguns aspectos que você não pode mudar e não pode discutir, e depois há coisas que podem.
Você precisa ter certeza de que as verdadeiras restrições são muito claras e que quaisquer outras restrições artificiais não estejam lá. Você precisa descobrir as restrições mais críticas.
Você tem que dizer: o dinheiro é uma restrição real, ou é apenas artificial? O tempo é uma restrição real, ou é apenas artificial? Nesse caso, certamente não foi artificial. Descubra a restrição mais importante, e tudo o mais é negociável. E depois certifique-se de que as pessoas trabalhem apenas dentro das restrições necessárias. Mas, dentro dessas restrições, elas precisam cumprir.
Desse modo, você obtém equipes muito criativas. Todas as pessoas com quem conversamos entenderam o que estavam fazendo. Eles simplesmente mal podiam esperar para ver os jogos transmitidos pela TV e estavam trabalhando para que isso acontecesse.
Esse era um excelente propósito para o qual eles trabalhavam. Você precisa comunicar o propósito e as limitações e ter certeza de que elas são verdadeiras limitações. Dentro dessas restrições, deixe as pessoas serem tão criativas quanto possível.
A organização vem de eventos integrados. Os eventos integrados são as coisas que acontecerão, quer você goste ou não, nesta data em particular. Esse é o seu princípio estruturante.
Tenho certeza de que a Globo se saiu muito bem porque seu princípio estruturante (organizador) foi cumprir esse prazo, ter um mecanismo seguro e garantir que eles pudessem transmitir muito mais rápido do que quando começaram todas essas coisas. E todos estavam realmente entusiasmados com isso. Não tenho certeza se importava o quão organizados eles estavam, mas tenho certeza de que importava que eles atingissem o prazo, tivessem a velocidade de transmissão que precisavam e fossem capazes de colocar essas coisas na TV, e todos matariam por isso, e o resto, bem! O que há de tão importante nas coisas sem importância? O que importa é o resultado e o impacto, não como se chega lá.
Rodrigo: Mary e Tom, sempre que falo com vocês sinto uma energia espetacular. Lembro-me da última vez que os vi no aeroporto. Depois de quase sete anos, você não mudou fisicamente. É impressionante.
Mary Poppendieck: Você tem tempo para mais uma história?
Uma vez, alguém veio e me disse que os testes eram um desperdício. Eu disse que, em software, os testes são fundamentais. Mas ele disse que em toda parte, em Lean, os testes são um desperdício.
O problema é que, em software, os testes são projetados. Pense na escrituração de partidas dobradas. Se você é um contador, você tem que fazer uma contabilidade de dupla entrada; caso contrário, você pode cometer muitos erros. A escrituração contábil de dupla entrada é um desperdício? Nenhuma empresa de contabilidade no mundo diria que a escrituração contábil por partidas dobradas é um desperdício. Testes e software são escrituração contábil de dupla entrada porque você tem um ambiente complexo. Você faz as coisas de duas maneiras diferentes e sempre se certifica de que elas coincidem.
Seu teste é na verdade o projeto de como você quer que ele funcione, mas você o automatiza para executar esse teste contra o código. Então o código o faz funcionar, e você executa os dois juntos o tempo todo porque você tem sua escrituração contábil de dupla entrada. Eu podia me lembrar de estar tão frustrada porque ele estava tão certo de que o teste era um desperdício, e eu estava tão certa de que ele estava absolutamente errado, mas eu não sabia como explicá-lo.
Rodrigo Aquino: Eu costumo dizer que quando você testa algo, você tem a oportunidade de aprender sobre seu processo e melhorá-lo.
Mary Poppendieck: Eu entendo o que você está dizendo, mas você percebe que, em entrega contínua, você escreve o código, envia-o pelo “pipeline” e ele entra. A única razão pela qual funciona é que há um teste automatizado que corre até o final do “pipeline”. Caso contrário, seriam semanas de verificação manual. A única maneira de termos uma implantação rápida no ambiente de nuvem é porque criamos um mecanismo de contabilidade de dupla entrada.
Não é apenas para testar seu processo. O teste é um mecanismo que permite que nosso código, com um alto grau de confiabilidade e segurança, seja implantado imediatamente porque o vemos sob duas perspectivas o tempo todo. Nunca temos apenas uma maneira de olhar para ele.
Sempre o temos a partir de duas perspectivas. É exatamente a forma como a contabilidade funciona e por que confiamos nela. Nós automatizamos porque somos pessoas de software. Nós sabemos como automatizar as coisas, certo!
Essa automação em entrega contínua é um dos maiores avanços de 2000 para 2010 ou 2015 no desenvolvimento de software. Mesmo sabendo disso, todos os anos antes, nunca nos ocorreu usar nossas próprias ferramentas para que fosse possível saber que não cometemos um erro.
Tom Poppendieck: Mas se você parar por aí, é inútil porque só lhe permite provar que o software faz o que você queria que fizesse. Ele não prova que o que você queria que ele fizesse funciona para o cliente.
Não prova que o que você queria que ele fizesse funciona no mercado. A vantagem da entrega contínua que todos estes testes automatizados de software permitem é que você pode experimentar as coisas rapidamente, experimentá-las no mercado, experimentá-las com um cliente, experimentá-las contra o problema que você está tentando resolver, e ver se funciona.
Você recebe feedback rapidamente. Não do software, mas mais importante, do domínio do problema que você está tratando. Como mencionei anteriormente, o software é inútil, exceto na medida em que realmente impacta o problema que você está tentando resolver, a oportunidade que você está tentando explorar. A única maneira de descobrir isso é experimentá-lo.
A entrega contínua permite que você experimente rapidamente. Experimente muitas coisas e veja o que funciona, que é o tema de toda a tarde; experimente e veja o que funciona.
Use suas oficinas de tecnologia para fazer isso o mais rápido e ao mais baixo custo possível, para que você possa entregar um impacto real que seja importante para as pessoas que são a razão de você estar fazendo isso.