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

2009 December 10, 23:23 h

“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. Eu posso até usar alguma coisa baseado na minha intuição de que funciona, mas isso não pode virar uma zona de conforto. Isso me levou a uma engenharia-reversa e uma linha de pesquisa que já dura mais de um ano, representou dezenas de livros, dezenas de papers técnicos, pesquisas multi-disciplinares entre história do gerenciamento, engenharia de produção, psicologia, sociologia, física, etc. É uma busca pelas raízes do que deveria constituir uma verdadeira “organização ágil”. Para mim, as metodologias ágeis são o atual estágio na evolução de gerenciamento de projetos, mas não é o último! Ou seja, implementar uma metodologia ágil não é um objetivo, é um meio.

E na realidade, os últimos meses foram apenas os mais constantes. Não esquecendo que eu me certifiquei como PMP em 2005 e naquela época eu já estudei PMBOK e OPM3. Dois anos antes minha linha de pesquisa era sobre 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. Nos anos 90 eu acompanhei a evolução de UML e RUP. Coad & Yourdon, Rumbaugh, Booch, Jacobson, etc.

Essa introdução toda é na verdade uma mea-culpa em relação a palestras recentes que eu tenho dado, em especial o Além do Caos: Pensamentos Aleatórios sobre Agilidade. Ela é 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. Está claro que muitas pessoas não tinham bagagem para entender todos esses conceitos.

Nessa palestra eu ousei mencionar conceitos como:

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, estou falando de pesquisa séria. Aliás, esses ramos são justamente a “resposta” para a pergunta: “como metodologias ágeis – se devidamente implementadas – efetivamente 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 pois estou falando de pessoas que – teoricamente – deveriam ser agilistas já que clamam saber implementar Scrum. Por isso eu 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.”

O Sutherland e Schwaber foram alguns dos primeiros ocidentais a entender e publicar sobre a enorme diferença que existe entre processos Definidos (previsíveis) e processos Empíricos (imprevisíveis). Os japoneses já tinham entendido isso junto com Deming anos antes. Metodologias de Cascata, RUP, 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. O Schwaber explica isso muito bem em Controlando o Caos: Vivendo na Beira, apresentado no OOPSLA-96.

Também recentemente, às vezes ainda ouço alguém querer começar uma discussão do tipo “Scrum vs. XP” ou “Scrum vs. Lean” ou “Somar Scrum ao Kanban” ou “Somar Scrum ao CMMi” e é difícil não ficar frustrado com a futilidade dessas discussões, onde as pessoas discutem apenas 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 raíz 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 o 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, eu apenas li essa descrição da história do Scrum esta semana. Eu acabei chegando nos mesmos temas de Sistemas Complexos Adaptativos, Punctuated Equilibrium e os outros temas que listei acima, por caminhos diferentes. Eu já conhecia as novidades de teoria de redes de livre escala, que deu origem à minha palestra “Matando a Média” de 2008. Finalmente, 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 culminou 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. Eu acabei de comprar e é muito interessante que a analogia com “Scrums” de “Rugby” está explicado e nomeado nesse paper. Ou seja, o nome “Scrum” origina de Takeuchi e Nonaka. Mais do que isso, eles já explicam nesse paper o que é e como funciona esse conceito de Auto-Organização. Eles também explicam o estilo sequencial (tipo A) e fases de desenvolvimento que se sobrepõe (tipos B e C). O Sutherland comumente fala 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 ítens é tema para um ramo inteiro de pesquisas, por isso recomendo que não se tente, superficialmente, retirar qualquer sentido apenas dessas poucas palavras. O objetivo aqui é apenas 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 sobre 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, se você é um agilista, deveria ler. O ponto é: Scrum é fundado nos princípios japoneses que deram origem ao Lean, ao mesmo tempo que serviu de inspiração para a criação de XP. Ou seja, não existe conflito entre Lean, Scrum, XP. Eles tem raízes semelhantes! Por isso é importante estudar os princípios mais do que somente 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.

Finalmente, para fechar, gosto de mencionar Mary Poppendieck. Das agilistas, ela e Tom, foram os que resolveram ir na linha mais purista e escreveram Lean Software Development. Com essa explicação deve ficar claro que o que a Mary/Tom e o Sutherland/Schwaber dizem não é contraditório, não é competitivo, são apenas complementares e totalmente compatíveis, 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.

tags: off-topic principles career management agile carreira

Comments

comentários deste blog disponibilizados por Disqus