David J. Anderson, pioneiro na implementação de Kanban no desenvolvimento de software e um dos principais responsáveis pela popularização do método no mundo, veio ao Brasil recentemente para dois treinamentos pela Aspercom e conversou com com o InfoQ Brasil sobre Lean, Agile e Kanban. Anderson revelou algumas de suas opiniões sobre as principais questões em torno do Kanban e seus mitos e desafios, além de discutir sua integração com práticas ágeis de desenvolvimento. Veja a seguir os melhores momentos da entrevista.
InfoQ Brasil: Como você relacionaria a filosofia Lean e o Agile?
David: Obviamente há muita semelhança entre as abordagens. Uma das diferenças, entretanto, é que o Lean tem como filosofia a busca pela perfeição, ao passo que o Agile adota a ideia de avançar com informações imperfeitas e corrigi-las mais tarde. Vários pensadores do Lean teriam dificuldade em lidar com essa abordagem de avançar, mesmo com informações incompletas. Esta é uma diferença fundamental entre as duas filosofias.
Uma outra diferença entre Lean e Agile está na forma como as pessoas são vistas dentro das duas filosofias. No Lean existe um pensamento sistêmico. A ideia é que o desempenho das pessoas é afetado especialmente pelo sistema do qual fazem parte e a maneira de se demonstrar respeito pelas pessoas, no Kanban, é projetando um sistema que as permita trabalhar bem.
Já na comunidade Agile, especialmente nos Estados Unidos, há muita influência política. As pessoas são muito humanistas ou libertárias. Há inclusive alguns anarquistas que acreditam que as pessoas são inerentemente boas e que, portanto, é possível confiar nelas cegamente, e que o resultado será excelente se as deixarmos "em paz". Por isso, os anarquistas pregam a ideia de que todos deveriam poder fazer o que bem entendessem. Pessoalmente, acredito que isso seja um otimismo exagerado.
Historicamente, houve a influência de um comunismo puro na comunidade Agile, que se manifesta em pensamentos como: Todos os gerentes são ruins; qualquer tentativa de controlar as pessoas é ruim; qualquer tentativa de impor autoridade sobre as pessoas é ruim. Não estou convencido de que isso seja verdade, nem que os pensadores Lean compartilham dessas ideias. Pensadores Lean acreditam na construção de sistemas e que há classes de pessoas que operam estes sistemas. A cultura kaizen não é auto-organização. Há, portanto, uma abordagem bastante diferente em relação a pessoas e organição entre Agile e Lean.
E para mim, é perfeitamente aceitável se alguém vai ao trabalho, faz seu serviço, recebe seu salário e volta para casa para aproveitar sua vida - se preocupar com a família. Tudo bem se a paixão das pessoas está fora do trabalho. Acredito que muitas pessoas do Agile pensam que todos na equipe deveriam ser profundamente apaixonados sobre sua profissão. Não considero isso prático nem realístico ou pragmático - em implementações de larga escala ou em grandes empresas. Esta ideia de contar com um amor intenso pela profissão pode até funcionar para uma startup de seis pessoas, mas não funciona para uma unidade de negócio de 300 pessoas numa grande empresa.
InfoQ Brasil: Mas a ideia de "dar poder à equipe" não iria contra essa afirmação?
David: Dar poder à equipe não significa permitir que as pessoas façam o que bem entendam ou assumir que, de alguma forma, se auto-organizarão para produzir o resultado desejado. Dar poder é definir limites, é o mesmo que fazemos ao educar as crianças: dizemos a elas o horário de ir para cama; quando podem brincar ou sair de casa; ou que devem permanecer dentro do condomínio; que podem nadar apenas na parte rasa da piscina; que não podem pular do trampolim e todo este tipo de coisa. Logo, dar poder à equipe é dar às pessoas limites claros para permitir que tenham, então, iniciativas dentro desses limites.
InfoQ Brasil: Recentemente foi adicionada mais uma prática fundamental ao Kanban: "Implementar feedback organizacional". Por quê?
David: Na realidade não acrescentei a prática, apenas a tornei explícita. Era um aspecto que já estava lá de forma implícita; No meu livro "Kanban: Mudança Evolucionária de Sucesso para Seu Negócio de Tecnologia" não listei esta prática entre as fundamentais do Kanban, mas já havia um capítulo inteiro sobre o assunto. Percebi que foi um erro não tê-lo feito, ao verificar que pouquíssimas implementações incluíram a adoção do ciclo de feedback em nível organizacional. Às vezes, quando uma coisa não está acontecendo, é preciso torná-la mais óbvia e adicionar esta prática às práticas fundamentais teve este objetivo.
InfoQ Brasil: Você diz que o Kanban é uma forma de limitar a demanda de acordo com a capacidade. Quais as vantagens de se fazer isso e como convencer a área de negócios dessa necessidade?
David: Precisamos equilibrar a demanda com a nossa capacidade. É importante evitar sobrecarregar essa capacidade, ir além dela. Se criamos uma sobrecarga, na verdade produzimos menos, com qualidade inferior e muitas vezes de forma mais lenta. Ao manter um equilíbrio, podemos melhorar nossa capacidade e aumentar a velocidade. Faremos mais e com mais qualidade.
Em relação às pessoas do negócio, estas precisam entender o que significa limitar a demanda de acordo com a capacidade: significa que devemos racionar a demanda de acordo com a oferta, pois sempre haverá mais demanda que a nossa capacidade de supri-la. Não existe limite à engenhosidade humana. É preciso, entretanto, ser capaz de avaliar com precisão os riscos e os benefícios de todas essas ideias.
Assim, há muitos ganhos em ajudar as pessoas do negócio a analisar os riscos e entender os benefícios de suas ideias, a se concentrar no que realmente gera valor, para que tenham um portfólio balanceado, que leva em conta a nossa capacidade. Assim, apesar de ser possível melhorar nossa capacidade para suprir as demandas, também é necessário aprender como escolher as melhores opções entre as ideias disponíveis.
Se pudermos fazer as duas coisas (aumentar nossa capacidade e limitar/melhorar a gestão de riscos da demanda), podemos viver com muito mais harmonia. Uma das razões pelas quais temos mais e mais demandas é porque há incerteza quanto ao futuro. As pessoas do negócio querem se proteger, pedindo que "façamos tudo", o que obviamente é inviável. Precisamos, portanto, ajudá-las a identificar melhor os riscos e entender as incertezas que estão enfrentando, ajudando-as a ter mais confiança nas escolhas que estão fazendo.
InfoQ Brasil: Quais, na sua opinão, são os os mitos e incompreensões mais comuns em relação ao Kanban?
David: Acredito que existe uma série de mitos, e um deles é relacionado ao quadro Kanban. A Agile Alliance tem até uma página sobre quadros kanban, onde são apresentados como uma prática ágil, mas o método Kanban não tem esse nome por causa do quadro; chama-se Kanban por implementar um sistema virtual; um sistema puxado (pull) que contribui para limitar o trabalho em progresso e adiar o comprometimento até o "último momento responsável" (como chamam os pensadores do Lean).
O quadro é apenas uma forma de visualizar o que está acontecendo. Na verdade, o quadro veio depois; primeiro veio o sistema kanban. Naquela época, os quadros eram conhecidos como "painéis de cartões" e eram comuns na comunidade ágil. O quadro, entretanto, não era a novidade, mas sim o sistema virtual Kanban.
Há vários outros mitos recorrentes. Um deles diz que o Kanban serve apenas para manutenção e operações de TI, e não para realização de projetos grandes. Isso é claramente apenas desinformação. Por exemplo, em 2007 fizemos um projeto de mais de 11 milhões de dólares, com mais de 50 pessoas, utilizando Kanban.
Temos utilizado o Kanban em projetos grandes desde o início de nossas implementações, especialmente por ajudar na melhoria da previsibilidade e da gestão dos riscos. Afinal, ter alguma clareza sobre os cronogramas de entrega é importante para a gerência de projetos e para a governança em geral.
Assim, também digo que é um mito o Kanban ser apenas para trabalhos de manutenção de TI e não para projetos de grandes porte.
InfoQ Brasil: Há o mito de que o Kanban nos levaria de volta ao modelo Cascata [Waterfall]. Isso ainda persiste?
David: Este mito era muito comum entre os anos de 2007 e 2009, mas não se fala muito hoje em dia. A razão disto está provavelmente no fato das primeiras implementaçãos do Kanban terem sido aplicadas em equipes rodando STLCs (Software Testing Life Cycle) ou outros métodos não reconhecidos como ágeis, como personal software process ou team software process, de forma que os primeiros exemplos de Kanban eram exemplos pouco ou nada ágeis.
Este fenômeno era natural, pois introduzi o Kanban como uma forma de melhorar equipes que estavam rejeitando os métodos ágeis e os únicos exemplos disponíveis, portanto, eram da época pré-ágil. Hoje em dia, contudo, é muito comum algo em torno de 50% das implementações serem feitas sobre o Scrum. Por esta razão, acredito que este mito tenha praticamente desaparecido.
InfoQ Brasil: Você cogitou adicionar a prática "Liderança - conceder permissão para ideias e encorajar o processo de inovação de qualquer integrante da equipe" como questão central do Kanban, por que esta prática não foi incluída? Você vê a necessidade de um "Kanban Master"?
David: Na verdade acabei colocando a ideia de que se deve encorajar a liderança e haver uma diferenciação de liderança e gerenciamento, nos princípios do Kanban. Os gestores são responsáveis pelo sistema que estão operando, pelo design do sistema, suas políticas e respectivas decisões para sobrescrevê-las. Isto é positivo, mas queremos que as pessoas envolvidas na realização do trabalho sejam contribuidoras individuais. Queremos que tanto trabalhadores como gestores exibam atos de liderança.
Um ato de liderança é, por exemplo, uma atitude de buscar sempre melhorar e nunca considerar que a situação atual está totalmente boa. Se não houver este tipo de atitude, portanto, não haverá o catalizador de melhoria contínua. Todos poderiam dar de ombros e dizer "Bem, as coisas são como são, vamos continuar assim" e nada melhoraria. Liderança, portanto, é o ingrediente mágico; é o catalizador.
Um exemplo de como criar condições aos atos de liderança, é de Håkan Forss, um consultor de Kanban da Suécia que foi influenciado pelo livro Toyota Kata, de Mike Rother. Forss sugeriu que no Kanban haveria três kata. Um dos kata seria o daily [reunião diária], o qual provoca eventos locais de kaizen.
Outro kata seria a Revisão das operações, que levaria a melhorias entre fluxos ou entre sistemas Kanban; e um terceiro kata que seria a Relação entre um superior e um subordinado, em que o mais sênior ensina o mais inexperiente através de perguntas como: Nosso sistema está funcionando bem? Temos as políticas corretas? Estamos colhendo as métricas certas? Visualizamos o que deve ser visualizado? Essas perguntas têm por objetivo ajudar a pessoa menos experiente a entender o mundo em que vivemos para que possa mudá-lo e melhorá-lo.
InfoQ Brasil: A comunidade está se acostumando com o termo Kanban Master?
David: Não, e estamos desencorajando a ideia de um Kanban Master (nos moldes do Scrum Master). Acredito que haja valor, contudo, para um Coach. Trata-se de um papel diferente do que estamos acostumados a ver em relação a coaches ágeis; estes estão comumente ligados a uma equipe e estão presentes todos os dias. Vemos comumente que os coaches de Kanban ficam com as equipes apenas de dois a três dias por mês, em geral discutindo sobre políticas explícitas do sistema, e sobre a visualização da cadeia de valor e métricas. Para essas atividades não é necessário que o coach esteja presente todos os dias do mês.
InfoQ Brasil: Recentemente a InfoQ norte-americana e brasileira publicaram artigos sobre o Kanban ser o próximo passo depois do Scrum. O que você acha sobre esse tema?
David: Se o artigo estiver falando sobre a evolução do mercado ou se vemos o Kanban se tornar o próximo processo importante no mercado de software, então considero que a afirmação do artigo está correta. Há muitas evidências de que o momento está muito positivo para o Kanban. Temos uma grande demanda por treinamentos, coaching, consultoria, bem como como jogos e simuladores para Kanban. De uma perspectiva de mercado, o Kanban se desenvolve para ser o próximo grande ator. Basta lembrar que já tivemos CMMI, RUP, XP e Scrum. O Kanban é o próximo nesta sucessão.
Em contrapartida, se o artigo insinua que as pessoas devam adotar o Scrum para depois adotar o Kanban, então considero a ideia completamente equivocada. O Scrum é de difícil adoção para muitas organizações e trata-se de uma opção errada, muitas vezes, para determinadas culturas organizacionais, de forma que as pessoas acabam resistindo à sua adoção.
O Kanban, ao contrário, foi projetado para facilitar a adoção, começando com o processo que se aplica atualmente, sendo uma alternativa ao Scrum. No caso de equipes que já utilizam Scrum e sentem a necessidade de melhorarem ainda mais, talvez a adição do Kanban sobre o Scrum seja uma boa ideia. Já se não estão usando Scrum, seria aconselhável que pensassem no Kanban como uma abordagem a ser ser adotada imediatamente.