/ AGILIDADE

Scrum Guide 2020

Foto de RetroSupply, via Unsplash

No dia 18 de novembro, em comemoração aos 25 anos do Scrum e aos 10 anos do Scrum Guide, foi lançado o Scrum Guide 2020. Ele foi anunciado como um guia menos prescritivo e mais enxuto e, dentre as novidades destacadas no evento, encontram-se:

  • Foco em manter o Scrum como um framework minimalista;
  • Aproximação entre o PO e os Desenvolvedores, com o reforço do conceito de que o Time Scrum é um time único, sem hierarquias;
  • Conceito do Objetivo do Produto, que fornece uma meta de valor maior para o time, onde cada Sprint deve aproximar o produto em sua direção;
  • Objetivo do Produto, Objetivo da Sprint e Definition of Done atrelados aos artefatos;
  • O time de desenvolvimento agora é descrito como autogerenciado ao invés de auto-organizado;
  • O tópico da Sprint Planning foi estendido, descrevendo o porquê, o quê e o como;
  • A linguagem foi simplificada, para atingir mais pessoas além da área de TI.

Nesse post vou fazer uma tradução parcial, além de comentar todas as mudanças da nova versão. Assim como na série Trabalhando com o Scrum, alguns termos seguirão em inglês para que o texto se aproxime ao máximo do modo como me refiro a eles no dia a dia.

Definição do Scrum

Ao ler a nova versão, a primeira impressão é que realmente está mais enxuto. A versão anterior (2017) tem 19 páginas versus as 13 páginas da versão atual. E a segunda impressão é que realmente parece ser um guia mais fácil de ler. Logo no início, a definição do Scrum já apresenta uma lista de itens que, na minha opinião, explica muito bem o framework em poucas palavras:

O Scrum necessita de um Scrum Master para fomentar um ambiente onde:

  1. Um Product Owner ordena o trabalho de um problema complexo dentro de um Product Backlog;
  2. O Time Scrum transforma uma seleção deste trabalho em um Incremento de valor durante uma Sprint;
  3. O Time Scrum e os stakeholders inspecionam os resultados e fazem os ajustes para a próxima Sprint;
  4. Repita.

Realmente é uma forma muito direta de explicar o funcionamento do Scrum e acredito que agora qualquer pessoa que ler o Scrum Guide vai concordar que o framework é simples. Não que ele não fosse simples nas versões anteriores, mas eu mesma tive dificuldades para entender o panorama geral na primeira vez que li. Só consegui entender o todo após participar de uma Sprint na prática e reli o Scrum Guide com outros olhos, aproveitando muito mais o conteúdo.

O Scrum é um framework que define somente as partes necessárias para implementar a sua teoria. As regras fornecidas guiam as relações e interações das pessoas que compõem o time, sendo possível aplicar diversos processos, técnicas e métodos.

O Scrum torna visível a eficácia relativa do gerenciamento, ambiente e técnicas de trabalho para que melhorias possam ser feitas.

Outra novidade é que a nova versão não possui a seção “Usos do Scrum”. Como anunciado, o Scrum pode ser utilizado por diversas áreas além da TI e a linguagem foi simplificada, então entendo que não faz sentido ter esse texto que definia os termos utilizados pelos times de tecnologia.

Teoria do Scrum

Além do empirismo, o Scrum agora também é baseado no Lean Thinking:

Empirismo: o conhecimento vem da experiência e a tomada de decisão deve ser baseada no que é conhecido.

Lean Thinking: reduz desperdício e foca no que é essencial.

Para otimizar a previsibilidade e controlar os riscos, o Scrum utiliza uma abordagem iterativa e incremental. O Scrum envolve grupos de pessoas que coletivamente possuem todas as habilidades e conhecimento para realizar o trabalho, que compartilham e adquirem conhecimento conforme necessário.

Esta versão segue com as 4 cerimônias para inspeção e adaptação dentro da Sprint (Planning, Daily, Review e Retrospectiva). E elas só funcionam porque implementam os pilares empíricos do Scrum de transparência, inspeção e adaptação.

Transparência

O processo emergente e o trabalho devem estar visíveis para quem realiza as atividades, bem como para quem recebe os resultados. Decisões importantes são tomadas com base no estado percebido dos 3 artefatos formais (Product Backlog, Sprint Backlog e Incremento).

A transparência permite inspeção. Inspeção sem transparência é enganosa e gera desperdício.

Inspeção

Os artefatos do Scrum e o progresso em direção aos objetivos devem ser inspecionados frequente e cuidadosamente para identificar potenciais discrepâncias ou problemas indesejados.

A inspeção permite adaptação. Inspeção sem adaptação é considerada sem sentido.

Adaptação

Se qualquer aspecto do processo desvia dos limites aceitáveis ou se existem objeções em relação ao produto resultante, o processo que está sendo aplicado ou os materiais que estão sendo produzidos devem ser ajustados. O ajuste deve ser feito o mais rápido possível para evitar maiores desvios.

A adaptação é dificultada quando as pessoas envolvidas não são empoderadas ou autogerenciadas. É esperado que o Time Scrum se adapte quando aprende algo novo através da inspeção.

Esta seção agora deixa mais claro qual é a conexão entre cada um dos pilares: a transparência permite inspeção, a inspeção permite adaptação e, após o processo de adaptação, os artefatos e processos devem se manter transparentes para que o ciclo continue.

Valores do Scrum

O sucesso do Scrum depende de pessoas se tornando proficientes em viver os 5 valores:

  1. Comprometimento: o Time Scrum se compromete a atingir os objetivos e a suportar uns aos outros;
  2. Foco: o foco principal é no trabalho da Sprint para fazer o melhor progresso possível em direção aos objetivos;
  3. Abertura: o Time Scrum e os stakeholders são abertos a respeito do trabalho e dos desafios;
  4. Respeito: os membros do Time Scrum respeitam uns aos outros, sabendo que todos são pessoas capazes e independentes;
  5. Coragem: o Time Scrum tem coragem para fazer a coisa certa, para trabalhar em problemas difíceis.

Esses valores guiam o Time Scrum em relação ao trabalho, ações e comportamento e eles devem ser trabalhados ao longo das Sprints. Quando esses valores são internalizados pelo Time Scrum e pelas pessoas com quem o time trabalha, os pilares empíricos do Scrum da transparência, inspeção e adaptação ganham vida, gerando confiança.

Apesar de ter sido revisada, a essência da teoria do Scrum segue a mesma. Mantendo os pilares e valores descritos em versões anteriores e que são tão importantes para a agilidade.

Time Scrum

O Time Scrum consiste em um Scrum Master, um Product Owner e os Desenvolvedores. Não existem times internos, nem hierarquia. É uma unidade coesa de profissionais, focados em um objetivo por vez, o Objetivo do Produto.

Os membros do Time Scrum possuem todas as habilidades necessárias para criar valor a cada Sprint. O time é autogerenciado, ou seja, o time escolhe internamente quem faz o quê, quando e como.

O Time Scrum deve ser pequeno o suficiente para se manter ágil e grande o suficiente para ter todas as habilidades necessárias para fazer um trabalho significante a cada Sprint. O recomendado é no máximo 10 pessoas.

O Time Scrum é responsável por todas as atividades relacionadas ao produto, incluindo a colaboração com os stakeholders, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento e qualquer outra atividade necessária. O time é estruturado e empoderado pela companhia de forma que conseguem gerenciar o seu próprio trabalho. Trabalhar em Sprints em um ritmo sustentável melhora o foco e a consistência do time.

Todos os integrantes do Time Scrum são responsáveis por criar um Incremento de valor e utilizável a cada Sprint.

Essa seção se difere por definir o time como autogerenciado ao invés de auto-organizado, definição que não considerava quando o trabalho será feito. A descrição do tamanho do time na versão anterior encontrava-se na seção “Tamanho do time de desenvolvimento”. Além dessa seção ter sido removida do Scrum Guide, a recomendação de tamanho do time na nova versão considera todos os integrantes.

Desenvolvedores

São as pessoas no time comprometidas com a criação de qualquer aspecto de um Incremento utilizável a cada Sprint. As habilidades específicas necessárias variam de acordo com o escopo do trabalho, mas os Desenvolvedores são sempre responsáveis por:

  • Criar o plano para a Sprint, o Sprint Backlog;
  • Garantir qualidade ao aderir ao Definition of Done;
  • Adaptar o plano diariamente em direção ao Objetivo da Sprint;
  • Responsabilizar-se mutualmente como profissionais.

Agora o Scrum Guide faz referência às pessoas que desenvolvem o trabalho para entregar o produto como Desenvolvedores, ao invés de Time de Desenvolvimento. A intenção é reforçar que não existe um time separado dentro do Time Scrum.

Product Owner

O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Time Scrum. A forma de fazer isso varia de acordo com a organização, Times Scrum e indivíduos que estão envolvidos.

O Product Owner também é responsável por um gerenciamento efetivo do Product Backlog, que inclui:

  • Desenvolver e comunicar explicitamente o Objetivo do Produto;
  • Criar e comunicar de forma clara os itens do Product Backlog;
  • Ordenar os itens do Product Backlog;
  • Garantir que o Product Backlog é transparente, visível e compreensível.

Independente do Product Owner desempenhar essas atividades ou delegar para outras pessoas, ele segue sendo o responsável pelo Product Backlog.

Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. Essas decisões são visíveis em relação ao conteúdo e à ordenação do Product Backlog e em relação ao Incremento na Review.

Scrum Master

O Scrum Master é responsável por estabelecer o Scrum como definido no Scrum Guide. Isso é feito ajudando todos a entenderem a teoria e prática do Scrum, no contexto do Time Scrum e da organização como um todo.

O Scrum Master é responsável pela eficácia do Time Scrum. É um líder que serve ao Time Scrum e à organização.

O Scrum Master serve ao Time Scrum de diversas formas, incluindo:

  • Instruindo os membros do time no autogerenciamento e na interdisciplinaridade;
  • Apoiando no foco para criar Incrementos de alto valor que estejam de acordo com o Definition of Done;
  • Removendo impedimentos que afetam o progresso do time;
  • Garantindo que todas as cerimônias são feitas de forma positiva, produtiva e dentro do timebox.

O Scrum Master serve ao Product Owner de diversas formas, incluindo:

  • Ajudando a encontrar técnicas para um gerenciamento efetivo do Objetivo do Produto e do Product Backlog;
  • Ajudando o Time Scrum a entender a necessidade de um Product Backlog com itens claros e concisos;
  • Ajudando a estabelecer um planejamento de produto empírico em um ambiente complexo;
  • Facilitando a colaboração com os stakeholders conforme necessário.

O Scrum Master serve à organização de diversas formas, incluindo:

  • Liderando, treinando e instruindo a organização na adoção do Scrum;
  • Planejando e aconselhando nas implementações do Scrum na organização;
  • Apoiando os colaboradores e os stakeholders a compreender e aceitar a abordagem empírica para trabalhos complexos;
  • Removendo barreiras entre stakeholders e os Times Scrum.

Além da mudança na nomenclatura dos papéis, a descrição do papel do Scrum Master está mais enxuta e acredito que está bem mais próxima do que é feito no dia a dia.

Cerimônias do Scrum

Todas as cerimônias estão contidas na Sprint. Cada cerimônia é uma oportunidade para inspecionar e adaptar os artefatos.

As cerimônias são utilizadas no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no framework. Idealmente, todos os eventos são feitos nos mesmos horários e locais, para reduzir a complexidade.

A instrução de manter as cerimônias marcadas nos mesmos horários e locais foi removida da seção da Daily e adicionada para todas as cerimônias. Sempre fui uma defensora dessa prática para todas as cerimônias, pois saber que toda quarta-feira tem uma Planning, por exemplo, ajuda a manter uma organização com o time que só traz benefícios com o passar do tempo.

Sprint

As Sprints são eventos de tamanho fixo, de até um mês. Uma nova Sprint se inicia imediatamente após a conclusão da Sprint anterior.

Todo o trabalho necessário para atingir o Objetivo do Produto é realizado dentro da Sprint e isso inclui todas as cerimônias.

Durante a Sprint:

  • Não são feitas mudanças que possam ameaçar a conclusão do Objetivo da Sprint;
  • A qualidade não diminui;
  • O Product Backlog é refinado conforme necessário;
  • O escopo pode ser esclarecido e renegociado com o Product Owner de acordo com os aprendizados.

Várias práticas podem ser aplicadas para prever o progresso, como burn-downs, burn-ups ou diagramas de fluxo cumulativo. Apesar de úteis, não devem substituir o empirismo. Em ambientes complexos, não sabemos o que pode acontecer e apenas o que já aconteceu pode ser utilizado para tomar decisões para o futuro.

A Sprint pode ser cancelada se o Objetivo da Sprint se tornar obsoleto e apenas o Product Owner pode cancelar a Sprint.

Esta seção num geral foi bem resumida. A seção “Cancelando uma Sprint” foi removida e o seu conteúdo está descrito de forma sucinta dentro da descrição da Sprint.

Sprint Planning

A Planning inicia a Sprint apresentando o trabalho que será desempenhado durante a Sprint. O plano resultante é criado colaborativamente por todo Time Scrum.

O Product Owner garante que os participantes estão preparados para discutir os itens mais importantes do Product Backlog e como esses itens se relacionam com o Objetivo do Produto. O Time Scrum pode convidar outras pessoas para participar da cerimônia, a fim de consultoria.

A Planning aborda os seguintes tópicos:

  • Qual é o valor dessa Sprint?
    • O Objetivo da Sprint deve ser definido até o final da cerimônia.
  • O que pode ser feito nessa Sprint?
    • Seleção de itens do Product Backlog que será concluída durante a Sprint.
  • Como o trabalho escolhido será feito?
    • Os Desenvolvedores quebram cada item selecionado em tarefas menores, de no máximo um dia.

O Sprint Backlog é formado pelo Objetivo da Sprint, pelos itens do Product Backlog selecionados para a Sprint e pelo plano para entregar todos estes itens.

Agora temos um terceiro tópico na Planning: “Qual é o valor dessa Sprint?”. Assim, o objetivo da Sprint ganha destaque ao não ser mais descrito em uma seção separada da Planning e é incluído na descrição da facilitação da cerimônia.

Daily Scrum

O propósito da Daily é inspecionar o progresso em direção ao Objetivo da Sprint e fazer as adaptações necessários no Sprint Backlog.

A Daily é uma cerimônia de 15 minutos feita pelos Desenvolvedores. Para reduzir a complexidade, ela é feita no mesmo horário e local durante todos os dias da Sprint. Se o Product Owner e o Scrum Master estão trabalhando ativamente em itens do Sprint Backlog, eles podem participar da cerimônia como Desenvolvedores.

Os Desenvolvedores podem escolher a estrutura e técnicas que quiserem para realizar a Daily, desde que a cerimônia foque no progresso em direção ao Objetivo da Sprint e produza um plano para o dia de trabalho seguinte. Isso cria foco e melhora o autogerenciamento.

A Daily melhora a comunicação, identifica impedimentos, promove a tomada de decisão rápida e, consequentemente, elimina a necessidade de outras reuniões. Ela não é o único momento em que os Desenvolvedores estão permitidos a ajustar o plano. Eles geralmente se reúnem durante o dia, para discussões mais detalhadas sobre adaptação e replanejamento do trabalho restante da Sprint.

Não ter as perguntas deixa a Daily menos prescritiva, mas sempre considerei as perguntas como um exemplo interessante de como iniciar a facilitação da Daily antes de fazer os ajustes necessários para a dinâmica se encaixar no time.

Sprint Review

O propósito da Review é inspecionar o resultado da Sprint e determinar as adaptações futuras. O Time Scrum apresenta o resultado do trabalho desempenhado para os stakeholders chave e o progresso em direção ao Objetivo do Produto é discutido.

Durante a cerimônia, o Time Scrum e os stakeholders revisam o que foi realizado durante a Sprint e o que mudou no cenário. Baseados nessas informações, os participantes colaboram a respeito do que fazer em seguida. O Product Backlog também pode ser ajustado para atender novas oportunidades. A Review é uma cerimônia de trabalho e o Time Scrum deve evitar limitá-la a uma apresentação.

É a penúltima cerimônia da Sprint.

Essa seção está muito menor. A versão anterior continha um script de como facilitar a cerimônia e, para mim, foi a maior mudança na tentativa de deixar o Scrum Guide menos prescritivo. A nova versão traz instruções muito mais amplas, mas que são igualmente eficientes no propósito de informar os insumos e resultados esperados da cerimônia.

Retrospectiva

O propósito da Retrospectiva é planejar maneiras de aumentar a qualidade e a eficácia.

O Time Scrum inspeciona como foi a Sprint anterior em relação às pessoas, interações, processos, ferramentas e o Definition of Done. O time discute o que deu certo durante a Sprint, quais problemas foram encontrados e como esses problemas foram (ou não foram) resolvidos.

Melhorias de maior impacto devem ser endereçadas o mais rápido possível. Podendo até mesmo serem adicionadas ao Sprint Backlog da Sprint seguinte.

A Retrospectiva conclui a Sprint.

De modo geral, todas as cerimônias foram descritas de forma mais enxuta. Deixei destacado em negrito o momento em que cada cerimônia ocorre durante a Sprint, informação que foi adicionada nessa versão.

Artefatos do Scrum

Os artefatos representam trabalho ou valor. Eles são projetados de forma a maximizar a transparência de informações chave.

Cada artefato possui um compromisso, para garantir que fornece informações que aumentam a transparência e o foco e que permitem que o progresso possa ser medido:

  • Para o Product Backlog é o Objetivo do Produto;
  • Para o Sprint Backlog é o Objetivo da Sprint;
  • Para o Incremento é a Definition of Done.

Esses compromissos existem para reforçar o empirismo e os valores do Scrum para o Time Scrum e seus stakeholders.

Cada artefato ter um compromisso é uma novidade da versão 2020. Agora existe uma forma de medir o progresso para o produto como um todo, além da que já existia para a Sprint e para o incremento.

Product Backlog

O Product Backlog é uma lista ordenada do que é necessário para evoluir o produto. É a única fonte do trabalho realizado pelo Time Scrum.

Itens do Product Backlog que podem ser concluídos pelo Time Scrum dentro de uma Sprint são considerados prontos para seleção na Planning. Eles se tornam cada vez mais transparentes a cada refinamento, que é o ato de quebrar os itens em itens menores e mais precisos. Essa é uma atividade recorrente, onde são adicionados detalhes como a descrição, ordenação e tamanho. Os atributos podem variar conforme o escopo do trabalho.

Os Desenvolvedores são os responsáveis por definir o tamanho dos itens. O Product Owner pode influenciar, ajudando na compreensão e troca de itens.

Objetivo do Produto

O Objetivo do Produto descreve o estado futuro do produto que pode servir como um alvo para o planejamento do Time Scrum. Os itens do Product Backlog definem o que vai atender ao Objetivo do produto.

Um produto é um veículo para entregar valor. Ele tem fronteiras claras, stakeholders conhecidos, usuários ou clientes bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato.

O Objetivo do Produto é um objetivo de longo prazo para o Time Scrum. O time deve atingir este objetivo (ou abandoná-lo) antes de partir para o próximo.

O Product Backlog estar descrito de forma bem mais sucinta, facilitando o entendimento do artefato. Também foi incluída a definição de produto que, apesar de ser citado na versão anterior, somente a versão atual traz uma descrição clara.

Sprint Backlog

O Sprint Backlog é composto pelo Objetivo da Sprint (porquê), pelo conjunto de itens do Product Backlog selecionados para a Sprint (o quê), bem como um plano para entregar o Incremento (como).

O Sprint Backlog é um plano feito por e para os Desenvolvedores. É um plano altamente visível, com o status atualizado do trabalho desempenhado durante a Sprint pelos Desenvolvedores para atingir o Objetivo da Sprint. Deve ter detalhe suficiente para que seja possível inspecionar o progresso durante a Daily.

Objetivo da Sprint

O Objetivo da Sprint é a única meta da Sprint. Ele cria coerência e foco, encorajando o Time Scrum a trabalhar junto, ao invés de trabalharem em iniciativas separadas.

Ele é criado durante a Planning e é adicionado ao Sprint Backlog. Conforme os Desenvolvedores trabalham na Sprint, eles devem manter o Objetivo da Sprint em mente. Se o trabalho se desviar do esperado, os Desenvolvedores devem colaborar com o Product Owner para renegociar o escopo do Sprint Backlog sem afetar o Objetivo da Sprint.

Incremento

Um Incremento é um passo concreto em direção ao Objetivo do Produto. Cada incremento é uma adição a todos os Incrementos anteriores, que deve ser devidamente verificado para garantir que todos os Incrementos sigam funcionando juntos.

Vários incrementos podem ser criados durante a Sprint. A soma desses Incrementos é apresentada na Review, suportando o empirismo. Um Incremento pode ser liberado para os stakeholders antes do final da Sprint, pois a Review nunca deve ser considerada como o único momento para entregar valor.

O trabalho não pode ser considerado como parte do Incremento, a não ser que faça parte do Definition of Done.

Definition of Done

O Definition of Done é uma descrição formal do estado do Incremento que atende aos padrões de qualidade exigidos para o produto. No momento que um item do Product Backlog atende ao Definition of Done, temos um Incremento.

O Definition of Done cria transparência ao fornecer para todos um entendimento comum do trabalho que precisou ser concluído para formar um Incremento. Se um item do Product Backlog não atende ao Definition of Done, ele não pode ser liberado ou apresentado na Review. Ao invés disso, deve retornar para o Product Backlog para ser reavaliado.

Se o Definition of Done para um Incremento é parte dos padrões da organização, então todos os Times Scrum devem seguir pelo menos o que o padrão define. Caso não exista padrão, o Time Scrum deve criar um Definition of Done apropriado para o produto.

Os Desenvolvedores devem trabalhar de forma a atender o Definition of Done. Se vários Times Scrum trabalham no mesmo produto, todos devem definir e atende o mesmo Definition of Done.

Aqui temos o reforço de que o Incremento deve funcionar junto com os Incrementos anteriores, pois uma entrega não pode comprometer o que já foi liberado previamente.


Se você leu tudo até aqui, deve ter percebido que o Scrum Guide 2020 está mais direto e com as seções distribuídas de forma mais organizada. Acho ótima a inclusão do Lean Thinking e a remoção do conceito do “Time de Desenvolvimento” para uma aproximação dos Desenvolvedores com o Product Owner.

Todas as mudanças parecem fazer muito sentido e um guia menos prescritivo abre um leque de possibilidades para os times, permitindo que ainda sejam enquadrados no Scrum ao fazer uma Review diferente, por exemplo. O próprio guia é bem assertivo quanto a isso, ao dizer que implementar somente partes do Scrum não é Scrum, então essa simplificação é muito bem-vinda.

O Scrum Guide 2020 encontra-se neste link e as informações das mudanças e a gravação do evento podem ser encontradas aqui.

Como sempre, os comentários estão abertos para dúvidas e discussões.



ingridmachado

Ingrid Machado

Engenheira de computação, especialista em engenharia de software.
Autora deste querido blog.

Mais posts