Cuidado com Lean e o excesso de "Keep It Simple, Stupid"! (ou "Não confunda Lean Thinking com Lean Startup")

Quando ouvi falar em "Lean", pela primeira vez, em alguma conversa qualquer, o foco da discussão era no Produto Mínimo Viável (MVP - Minimum Viable Product) - a importância de fazer um produto simples, com o mínimo de esforço e tempo, agregando o máximo de valor. Em conversas posteriores, com outras pessoas, o foco também estava no MVP. Em um tom de utopia, quando surgia o tópico de Lean Thinking, as pessoas discutiam sobre maneiras de minimizar ao máximo o trabalho de desenvolvimento. Foi aí que fui contaminado (por pouco tempo) pela idéia de reduzir simplificar o valor.

O problema nestas discussões é que focar em MVP não é um princípio de Lean Thinking, mas sim de Lean Startup! E a situação se agrava quando não se está seguindo princípios de Lean Startup nem de Lean Thinking.

Não são raras as situações em que acabamos tirando valor de um produto em nome da do mínimo viável. Deixamos de lado o valor em nome do tempo e esforço
(Figura retirada do post "Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable" de Henrik Kniberg)

Em Lean Startup, o foco é, realmente, no MVP, objetivando a criação de protótipos de maneira rápida, para validação junto ao mercado, levando a uma rápida evolução deste produto.

O Lean Thinking - Pensamento Lean - envolve uma série de princípios, valores e práticas que objetivam o entendimento do valor do produto, e suas dinâmicas - o processo (ou linha) de produção - eliminando qualquer esforço e tempo que não agreguem valor ao produto, buscando a perfeição.

Lean Startup tem como foco o produto, enquanto que Lean Thinking foca na linha de produção

A falta de conhecimento dos valores de Pensamento Lean, misturado a idéias de Lean Startup, gera uma série de propagandas enganosas, que seduzem as pessoas através do foco em produto mínimo e menor esforço. Surge, então, o pensamento distorcido com base nestes dois elementos, resultando em baixo valor em nome da economia de trabalho e tempo e sem melhorias no processo de produção como um todo.

Muito cuidado ao tentarem apenas simplificar o seu trabalhos em projetos, pensando apenas no produto em si. O resultado será convertido em desperdício e frustração. Convido vocês a estudar Lean Thinking. Um bom começo é o livro Tudo que sei sobre lean aprendi no 1º ano da escola, de Robert O. Martichenko.

O livro introduz de maneira simples e muito divertida o pensamento Lean, além de abordar algumas das práticas e princípios por trás dos valores propostos.

Conhecendo melhor os valores do pensamento Lean, você entenderá que menor esforço é apenas o começo, fazendo você refletir não apenas no produto em si, mas em todos os elementos que rodeiam o produto. Aí, então você poderá dizer que PENSA Lean. Vamos começar?

"Desmistificando Pair Programming e TDD" para leigos

Quando eXtreme Programming (XP) foi apresentado ao mundo, uma série de práticas foram propostas para aplicabilidade dos valores e princípios básicos por trás desta metodologia ágil.

Algumas práticas são muito consolidadas na cultura de empresas, tais como entrega frequente de software funcionando (me corrijam, se estou errado, mas nunca vi ninguém defendendo entregas menos frequentes, nem mesmo em times e organizações com cultura waterfall).

Outras práticas, no entanto, ainda encontram obstáculos para se tornarem definitivas em times que almejam se tornar verdadeiramente ágeis. Em minha trajetória, observei duas práticas muito negligenciadas (por mim inclusive): Pair Programming (PP) e Test-Driven Development (TDD).

As justificativas para deixar essas duas práticas de lado apontam sempre para uma dimensão: tempo.

Muitas pessoas acreditam que Agilidade implica em Correria, levando a crer que, deixando pair-programming e TDD de lado, poderão produzir mais, em menos tempo. Após uma breve análise, encontrei nos princípios do Manifesto Ágil uma possível causa desta deturpação:
 "Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos"

"Frequência" não significa "Intensidade"! Abrindo mão de PP e TDD, é possível, mas pouco provável, que você possa entregar mais, porém deixará de lado a qualidade - um dos princípios de XP - e tem como risco não ter um software funcionando (você já leu o Manifesto Ágil e seus princípios? Pois deveria).

Deve-se entregar, com frequência, software funcionando e de alta qualidade, e o tempo consumido em atividades de Pair-Programming e TDD sobre o trabalho como um todo é irrelevante, do ponto de vista ágil.

Se ainda assim, houver obstáculos com tempo (ex: prazos impostos por clientes), negocie o escopo do trabalho. No fim, um trabalho de qualidade, mesmo que com escopo reduzido, terá muito mais valor que um trabalho com escopo mais amplo, mas de menos qualidade.