[Off-Topic] Você não entende nada de Scrum

“E nem eu também. Mas continuo estudando :-P”

Meu estilo de pesquisa é bem Web-like, eu diria :-) Por exemplo, por alguma falha cósmica qualquer, somente esta semana eu resolvi ler sobre a origem do Scrum, a metodologia Ágil que acabou se tornando mais conhecida atualmente. Fiquei muito surpreso com o que encontrei.

Eu sempre defendo que as pessoas precisam pesquisar constantemente, obsessivamente e nunca aceitar nada sem argumentação. Todos nós já deveríamos saber que não existem balas-de-prata. Simplesmente citar alguém para justificar alguma coisa é uma falácia que eu não aceito , como já disse no meu artigo Obediência à Autoridade.

Ou seja, até mesmo para defender metodologias ágeis eu preciso de um argumento melhor do que dizer “o Kent Beck é fodão, o Kent Beck inventou o XP, portanto devo usar XP.” Ou algo como “a Toyota é fodona, a Toyota usa Lean, portanto devo usar Lean.” Isso não é argumento.

Fato: muitas empresas hoje dizem que usam Scrum, muitas pessoas dizem que entendem Scrum, mas eu apostaria muito dinheiro de que a maioria avassaladora não sabe mais do que Scrum-butt, ou o que nós chamaríamos, de forma bem brasileira, de “Scrum meia-boca”. Melhor do que nada, sim, mas bastante pobre frente ao nível de hiperprodutividade que o Scrum promete: 400% para mais.

David Hume disse:

Um homem sábio, portanto, tem crença proporcional às evidências.

O Princípio de Laplace (Pierre Simon Laplace) diz:

O peso da evidência para uma afirmação extraordinária deve ser proporcional à sua estranheza.

Carl Sagan popularizou:

Afirmações extraordinárias exigem evidências extraordinárias.

Dado que eu penso assim, preciso de muito mais. Posso até usar alguma coisa baseado na minha intuição de que funciona, mas isso não pode virar zona de conforto. Isso me levou a uma engenharia-reversa e a uma linha de pesquisa que já dura mais de um ano: dezenas de livros, dezenas de papers técnicos, pesquisa multidisciplinar entre história do gerenciamento, engenharia de produção, psicologia, sociologia e física.

É uma busca pelas raízes do que deveria constituir uma verdadeira “organização ágil”. Para mim, as metodologias ágeis são o estágio atual na evolução do gerenciamento de projetos, e ainda longe do último. Implementar uma metodologia ágil é um meio para chegar a algo maior, nunca o objetivo final.

Na realidade, os últimos meses foram apenas os mais constantes. Vale lembrar que me certifiquei como PMP em 2005 e naquela época já estudava PMBOK e OPM3. Dois anos antes minha linha de pesquisa era RUP, SW-CMM (antes de CMMi) e as fábricas de software indianas. Meu primeiro contato com metodologias ágeis foi em 2003, com uma introdução ao Extreme Programming, e nos anos 90 eu acompanhei a evolução de UML e RUP: Coad & Yourdon, Rumbaugh, Booch, Jacobson.

Essa introdução toda é uma mea-culpa em relação a palestras recentes que tenho dado, em especial o “Além do Caos: Pensamentos Aleatórios sobre Agilidade”. Foi a versão mais recente e mais ousada de uma série de palestras que ministrei durante todo o ano de 2009 em diversas cidades. Ficou claro que muita gente não tinha bagagem para acompanhar todos esses conceitos.

Nessa palestra eu ousei mencionar conceitos como:

• Teoria da Complexidade e Não-Linearidade
• Teoria do Caos (especificamente “Beira do Caos”)
• Teoria de Sistemas de Entropia
• Emergência e Auto-Organização
• Sistemas Complexos Adaptativos
• Evolução e Punctuated Equilibrium
• Teoria dos Jogos

Eu bem que tentei explicar cada um desses temas, mas descobri que palestras de menos de 1 hora são péssimas para expor conceitos tão densos ao mesmo tempo. Ainda vou encontrar um jeito melhor.

Cada um desses tópicos representa um ramo completo de pesquisa científica. E juro que não estou falando de pseudo-ciência, é pesquisa séria. Aliás, esses ramos são justamente a “resposta” para a pergunta: “como metodologias ágeis, se devidamente implementadas, levam equipes a um estágio de hiperprodutividade sustentável?”

Da primeira vez que mencionei “Auto-Organização” no começo de 2009, eu ouvi muitas pessoas literalmente “tirando sarro” do que eu disse. Alguns acharam que eu “inventei” esse conceito “estranho”. Infelizmente não sou tão inteligente assim :-) Por acaso cheguei às mesmas conclusões que os criadores do Scrum. Veja o Jeff Sutherland, co-criador do Scrum, listando ele mesmo alguns desses conceitos:

Esse trecho é da palestra Auto-Organização: o tempero secreto para melhorar sua equipe Scrum, que ele apresentou recentemente no Google Tech Talk.

Confesso que foi muito estranho ouvir essa reação, porque estou falando de gente que, teoricamente, deveria ser agilista, já que clama saber implementar Scrum. Por isso publiquei o artigo O Manifesto Ágil, ou como se tornar o Google, onde comecei a interpretar o que todos já deveriam ter memorizado: o Manifesto Ágil:

“As melhores arquiteturas, requerimentos, e designs emergem de equipes auto-organizadas.”

Sim, isto é um dos 12 princípios do Manifesto. Mas se você não entende o conceito científico de “emergência” e “auto-organização”, então você não entende o Manifesto e, portanto, terá muitos problemas em tentar ser Ágil.

Sabem do que mais? Ken Schwaber foi co-criador do Scrum, no meio dos anos 90, junto com Jeff Sutherland. Ele escreveu um paper formal apresentado no OOPSLA-95. Não consigo entender como alguém pode dizer que “sabe Scrum” e nunca ter lido esse paper. Nele, o Schwaber diz:

“Quanto mais próximo uma equipe de desenvolvimento operar da beira do caos , enquanto ainda mantendo ordem, mais competitivo e útil será o sistema resultante.”

Sutherland e Schwaber foram alguns dos primeiros ocidentais a entender e publicar sobre a enorme diferença entre processos Definidos (previsíveis) e processos Empíricos (imprevisíveis). Os japoneses já tinham chegado a isso com Deming anos antes.

Cascata, RUP e CMM são processos definidos. Scrum, XP e outras metodologias ágeis são processos mistos, entre definidos e empíricos. Esta é a primeira grande diferença que torna os dois grupos incomparáveis, e o Schwaber explica isso muito bem em Controlando o Caos: Vivendo na Beira, apresentado no OOPSLA-96.

Ainda hoje ouço alguém querer começar uma discussão do tipo “Scrum vs. XP”, “Scrum vs. Lean”, “Somar Scrum ao Kanban” ou “Somar Scrum ao CMMi”. É difícil não ficar frustrado com a futilidade dessas conversas, em que as pessoas discutem só o topo do iceberg e não chegam nem perto de tocar a base dos princípios que precedem cada um desses temas.

Nas palavras do co-criador do Scrum, Jeff Sutherland, de novembro de 2007:

Depois de pensar sobre os primórdios do Scrum, acho que a raiz tanto do Scrum quanto Lean são sistemas complexos adaptativos. Quando nós criamos Scrum nós não falamos sobre Lean, falamos sobre sistemas complexos adaptativos. Eu acho que Scrum e Lean são implementações complementares de maneiras de lidar com realidades físicas onde as coisas normalmente são não-lineares , não são simples e não são previsíveis.

O primeiro Scrum implementou todas as práticas que conhecemos do Scrum de hoje, mais tudo o que depois viria a se chamar de práticas de XP, mais um tempero secreto que cria equipes hiperprodutivas.

(…) Mas mais importante, nós capturamos o efeito de “punctuated equilibrium”, uma coisa que ainda estou para ver alguma equipe de Scrum conseguir. É um dos segredos de equipes hiperprodutivas. Antes de um desenvolvedor escolher uma tarefa em uma reunião de Scrum, a equipe inteira discute com ele se essa tarefa é o caminho mais rápido para uma funcionalidade visível ao usuário-final. Isso foi uma implementação sofisticada de auto-organização e desenvolvimento “test-first”.

Engraçado é que, como eu disse antes, só li essa descrição da história do Scrum esta semana. Cheguei aos mesmos temas de Sistemas Complexos Adaptativos, Punctuated Equilibrium e os outros que listei acima por caminhos diferentes.

Eu já conhecia as novidades de teoria de redes de livre escala, que deram origem à minha palestra “Matando a Média” de 2008. E, lendo e relendo o Manifesto Ágil, me deparei com a palavra auto-organização. A soma dessas duas coisas levou a dezenas de leituras que culminaram em Sistemas Complexos Adaptativos. É um caminho de pesquisa que parece meio inevitável, e parece que Sutherland e Schwaber chegaram à mesma conclusão mais de 15 anos atrás.

E mais do que isso, o Sutherland, também diz o seguinte a respeito da origem do Scrum:

A primeira equipe de Scrum foi criada diretamente de um paper que é leitura obrigatória para qualquer praticante de Scrum. Ele explica como configurar equipes auto-organizadas e claramente delineira o papel da gerência no processo.

Takeuchi and Nonaka. The New New Product Development Game. Harvard Business Review, 1986

Um paper mais longo que vai mais a fundo, a partir de um livro que já saiu de circulação. Alguns podem achar mais fácil de ler.

Ken-ichi Imai, Ikujiro Nonaka, and Hirotaka Takeuchi. Managing the New Product Development Process: How Japanese Companies Learn and Unlearn.

Hirotaka Takeuchi e Ikujiro Nonaka são professores japoneses também conhecidos por suas pesquisas em Gestão do Conhecimento. O paper na Harvard Business que o Sutherland menciona custa meros USD 6,50. Acabei de comprar, e é curioso que a própria analogia dos “Scrums” do “Rugby” já esteja explicada e nomeada ali. Ou seja, o nome “Scrum” vem de Takeuchi e Nonaka.

Mais do que isso, eles já explicam nesse paper o que é e como funciona o conceito de Auto-Organização. Também explicam o estilo sequencial (tipo A) e as fases de desenvolvimento que se sobrepõem (tipos B e C). O Sutherland costuma falar de equipes hiperprodutivas como Scrum Tipo C.

O que Takeuchi e Nonaka explicam em detalhes nesses papers é o seguinte:

A partir de entrevistas com membros de organizações, do CEO a jovens engenheiros, aprendemos que empresas líderes demonstram 6 características no gerenciamento dos processos de novos produtos:

• Instabilidade Interna
• Equipes de projetos auto-organizados
• Fases de desenvolvimento que se sobrepõe
• “Múltiplo-aprendizado”
• Controle sutil
• Transferência organizacional de conhecimento

Mais uma vez, cada um desses itens é tema para um ramo inteiro de pesquisa, então não tente extrair sentido apenas dessas poucas palavras. O objetivo aqui é só dar um “gostinho”. Compre o paper e leia mais sobre o trabalho dos dois, especialmente sobre Gestão do Conhecimento, que é um pouco diferente do que a maioria das empresas entende por conhecimento (pra variar).

Outra coisa que alguns podem não saber:

“No mesmo ano (1995), Sutherland deu suporte para o desenvolvimento do Extreme Programming, ao dar a Kent Beck toda a informação de bastidores da criação do Scrum e o resultado de dois anos de desenvolvimento de produto com o processo Scrum de 1993-95. As práticas de engenharia de XP evoluíram junto com o Scrum e os dois processos de desenvolvimento Ágil trabalham bem juntos. Scrum e XP são os processos Ágeis mais usados pelo mundo e seus criadores são signatários do Manifesto Ágil.”

Isso está no Scrum Papers que, obviamente, todo agilista deveria ler. O ponto é: Scrum se funda nos princípios japoneses que deram origem ao Lean, e ao mesmo tempo serviu de inspiração para a criação de XP. Não existe conflito entre Lean, Scrum e XP. Eles têm raízes semelhantes! Por isso é importante estudar os princípios mais do que só as práticas.

Cuidado: eu não estou citando tudo isso como forma de “provar” meu ponto. Estou citando estudos que por acaso coincidiram com o que eu comecei fazendo sozinho. É tudo material de pesquisa que não deve ser usado como dogmatização, mas como referência para pesquisa.

Para fechar, gosto de mencionar Mary Poppendieck. Entre os agilistas, ela e Tom foram os que resolveram seguir a linha mais purista e escreveram Lean Software Development. Com essa explicação deve ficar claro que o que Mary/Tom e Sutherland/Schwaber dizem é complementar e totalmente compatível, cada um com sua bagagem de experiências. E, de Mary, acho que este artigo sobre ‘Culpa’ é importante de ler:

O propósito do que se tornou a estrutura organizacional de hoje era claro: a assinalação de responsabilidade permitiria “detecção imediata de negligências de trabalho … e apontar o delinquente.”

(…) Existe uma coisa chamada trabalho padrão , mas padrões deveriam mudar constantemente. Em vez disso, se você pensar no padrão como o melhor que você pode fazer, está tudo acabado. O trabalho padrão é apenas uma base para fazer mais kaizen. É kai-aku [mudança para pior] se as coisas piorarem em relação a agora, e é kai-zen [mudança para melhor] se as coisas melhorarem. Padrões são ditados arbitrariamente por humanos, então como elas não deveriam mudar?

Esse último parágrafo é, novamente, para aqueles que ainda acham que existem balas-de-prata, que existe algum corpo de práticas inabaláveis (CMMI, ITIL, RUP, etc) onde basta “seguir a receita à risca” que tudo vai, magicamente, dar certo. Afinal, são “padrões de mercado”.

Bullshit! Faça sua lição de casa: continuem pesquisando!

PS: Leia todos os meus artigos da seção Off-Topic para mais assuntos relacionados.