Não Vá Atrás da Cascata
Mais e mais eu percebo que, poderia criar um sistema, que parecesse um robô, poderia coordenar pensadores independentes com um retorno sobre seu ambiente, os que tivessem mais performance poderia ser efetuado.
Simplificando o fluxo de informações entre as “pernas” de um grupo, nós poderíamos alcançar eficiências nunca alcançadas.
Minha conversa com Rodney Brooks foi há mais de duas décadas. Por anos ele foi a cabeça da robótica e inteligência artificial do MIT, e daquele robô aranha que eu encontrei, apelidado de “Genghis Khan”, que agora está como um item de colecionador na Smithsonian.
Você provavelmente deve conhecer a companhia de Brooks, iRobot, o qual faz o Roomba limpador a vácuo que usa a mesma inteligência adaptada para limpar o andar que o Genghis Khan utilizava para me perseguir no meu escritório.
A última inovação da Rethink Robotics, o robô Baxter, pode trabalhar colaborativamente com humanos em um espaço comum.
Eu fui inspirado pelo trabalho do Brooks. Com isso, em 1993 eu levei as ideias comigo para uma companhia chamada Easel, onde eu fui contratado como VP da Object Technology.
Os executivos da Easel queriam meu time para desenvolver uma nova linha de produtos em seis meses que teriam como objetivo os seus maiores consumidores, tais como a Ford Motor Company, a qual utiliza seus softwares para modelar e construir aplicações internas.
Eu me sentei com o meu time de desenvolvedor e falei para eles que não poderiam utilizar a mesma maneira de trabalho para desenvolver softwares.
A metodologia que utilizávamos é o método Cascata. Tudo era descrito no gráfico de Gantt, toda tarefa era medida em horas e identificada por cores em uma página que parecia uma cascata. Aqueles gráficos eram lindos e precisos. Eles foram completamente fabricados.
Na Easel, eu sabia que a metodologia Cascata poderia nos atrasar em meses ou anos do nosso prazo. Tínhamos que fazer algo completamente diferente. Eu fui ao CEO e disse a ele que nós não usaríamos o gráfico de Gantt. Ele ficou chocado e quis saber o motivo.
“Quantos gráficos de Gantt você viu durante a sua carreira?”, perguntei a ele.
“Centenas”, disse ele.
“Quantos deles funcionaram?”
Ele parou e disse. “Nenhum.”
Foi então que eu disse a ele, você verá o software pronto dentro do prazo ao invés de passarmos do prazo utilizando o gráfico de Gantt. Ele poderia testar o processo para ver se estávamos no caminho certo. Mas tínhamos que testar para saber se funcionaria.
Meu time e eu gastou várias semanas lendo centenas de artigos e livros para organizar o time e o produto em desenvolvimento. Então um dia, um dos desenvolvedores veio com um artigo de Harvard Business Review de 1986, escrito por dois professores de japoneses, Hirotaka Takeuchi e Ikujiro Nonaka.
O artigo tem o título “The New New Product Development Game.” Takeuchi e Nonaka procurou os times mais produtivos pelo mundo e companhias inovadoras: Honda, Fuji-Xerox, 3M, Hewlett-Packard e outros.
Eles argumentavam que a velha maneira de desenvolver produtos, tipificada por sistema de Planejamento e Programa de Fases da NASA, um sistema de Cascata, que fundamentalmente é falho.
Com isso, as empresas estudadas, utilizavam um processo de desenvolvimento contínuo que era mais rápido e flexível. Os times eram entrosados. Os times tinham autonomia.
Eles foram autorizados a fazer suas próprias decisões. E tinham um propósito transcendente. Eles alcançaram algo maior que esperavam. Organizadores não mandavam.
Ao invés disso, executivos eram líderes facilitadores que focavam na remoção dos obstáculos do seu time, sendo assim, não falavam como produzir o produto.
Os professores japoneses compararam os times com um time de rugby que agem mesmo que esteja em um scrum (corrida)… a bola é passada pelo time e correm juntos no campo.
O artigo de Takeuchi e Nonaka abriu-me a mente quando foi publicado pela primeira vez, mas isto foi sete anos antes de lermos o artigo na Easel. Todos ficaram admirado, mas ninguém fez nada com essa informação.
O gerente americano médio não viu sentido nisso, mesmo a Toyota crescendo rápido no mercado utilizando essa abordagem. Na Easel nós não tínhamos nada a perder.
Nós decidimos tentar, mesmo que o artigo focasse na manufatura e não no desenvolvimento de software. Eu achava que as ideias eram fundamentais, um processo descritivo de como humanos trabalham melhor juntos em qualquer empreendimento.
Ele me fez voltar em todos os experimentos que eu fiz, voltei ao meu primeiro emprego no setor privado a MidContinet.
Esse foi o nascimento formal do “Scrum”. Nós entregamos o produto a Easel dentro do planejamento de seis meses, abaixo do orçamento, e com poucos bugs comparado com outras entregas.
Eu fiquei entusiasmado com as possibilidades dessa nova forma de organizar projetos, e meus trabalhos futuros focou no refinamento do Scrum para companhias.
Em 1995 eu apresentei um artigo com Ken Schwaber, chamado “SCRUM Development Process,” o qual codificou as práticas na conferência de pesquisa na Association for Computing Machinery. Desde então aprimoramos a ideia, mas os princípios fundamentais são os mesmos, e as companhias que adotaram o processo viram os benefícios imediatos.
👍 Scrum. A Arte de Fazer o Dobro do Trabalho na Metade do Tempo
Seja o primeiro a comentar!