Scrum é um framework de regras e um passo a passo prático para que equipes consigam desenvolver produtos conforme a metodologia ágil. Enquanto o Agile Manifesto dá as diretrizes e todo o mindset para uma equipe incorporar seus valores, o Scrum é o framework mais utilizado pelas empresas nos dias atuais, visando aplicar o Agile na prática.
Por ser um framework ágil, engloba regras e métodos que seguem essa metodologia, dando a ela diretrizes complementares e práticas – o “como fazer” – sendo fácil perceber por que algumas regras são como são.
Como surgiu o Scrum?
Contextualizando seu surgimento, o Scrum apareceu pela primeira vez em 1986 no artigo “The New New Product Development Game” produzido por Hirotaka Takeuchi e Ikujiro Nonaka, e publicado pela The Harvard Business Review. O nome, que traduzido para português fica algo como “O Novo Jogo de Desenvolvimento de Novos Produtos”, foi uma sacada proposital dos autores para apresentar uma nova forma de gerenciamento de produto inspirada na estratégia do jogo Rugby.
Tempos depois, e não se limitando a esse surgimento, foi publicado em 1995 o livro “Scrum Development Process“, pelos autores Ken Schwaber e Jeff Sutherland, pioneiros na aplicação do Scrum com as diretrizes da época. Por volta desse período, houve a percepção de que o Scrum já era mais eficaz que o modelo conhecido como Waterfall (“Cascata”) de desenvolvimento de produto, sobretudo por sua adaptabilidade.
Com isso, foi apenas com essa publicação que o Scrum se revelou como o conhecemos hoje, no que podemos pensar ter sido uma mistura da incorporação da teoria do primeiro artigo publicado, com a experiência real aplicada pelos autores do livro de 1995.
Como funciona e como aplicar
Uma das principais características do Scrum é a utilização de ciclos de desenvolvimento sucessivos, que se repetem a cada determinado período de tempo, os quais chamamos de Sprints (ou “iterações”, em português). Cada sprint pode ter de 1 a n semanas de desenvolvimento, sendo o mais comum o uso de sprints de 2 semanas.
Pessoas no Scrum
O Scrum determina algumas funções que compõem o time Scrum, são elas:
- Scrum Master: Em linhas gerais é a figura do time que deve garantir a aplicação do framework, ou seja, precisa ser um bom conhecedor do Scrum. Ele faz isso guiando as cerimônias e verificando o cumprimento das regras, além de se responsabilizar por superar os impedimentos apontados pela equipe.
- Product Owner: É aqui que entra uma pessoa representando o time de Produto, e eu diria que uma das figuras mais fundamentais nesse jogo. É responsabilidade do PO cuidar do product backlog, ou seja, lista de tarefas a serem desenvolvidas, refinando-o para que esteja priorizado e agregue o máximo de valor a cada entrega. Também faz a ponte com outras equipes e interessados no produto, o qual chamamos stakeholders.
- Desenvolvedores: Aqui entram todos os desenvolvedores de software, que podem ter diferentes especialidades. Podemos ter Dev Front-end, Back-end, Fullstack, QA, DevOps, Tech Leads, etc. Não há um número determinado e isso varia dependendo da empresa e do produto.
As cerimônias no Scrum
Cada sprint é composta por algumas cerimônias com propósitos bem claros que veremos a seguir. O Scrum não é um framework desenvolvido para ser trabalhoso, pelo contrário, seu objetivo é fomentar a adaptabilidade, mantendo o respeito pelas pessoas e ajudando equipes a se auto organizarem. Dessa forma, a existência de cerimônias já pré-definidas e com limite de tempo ajuda muito em sabermos o que/como devemos prosseguir com o desenvolvimento de determinado produto.
Sprint Planning
A primeira das cerimônias é a que chamamos de Sprint Planning. Nela, a equipe se reunirá no primeiro dia da sprint para definir e estimar quais tarefas estarão executando naquele ciclo, não devendo passar do tempo aproximado de 2h por semana de sprint, ou seja, numa sprint de 2 semanas de duração, a planning deverá ter até 4h. Nessa cerimônia, o Product Owner já está com o backlog devidamente priorizado, e vai direcionar o planejamento para entrega de maior valor possível.
Daily Scrum
No decorrer do desenvolvimento temos uma cerimônia diária, chamada Daily Scrum. Mais que um reporte de ações, essa cerimônia serve para alinhamento contínuo entre a equipe e solução de impedimentos. Não deve durar mais de 15 minutos diários, o que é uma tarefa árdua para muitas equipes, mas o objetivo dela é realmente ser célere e objetiva. Um curiosidade interessante é que, até antes do início da pandemia da Covid-19, muitas empresas e equipes culturalmente realizavam essa rápida conversa com todos as pessoas de pé, justamente para que não fosse possível fazê-la durar tanto (visto que, por óbvio, ficariam cansadas de permanecer em pé por muito tempo).
Sprint Review
Passado o tempo de desenvolvimento da sprint, tem-se a Sprint Review, cerimônia onde todo o time de desenvolvimento, SM e PO, devem apresentar aos stakeholders tudo que foi produzido naquele ciclo. Os stakeholders muitas vezes são representados pelas pessoas de negócio da empresa, clientes, outros setores e demais interessados no produto. O objetivo é que o desenvolvimento tenha sempre coleta de feedback e alinhamento sobre a saúde do produto.
É natural que ciclos de desenvolvimentos menores e com constante alinhamento de expectativas e saúde do produto tenham grande eficiência. Isso porque fica extremamente mais fácil poder mudar o rumo do desenvolvimento, caso necessário.
Essa é uma das principais características que fez o Scrum e o Agile ficarem tão famosos. Era comum no modelo Waterfall que escopos fechados fossem definidos com prazos fechados, mas que no decorrer do desenvolvimento muitas dificuldades fossem enfrentadas ou até prioridades e interesses fossem alterados, o que gerava altos custos e fadava projetos ao fracasso.
Com ciclos menores de entrega de valor e equipes mais autônomas, todos se tornam efetivamente ágeis, entregando valor constantemente e gerando uma boa percepção de avanço. Além disso, o processo garante que, caso necessário, o rumo do desenvolvimento possa ser adaptado às necessidades do produto/usuários e interesses dos stakeholders.
Sprint Retrospective
Por fim, mas não menos importante, temos a Sprint Retrospective, chamada carinhosamente de “Retro”. Aqui, após a review e ao fim da sprint corrente, toda a equipe se reúne internamente para trocar feedbacks, falando sobre o que fizeram bem e o que não fizeram bem naquele ciclo. Com isso, deve-se buscar enumerar itens de ação para tentar aprimorar nesses pontos nos próximos ciclos, buscando a melhoria contínua da relação entre as pessoas e da qualidade do trabalho.
Notas sobre a minha experiência
Costumo brincar que agilidade é um caminho sem volta. Todo o mindset e a forma de se trabalhar através do Scrum é inspiradora e traz resultados concretos no desenvolvimento de produto. É importante ressaltar, entretanto, que embora seja o framework ágil mais famoso atualmente, não é o único, existindo outras opções com diferentes regras que podem ser igualmente vantajosas. Outro ponto fundamental é acrescentar que há diretrizes específicas a serem respeitadas, mas cada equipe deve usar o framework da forma que melhor lhe atender.
Muitas empresas e equipes que hoje passam por transformação digital com foco em agilidade têm dificuldade de incorporar esse estilo de trabalho, principalmente as que vieram de uma gestão de projeto “coisificada” e hierarquizada. Isso porque em time Scrum as pessoas são a prioridade e não existe hierarquia entre a equipe.
Como Product Owner, eu gosto de enfatizar que, embora numa tradução ao pé da letra esse cargo me coloque como “dona do produto”, isso não significa que eu tenha qualquer poder sobre a equipe ou sobre o produto em si. Pelo contrário, meu trabalho depende da equipe e minha atividade é garantir entrega de valor e priorização. Eu uso e recomendo o framework enfaticamente, além de ser uma grande defensora do Agile.
Você pode querer ler também:
