O que é Scrum e como funciona na prática

Scrum é um framework para construir produtos em ciclos curtos, chamados Sprints, em que um time pequeno e multidisciplinar entrega algo pronto a cada uma a quatro semanas. Ele não é uma metodologia com etapas fixas e não diz como fazer o trabalho. Define quem responde pelo quê, quais conversas precisam acontecer e com que frequência.

É uma distinção que parece pequena e não é. A maior parte das implantações que dão errado trata o Scrum como um processo a seguir, quando ele é um conjunto de restrições que força a organização a decidir mais rápido e com mais gente sabendo o que está acontecendo.

Quem já conduziu projeto reconhece o padrão: a organização adota os eventos, mantém o quadro atualizado, faz a retrospectiva, e continua decidindo prioridade do mesmo jeito de antes. O cerimonial entrou. A forma de decidir, não.

O que o Scrum tentou resolver

Levantar requisito, planejar, montar cronograma, controlar custo, desenvolver, testar, validar e entregar. Nessa ordem, uma vez só.

Esse modelo funciona quando o escopo é conhecido e estável. O problema é que software quase nunca é assim. O cliente descobre o que quer usando o produto, e a descoberta chega depois que o cronograma já foi aprovado.

O resultado é conhecido de quem viveu: o projeto entrega o que foi especificado e mesmo assim decepciona.

O Scrum inverte a aposta. Em vez de tentar acertar a especificação no início, ele encurta o intervalo entre decidir e ver o resultado. Erra igual, mas erra pequeno e cedo.

De onde o Scrum veio

A origem não é de software. Em 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaram na Harvard Business Review o artigo "The New New Product Development Game", estudando como fabricantes japoneses de automóveis e bens de consumo desenvolviam produtos. Notaram que times pequenos e multidisciplinares, trabalhando em fases sobrepostas em vez de sequenciais, produziam resultado melhor.

Eles compararam esse time ao scrum do rugby, a formação em que o grupo avança junto, empurrando na mesma direção.

Em 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna implementaram essas ideias em software na Easel Corporation. Ken Schwaber e Sutherland apresentaram o Scrum formalmente na conferência OOPSLA de 1995, e desde então mantêm o Guia do Scrum, o documento oficial que define o framework.

Vale saber disso por um motivo prático: o Scrum não foi desenhado para acelerar programação. Foi desenhado para lidar com incerteza. Quando alguém tenta usá-lo em trabalho previsível e repetitivo, a frustração não é falha de implantação, é uso fora do propósito.

Quem responde pelo quê em um Scrum Team

São três responsabilidades, e nenhuma delas é chefe das outras.

O Product Owner responde pelo valor do produto. Mantém o Product Backlog, decide prioridade e traduz necessidade de negócio em algo que o time consiga construir. É o papel mais difícil de preencher bem, porque exige alguém com autoridade real de decisão. Product Owner que precisa pedir aprovação para priorizar não é Product Owner, é secretário do backlog.

O Scrum Master responde pela eficácia do time. Remove impedimento, protege a Sprint de interrupção e ajuda a organização a entender como o framework funciona. Não distribui tarefa, não define prioridade e não avalia desempenho.

Os Developers constroem o incremento. O termo cobre todos os perfis necessários, não só quem escreve código: análise, arquitetura, teste, documentação. O time decide sozinho como fazer o trabalho e quanto cabe em uma Sprint.

O Guia de 2020 fala em tipicamente dez pessoas ou menos, contando os três. Se você ainda encontra "três a nove", é material anterior a 2020.

Como funciona uma Sprint

A Sprint é um intervalo de tempo fixo, de uma a quatro semanas, e é dentro dela que todo o resto acontece.

Começa com o Sprint Planning. O Product Owner traz o backlog priorizado, os Developers quebram em tarefas e o time combina o que consegue terminar. Sai dessa reunião o Sprint Backlog e uma meta, o Sprint Goal, que é o que dá sentido ao conjunto.

Durante a Sprint acontece a Daily, de quinze minutos, todo dia. Não é reunião de status para o gestor. É o time se coordenando: o que mudou, o que travou, o que precisa de ajuda hoje.

No fim, a Sprint Review mostra o incremento para quem tem interesse no produto. Não é teste e não é aprovação formal. É a conversa em que o negócio vê o que existe e reage, e é dali que sai boa parte do próximo backlog.

Depois vem a Sprint Retrospective, só com o time, sobre o processo e não sobre o produto. O que funcionou, o que atrapalhou, o que muda na próxima. É o evento que as organizações cortam primeiro quando estão com pressa, e é justamente o que faz o time melhorar.

O refinamento do backlog não é um evento. É uma atividade contínua, que acontece ao longo da Sprint sempre que um item precisa ficar claro antes de entrar na próxima. Em material antigo isso aparece como uma reunião chamada grooming.

O que o Scrum chama de artefato

São três, e cada um carrega um compromisso.

O Product Backlog é a lista de tudo que pode entrar no produto, ordenada por prioridade. Não precisa estar todo especificado. O que está no topo precisa estar pronto para ser construído; o resto pode esperar. O compromisso associado é o Product Goal.

O Sprint Backlog é o que o time combinou para esta Sprint, com o Sprint Goal como compromisso.

O Incremento é o resultado utilizável. O compromisso aqui é a Definition of Done, o acordo explícito sobre o que significa "pronto". Sem isso escrito, "pronto" vira opinião, e a Review vira negociação.

Na minha visão, é a Definition of Done que separa um time que usa Scrum de um time que faz reunião de Scrum.

Os cinco valores, que são a parte difícil

Os eventos e as responsabilidades se implantam em uma semana. Os valores, não.

Uma organização em que ninguém diz que o prazo não cabe não tem coragem. Uma organização em que o time esconde impedimento até a última semana não tem abertura. E nenhum framework resolve isso, porque o problema não está no processo.

O que mudou no Guia de 2020

Se você estudou Scrum antes de novembro de 2020, três coisas mudaram e ainda causam confusão:

• "Development Team" virou "Developers". A ideia de um time dentro do time saiu. Agora existe um Scrum Team só, com três responsabilidades.
• "Papéis" virou "responsabilidades". Menos cargo, mais prestação de contas.
• O tamanho passou a ser "tipicamente dez ou menos", contando todos, no lugar de três a nove Developers.

O Guia também ficou menos prescritivo. As três perguntas da Daily, por exemplo, deixaram de ser obrigatórias e passaram a ser sugestão.

Onde o Scrum não resolve

O Scrum expõe problema, não corrige. Ele torna visível, a cada duas semanas, que a prioridade muda toda hora, que a Definition of Done não existe, que o Product Owner não decide nada.

Isso é útil e desconfortável. E é o motivo pelo qual muita implantação para no cerimonial: fazer as reuniões custa pouco, mudar o que elas revelam custa caro.

Na sua organização, o Scrum mudou como as decisões são tomadas, ou só mudou o nome das reuniões?