Sim, eu estou deliberadamente tentando lhe provocar. E sim, de uma forma muito específica, eu acredito que a última metade da questão é a verdade.
Isso pode ser supreendente já que LeanAgile parece ter se tornado uma palavra no mundo de desenvolvimento de software. Então, talvez alguns avisos foram dados.
Eu conheço Mary e Tom Poppendieck por mais de uma década. Nós éramos amigos e colegas no maior grupo de usuários do mundo - em Minneapolis. Tom foi meu aluno na University of St. Thomas (também em Minnesota, não - muito infortuna no inverno - nas Ilhas Virgens). Tom era um dos revisores técnicos do meu livro sobre objetos.
Exceto pelo fato de que o livro deles vendeu mais que o meu uns 100 pra 1 (e por isso nunca irei perdoá-los), eu só tenho respeito e admiração pelo seu conteúdo e idéias. O Livro deles é um discurso de mestres e deveria ser aprendido e aplicado pelos desenvolvedores de software do mundo todo. Incluindo, talvez, desenvolvedores ágeis.
Então qual é o problema?
ResumidamenteL Lean e Agile são baseados em visões fundamentalmente diferentes e portanto se encontrarão inevitavelmente em oposição nos pontos críticos.
Nos próximos parágrafos eu tentarei mostrar a visões opostas, ilustrar um ponto de conflito e então sugerir como os dois pontos podem ser reconciliados.
Visão do mundo Lean = Produção
Algumas citações do livro Lean oftware Developmente, An Agile Toolkit para introduzir minha declaração que a visão do Lean é uma visão de produção.
O prefácio de Jim Highsmith "... Mary e Tom Poppendieck levaram as práticas do lean industrial a um novo nível - eles nos ensinam como aplicá-las ao desenvolvimento de software." e "... fornece informação saudável sobre aplicação de técnicas lean da perspectiva industrial ao desenvolvimento de software."
Da página xxii da introdução, "Enquanto reconhecendo o perigo de aplica incorretamente metáforas, nós acreditamos que a indústria de desenvolvimento de software pode aprender muito examinando como as mudanças nas abordagens de desenvolvimento de produtos trouxeram melhoras ao processo de desenvolvimento de produtos."
Produção, vocabulário de processo e metáforas são presentes ao longo de todo o livro. Embora haja uma clara rejeição das idéias sobre produção do século 19 (ex: Tailorismo) há uma adoção igualmente clara dos modelos de produção destacados (ex: o modelo de produção Toyota)
Práticas ágeis especificas são avaliadas da perspectiva da contribuição para a produção. Se uma prática ágil específica é vista como estando em conflito com o modelo de processo de produção lean, esta prática deve ser modificada ou eliminada.
Lean não é apenas sobre processo. Por exemplo, dos sete princípios de Lean,
- Eliminar Desperdício
- Amplificar o aprendizado
- Decidir tão tarde quanto possível
- Entregar tão rápido quanto possível
- Fortalecer o time
- Construir integridade
- Ver o todo,
somente a primeira é inequivocadamente conectada ao processo de produção.
Estes princípios sugerem uma forma de transcender a visão de produção evidente em cada um do outros aspectos do Lean. Nós iremos retornar a esta possibilidade na última parte deste artigo.
Visão do Agile = Construção de Teoria
Eu tive o grande privilégio de ser associado com, e conto a mim mesmo como um do amigos da, maioria dos criadores e defensores da agilidade. Eu discuti a seguinte idéia sobre os fundamentos filosóficos do Agile e descobri que eles concordam. Somente um, Alistair Cockburn, colocou a idéia em papel.
Apândice B, páginas 227 a 239, do Agile Software Development de Cockburn contém um reprint de um artigo escrito por Peter Naur em 1985, entitulado "Programando como Construção de Teoria".
Naur argumenta que o ato de desenvolver software tem sido incorretamente tomado por um ato de produção - produção de "um programa e certos outros textos". Ele cita vários exemplos de inconsistência de dados empíricos com o modelo de produção de desenvolvimento; incluindo, o fato que documentação arbitrária e exatidão tem pouco, talvez nada, a ver com um entendimento de um programa para aqueles que não estão envolvidos em sua criação original.
Construir teoria, a la Naur, é o esforço individual e coletivo para:
- Entender o Mundo
- Entender como o software é formado pelo Mundo e como ele se integrará com este Mundo
- Entender a essência do software e como melhor articular (codificar) esta essência
- Entender se você alcançou os tres primeiros entendimentos corretamente.
As atividades observáveis assiciadas com a construção de teoria incluem contar muitas histórias, explorar idéias, tentar coisas para ver se elas funcionam, testar seu entendimento, popular seu espaço físico com lembretes evocativos de seu entendimento e fazer estas coisas interativamente em incrementos compreensivos e cada vez crescentes.
Parece muito com um ambiente ágil, mas lembra um pouco um ambiente de produção.
Esceto para citar as idéias de Ryle sobre posse de uma teoria, Naur não apresenta explicitamente um conjunto de princípios para construção da teorias. Se ele tivesse feito isso, esses princípios seriam consistentes com os valores do XP para Simplicidade, Comunicação, Coragem e Feedback.
Visões em conflito
Lean vê o desenvolvimento de software como um processo para sair de uma concepção para um produto. Ele quer otimizar o processo, mesmo que de uma forma radicalmente diferente e com valores radicalmente diferentes do tradicional (ex. Tailorismo) tentar uma otimização.
O Agile vê o desenvolvimento de software como um processo para construir uma teoria consensual do mundo: com um artefato sendo um produto - uma expressão - desta teoria.
Porque as visões fundamentais dos dois lados são dramaticamente diferentes, é inevitável que existam conflitos. Estes conflitos irão manifestar-se normalmente a nível de ferramentas e práticas.
Por exemplo: o product backlog.
Agile embasado na idéia de modularizar o trabalho em uma base de user stories. Uma user story é "algo que o cliente que que o sistema faça." (Kent Beck)
Estórias de usuaŕios (User stories) são originadas a partir do usuário, também chamado de, clientes ou negócio. Estórias podem ser produzidas muito mais rápido que implementadas, especialmente no começo de um grande projeto, ou quando o objetivo é "agilizar" uma corporação inteira.
Quase todos os projetos ágeis estabelecem um product backlog, um conjunto de estórias a serem implementadas. Este conjunto pode ser bem grande. Eu tenho visto projetos com um backlog de centenas de estórias.
Lean olha para o product backlog e vê 'inventário' e 'desperdício'. Mary Poppendieck sugere que o product backlog deveria ser eliminado ou, no mínimo limitado a um tamanho mais condizente com a velocidade dos times.
O Agile vê o product backlog como uma previsão de uma teoria emergente. Mesmo se esta previsão seja fisicamente manifestada como uma parede cheia de cartões de estórias, isso nào é um inventário! A cartas na parede servem como uma forma de memória externa, com cada cartão evocando (reavivando na mente) conversas detalhadas e entendimentos de como as coisas funcionam.
Agile funciona melhor quando há um grande product backlog e quando há uma grande quantidade de gordura na composição do backlog. Gordura resultante de conversas sobre a essência da estória; prioridade da estória; feedback dos desenvolvedores sobre estórias não compreendidas'estórias que acabaram sendo bem mai fácil ou difícil de desenvolver do que o esperado; estórias que tiveram de ser refatoradas para torná-las mais compreensíveis e mais rastreáveis para o desenvolvimento; e feedback da aceitação do usuário em relação às estórias completas.
Eventualmente, a gordura diminui e o product backlog se torna estável. A quantidade de novas estórias adicionadas é reduzida a poucas e a priorização de estórias muda somente nominalmente. Neste ponto se torna ainda mais tentador considerar o product backlog como um inventário.
Reista a tentação. O backlog ainda é uma manifestação física da teoria. Ele fornece o contexto absolutamente essencial para todo o trabalho de desenvolvimento sendo feito.
O backlog fornece o mesmo tipo de suporte crítico para o desenvolvimento de software que os editores de continuidade e conselheiros técnicos fornecem à produção de filmes. Quando a atenção está focada em uma única cena, é fácil esquecer que o herói estava vestindo uma camisa azul, não uma vermelha, no último frame da cena anterior. É fácil esquecer que você não pode ouvir uma explosão no espaço. Erros semelhantes ocorrem quando trabalhando na implementação de estórias e este é o contexto - o prodcut backlog - que fornece a continuidade e correção dos malentendidos da essência.
Em todos os projetos ágeis em que eu fui o coach, eu insisti em manter o product backlog na parede na forma de cartões de estórias adjacentes à informação de monitoração do sprint. As reuniões diárias (stand-up meetings) eram conduzidas com uma visão facilitada tanto das estórias de foco imediato quanto das estórias do product backlog. O product backlog era revisado e discutido em detalhes durante cada jogo de planejamento e cada retrospectiva - simplesmente para refrescar a memória de todos envolvidos com o estado de nossa teoria atual.
O ponto deste exemplo: sua visão necessáriamente colore sua interpretação das "coisas". Um simples artefato, como um product backlog, tem muitas realidades, propósitos,valores e funcionalidades diferentes, baseado na sua perspectiva do mundo. Neste caso a 'visão da produção' resulta em um ainterpretação que é atualmente prejudicial ao desenvolvimento ágil de software.
Eu sei que estou argumentando de forma geral e oferecendo apenas um único exemplo para suportar este argumento. Esta é uma questao de limitação de espaço, não falta de exemplos.
Reconciliação
Um casamento é pura felicidade - exceto pelos desentendimos, argumentos e objetivos conflitantes. Lean e Agile forma um belo casal. Tem certeza que este casamento pode ser salvo?
Claro que pode, mas há 3 pré-requisitos, uma para o Lean, uma para o Agile e um para ambos.
O Lean precisa tirar os "óculos de produção" e olhar para o Agile e elementos do processo de desenvolvimento ágil a partir de uma perspectiva holística que inclui todo os sete princípios do Lean. Se o product backlog for avaliado como mais do que o princípio de 'eliminar desperdício', suas contribuições para "amplificar o aprendizado, decidir tão tarde quanto possível, fortalecer o time, construir integridade e ver o todo" seriam óbvias.
Os praticantes de Agile devem, ironicamente, fazer a mesma coisa. Quando você ouvir praticantes de agile falarem sobre o que eles fazem - seu vocabulário, metáforas e implementação de práticas refletem a perspectiva do agile como um modo de produção alternativa. Pergunte para a maioria dos agilistas sobre Naur e construção de teoria e você receberá um olhar vazio.
Tanto o Lean quanto o Agile devem parar de aplicar, de forma literal, as ferramentas e práticas. Ferramentas e práticas não são nada mais que expressões de valores, princípios e filosofia. Eles não as únicas expressões possíveis e podem nem ser as melhores expressões. Nenhum lado será capaz de perceber o aviso de seus fundadores para "usar, adaptar e transcender" até e a não ser que eles venham a entender porque as práticas e ferramentas são o que são.
AgiLean foi um caso de amor a primeira vista. A lua de mel foi um excitante intervalo para encontrar novas idéias e mesclar idéias. Mas este tempo já é passado. Se este casamento vai sobreviver, ambas as partes precisam deixar para trás suas atrações superficiais - porque este tipo de conflito irá inevitavelmente surgir.