Há 30 anos, a indústria de tecnologia tentou importar as práticas Lean – falhou. Em vez de “melhoria contínua”, o progresso parou. O Agile é incompatível com a pesquisa, o design e o desenvolvimento escalável de UX. Sempre será. É hora de criar um novo padrão operacional.

Como as startups se concentram na “eficiência operacional”, vamos enfatizar que a eficiência é uma maneira de trabalhar, não o número de funcionários.

O desenvolvimento ágil tem sido o princípio operacional número 1 da tecnologia por mais de 20 anos, sem controle, sem questionamento. No entanto, tem falhas fundamentais que têm nos visto o tempo todo.

Falha no 1:

Os seres humanos não são máquinas.

Falha no 2:

O design não é inventário.

O produto não pode ser definido pelo que pode ser realizado por um número arbitrário de pessoas de habilidade arbitrária e experiência em um sprint de duas semanas.

Vamos dar uma olhada para trás em como nos colocamos em:

• 2001 — Ágil
• 1995 — Scrum
• 1988 — Lean (tradução)
• 1960 – Sistema Toyota de Produção (TPS)

A partir do início

O TPS evoluiu por décadas, dos anos 40 até os anos 70, permitindo que a Toyota alcançasse e mantivesse sua posição dominante entre os fabricantes mundiais de automóveis. Esses começos brilhantes se concentraram em eliminar muda mudas (desperdício), mura (inconsistência) e muri (sobrecarburada).

A eliminação dos resíduos foi a mais documentada. Entre os oito tipos de resíduos, os mais prejudiciais foram o excesso de estoque – tanto o produto acabado quanto as matérias-primas, e as máquinas ociosas. Em outras palavras – coisas que você gastou dinheiro nisso não está ganhando dinheiro. As soluções da Toyota eram de natureza logística e passaram a ser conhecidas como “fabricação just-in-time”.

“Recebe materiais a tempo de a linha de montagem processá-los a tempo para que o produto acabado atenda à demanda do cliente.”

Um parceiro de excelência para a TPS foi o “Toainpal da Toyota”. Essa filosofia exigia a melhoria contínua, incluindo a superação de desafios para uma visão de longo prazo, kaizen (inovando em operações) e meu favorito pessoal, genchi genbutsu. Significando “lugar de verdade, coisa real”, esse princípio significava “ir e ver por si mesmo”, tomar decisões de acordo. Também incentivou uma abordagem de baixo para cima para melhorar, reunindo insights de todos os funcionários, independentemente do seu nível.

A América trabalhou sua magia e transformou o Toyota Way no equivalente a Cup Noodles. Talvez eu esteja sendo injusto. A fabricação just-in-time era bem aplicada nos Estados Unidos para… a fabricação. Foi rebatizado como Lean em um artigo de 1988, “Triunfo do Sistema de Produção Lean” – a linhagem era clara.

Lean e seus antepassados são perfeitos para a fabricação de bens físicos, particularmente quando há um mercado estabelecido e um produto maduro. Baseia-se na previsibilidade da demanda e da cadeia de suprimentos. Quando se trata de criar um novo produto, os fabricantes contaram com diferentes processos em seus departamentos de P&D. Quer se tratava de Genentech desenvolvendo insulina sintética ou a Proctor & Gamble desenvolvendo o Swiffer, o processo foi longo e bastante linear. Estes envolveram pesquisa profunda e análise de mercado antes do desenvolvimento de produtos.

The Waterfall ScapegoatTradução

A crescente indústria de software seguiu em grande parte esses processos; aplicada a produtos digitais, eles ficaram conhecidos como metodologia Waterfall. O termo Cachoeira tornou-se um catch-all para descrever um processo de desenvolvimento linear que culmina em uma liberação de produto totalmente realizada. A crítica legítima é que o grande lançamento de produto caro ainda pode ser um indício. Como tal, a cachoeira é usada como uma folha para argumentar que a iteração, o teste e a reação ao mercado são necessários em um prazo mais curto.

Na década de 1990, os profissionais da indústria de tecnologia exploraram maneiras de aplicar o Lean aos produtos digitais. Infelizmente, desde o início, eles diagnosticaram erroneamente o problema. O tempo de lançamento no mercado é importante, mas eu argumentaria mais do que do ponto de vista do fluxo de caixa, especialmente para as startups. Os proponentes magros jogaram fora o bebê com a água do banho. Observe como o Scrum e a literatura ágil fazem pouca ou nenhuma menção de pesquisa ou estratégia. O design teve uma má reputação como a fase de perda de tempo longa da Cachoeira. Quadros enxutos são tudo sobre build e release.

Por volta dessa época, havia um Kaiju vs. Luta estilo Mecha entre os proponentes do Lean e aqueles que estavam praticando o desenvolvimento da Cachoeira. Tanto o monstro quanto o robô não consideraram as necessidades dos usuários e, em vez disso, pisaram neles e destruíram o mundo.

Qual é a diferença? Apenas o diagrama – Agile representando uma peça, Waterfall representando um todo.

Fonte: Medium | Publicado em Coletivo de UX