Scrum Guide 2020 está pronto: Confira as mudanças

Por Carolina Lucena

Organizações que utilizam Scrum ficarão felizes em saber que o Scrum Guide 2020 está disponível. Esta é a primeira atualização em três anos.

Ken Schwaber e Jeff Sutherland publicaram uma nova versão do Scrum Guide em 18 de novembro de 2020. O framework Scrum foi desenvolvido por eles no início de 1990 e a primeira versão do Scrum Guide foi publicada em 2010. Desde então, o guia vem sendo suportado com pequenas adaptações. Esta última atualização trouxe algumas mudanças significativas, que iremos abordar no decorrer deste artigo, como:

• Mudança na linguagem para melhorar a leitura e entendimento;
• Instruções e definições menos prescritivas;
• O Lean Thinking é referenciado;
• Developers ao invés de Dev Team;
• Foi adicionado práticas para prever o progresso da Sprint;
• As clássicas três perguntas da Daily Scrum foram removidas;
• Um novo artefato foi adicionado, o Product Goal;
• Artefatos atrelados a compromissos.

Linguagem do Scrum Guide nova e melhorada

A primeira e mais importante mudança no guia foi ajustar a linguagem. Alguns termos que definiam o framework limitando ao desenvolvimento de software foram retirados. Desta forma, o novo guia torna o Scrum ainda mais adaptativo para outros segmentos.

Se te perguntarem o que você faz, e você disser que é um ou uma Scrum Master, se a pessoa não tiver uma bagagem de desenvolvimento de software, provavelmente não saberá do que se trata. É ai que entusiastas gostam de explicar suas responsabilidades e então aprofundar em como o Scrum funciona.

Ao participar de eventos sobre o tema de métodos ágeis, as pessoas sempre perguntam se tais métodos podem ser utilizados fora do mercado de software. A resposta é sim. Como exemplo, existe um caso de aplicação do framework Scrum em um escritório. O framework apresenta-se muito útil em organizar as atividades do dia a dia e pode-se tirar muito proveito dos eventos. Talvez não seja possível utilizar o framework em sua totalidade, não podendo ser chamado de Scrum, mas é possível aderir algumas práticas como uma daily scrum por exemplo. Quem sabe, adaptando seja possível utilizar de forma completa no futuro? Ficamos animados em saber que o Scrum pode ajudar uma nova onda de empresas com problemas complexos, e nos perguntamos quais resultados os aguardam se puderem seguir esse framework.

Instruções do Guide menos prescritivas

A próxima mudança no guia foi deixá-lo menos prescritivo. Dentro da comunidade ágil, existe a percepção de que o Scrum seja um framework mais prescritivo comparado a outros, como os praticantes do Kanban costumam comentar. O Scrum tem papeis bem definidos, eventos, time-boxes, e artefatos que acabam deixando a impressão de ser mais prescritivo, mas essa nunca foi a intenção. Agora, esta atualização no guia, veio para corrigir este equívoco em partes, o que não quer dizer que não existe mais nenhuma dessas definições. Somente alguns detalhes foram otimizados no guia, conforme os seguintes tópicos:

• O Scrum Master é responsável por remover impedimentos. Atualmente, os Scrum Masters são responsáveis por guiar o time a remover seus próprios impedimentos. A nova versão veio para clarificar este conceito;
• O guia não possui mais uma sessão específica falando do cancelamento da Sprint. Somente deixa claro que a Sprint poderá ser cancelada quando o Sprint Goal ficar obsoleto;
• O time não move mais as ações definidas na Retrospectiva da Sprint imediatamente para a próxima Sprint. No entanto, o time deverá resolvê-las o mais rápido possível com o intuito de adaptar o processo. Essa prática de fato era uma prescrição, mas trouxe muita luz ao bom Scrum. Permitiu a reflexão que ela era importante para alcançar a melhoria contínua do processo. Esperamos que esta atualização não leve o Scrum de volta para as sombras.

O guia em português possuía 20 páginas na versão de 2017 e, na versão atual de 2020 ficou com 16 páginas. Cada sessão está mais simplificada, e algumas explicações para eventos e/ou práticas foram removidas. Com estas alterações, o Scrum Guide poderá ser visto verdadeiramente como um guia simples e mais objetivo comparado a antes. Quem sabe as futuras mudanças possam seguir na mesma direção?

Com base em nosso conhecimento e experiência do processo Scrum, esses e outros detalhes melhoram a objetividade e flexibilidade do guia, o que pode ter prós e contras.

Adicionado o conceito de Lean Thinking ao Scrum Guide

Toda a parte de propósito, definição, teoria, valores, pilares e princípios foram reduzidos, deixando tudo mais objetivo. O Scrum Guide agora cita o Lean Thinking como parte de sua teoria, no qual expressa a importância de redução de desperdício e foco máximo no essencial.

Certa vez trabalhei em um projeto para implementação do Scrum em uma grande organização. Em um primeiro momento, foi difícil lidar com a resistência, até porque o propósito e os benefícios da mudança não estavam claros para todos. Como Scrum Master, foi interessante enfatizar a redução de desperdício. Utilizando os conceitos dos sete desperdícios do Lean, mostramos ao time e gerência o quanto eles poderiam reduzir desperdícios diários e gerar mais valor ao cliente. Utilizando este conceito do Lean, foi possível mostrar a todos os benefícios de utilizar um framework Ágil.

A utilização do Scrum com outros frameworks sempre foi possível. Além de utilizar os conceitos dos sete desperdícios do Lean, também vale implementar práticas do Kanban.  Notamos em projetos passados e atuais que algumas ferramentas do Kanban ajudam no planejamento e monitoramento das Sprints. Vemos outras práticas que podemos implementar para trazer mais valor as nossas entregas. Exemplos dessas práticas incluí o limite WIP (work in progress), Kanban Board, e métricas.

Nova organização do Scrum Team

Na nova versão do Scrum Guide, os developers substituem o Dev Team. Esta alteração foi justamente para remover a impressão de ter um time separado do Scrum Team. Então, agora o Scrum Team é comporto pelo Scrum Master, Product Owner e Developers.

Achamos que essa mudança foi particularmente importante, pois na prática, acabava sendo criada essa separação entre Dev team, Product Owner e Scrum Master. Como estamos acostumados a trabalhar com hierarquia, os papeis de Scrum Master e Product Owner acabam sendo confundidos com “chefes”, e o verdadeiro significado do Scrum Team acaba se perdendo. O Scrum Team precisa ser autogerenciável. Eles decidem o por que, como e no que trabalhar, autonomamente tomando decisões de acordo com o Product Goal.

Ferramentas para medir o progresso

A sessão da Sprint se tornou mais enxuta e menciona ferramentas para medir o progresso das Sprints como: burndowns, burn-ups, e cumulative flows.

Certa vez trabalhamos em um time que apesar de utilizar o framework Scrum, não possuía uma base para planejar a Sprint. O planejamento era feito com base na expectativa do cliente. Após observar duas Sprints, apresentamos métricas como velocity, throughput, e cycle time. Em um primeiro momento, o time sentiu que estavam planejando mais do que sua capacidade. Fizemos também, a organização e priorização do Product Backlog de acordo com o prazo e expectativa do cliente. Planejamos uma Sprint considerando a capacidade do time, depois outra já considerando o plano para a entrega, validando-o a cada Daily Scrum. Com este método, entregamos a primeira Sprint conforme o planejado com um resultado melhor do que as anteriores. E ainda sem realizar horas extras.

O ponto disso é: Medir e acompanhar o progresso é importante! O objetivo da daily scrum é analisar o progresso e adaptar para garantir o Sprint Goal.

A daily Scrum não possui mais as três perguntas como principal elemento. Em teoria, essas perguntas eram uma sugestão para guiar o time na validação do plano de entrega da Sprint. Mas na prática, acaba tornando a daily scrum a um momento de status report. O objetivo principal, que é validar o plano acaba se perdendo. O foco deve ser em permitir aos developers os ajustes de seu plano com o Sprint Goal em mente.

Em cada Daily Scrum, alguém deve fazer uma pergunta “Qual é o nosso plano para hoje?” Dessa forma, o time adquire o hábito de começar a daily scrum com esta resposta em mente.

Novos Artefatos do Scrum

A nova versão do guia não fala somente do Sprint Goal, mas também do Product Goal. O Product Goal está relacionado ao Product Backlog e deve ser revisitado a cada Sprint Review. O Scrum Team precisa trabalhar em conjunto para atingir este Goal em cada Sprint.

Sempre fazemos questão de conversar com o Product Owner e compartilhar a visão do produto com todo o time. Para onde queremos ir? Qual é nosso objetivo? Como iremos saber se alcançaremos? O Product Goal deverá responder essas questões e guiar o Scrum Team em como alcançar este resultado.

O definition of done também ganha espaço como um artefato. Seu significado é a descrição formal do estado do incremento, quando ela atende às medidas de qualidade exigidas para o produto. Se a organização já possui um definition of done, ele deverá ser respeitada. Mas podemos complementar o definition of done com outros pontos que acharmos interessante. Se a organização não possuir um, o Scrum Team define e aplica isso a cada entrega de incremento.

Devemos ter cuidado para não confundir o definition of done com definition of ready e acceptance criteria. Definition of ready é um acordo entre o Product Owner e os developers em como uma user story estará pronta para a Sprint Planning. O Acceptance Criteria será diferente para cada user story, e trata-se de uma lista de itens testáveis para garantir que a user story seja implementada de acordo com a expectativa do Product Owner.

Cada artefato agora possui um compromisso, para:

• Product Backlog, o Product Goal;
• Sprint Backlog, o Sprint Goal;
• Incremento, o Definition of Done.

Quando se tem um objetivo, fica muito mais fácil alcançar os resultados. Para aumentar ainda mais esse resultado, podemos envolver o cliente na definição desses artefatos.

Ainda tem dúvidas sobre o novo Scrum Guide?

Em geral, o guia ficou muito mais leve e fácil de compreender. Mas o Scrum continua sendo um framework. Seus pilares, valores e princípios ainda transformam problemas complexos em valor agregado ao cliente. Esperamos que com essas mudanças, possamos continuar melhorando as interações entre os membros do time. Talvez todos dentro do time sintam-se mais confortáveis com sua autonomia e responsabilidade para juntos entregar incrementos de alto valor a seus clientes. Mas o verdadeiro resultado continuará sendo visto uma vez que as mudanças serão colocadas em prática.

Quer saber mais sobre o framework Scrum ou precisa de ajuda para implementar o Scrum no seu negócio? Entre em contato conosco hoje mesmo e fale com um dos nossos especialistas.

Carolina Lucena é uma das Scrum Masters da Programmer’s. Graduada em Ciências Contábeis e especializada em Engenharia de Software, tem experiência em Métodos Ágeis em diversos segmentos de negócios.