Slide 26 - Redundância e falhas

O jeito Toyota sempre permitiu redundância e falhas. Processos emergentes, como a evolução biológica, irá produzir falhas. Assim, é melhor que as falhas aconteçam logo e com freqüência. E isto é ótimo, sabe? As pessoas perguntam: “O Scrum pode ter alguma falha?”. Bem, ele raramente falha. Mas quando isto acontece é normalmente nas duas primeiras semanas. Isto é apenas um ruído na lucratividade de muitas empresas. As pessoas esperam meses antes de escrever sua primeira linha de código se elas constroem a grande especificação e o grande plano. Duas semanas é como... sequer são notadas.

Uma tentativa de planejamento racional e eficiente para soluções emergentes causará desastres ferroviários. É por isso que Capers Jones apontou em 1993 que: 65% de grandes projetos com mais de um milhão de linhas de código falharão. Em 1999, o DOD (Departamento de Defesa Americano) havia feito uma boa análise de seus projetos: taxa de 75% de falhas. E em 2001, em mais de mil casos de desenvolvimento de sistemas no Reino Unido, a taxa de falhas foi de 87%. Desta forma, a taxa de falha é extremamente alta no grande projeto e no grande plano. Esta é mais uma razão para parar com isto. Se fazer algo seis vezes mais rápido, ganhando mais dinheiro e tendo mais diversão não o motiva, talvez altas taxas de desastre possa fazê-lo (risos). E caso contrário (risos) você precisa dos alcoólicos anônimos.

So, the Toyota way allows for redundancy and failures. Emergent processes, like biological evolution, will produce failures. So you wanna fail early and often. And it's great, you know? People ask “does Scrum ever fail?” Well, it rarely fails. But when it does, it usually happens in the first two weeks. That's just noise in the P&L of most companies. People wait for months before they write the first line of code if they build the big spec and the big plan. Two weeks is like... not even noticed.

Rational and efficient approaches to emergent solutions will cause train wrecks. It's why Capers Jones pointed out in 1993: 65% of large projects over a million lines of code fail. By 1999 the DOD had really done a good analysis on their projects, failure rate 75%. And in 2001, out of over a thousand UK systems development efforts, 87%. So, the failure rate is extremely high on the big project and the big plan. So that's another reason to stop doing it. If doing it six times faster, and making more money and having more fun doesn't motivate you, maybe high disaster failure rates will. (laughs) And if that won't (laughs) you need alcoholics anonymous.