Guia scrum: tudo o que você precisa saber para a prática

Um breve guia sobre Scrum, a porta de entrada de muitas organizações no universo agile

O Scrum é uma metodologia ágil de desenvolvimento incremental e iterativo por meio da qual são produzidos e entregues softwares funcionais que os usuários amem.

Para muitas equipes e empresas, o Scrum é também a porta de entrada nos métodos ágeis. Pudera. Suas práticas e mecanismos não são difíceis de comunicar, nem de adotar pelos times.

Apesar de toda essa facilidade - ou justamente por causa dela -, não é raro que a adoção do Scrum se restrinja à simples aplicação irrefletida de suas funções, ferramentas e mecânica, passando ao largo dos valores que fundamentam a prática e, logo, do sucesso que se poderia obter dela.

Por isso, neste guia Scrum, reunimos os principais pontos sobre essa metodologia ágil: funções, mecânica e ferramentas em sua conexão com os valores do Scrum. Ao final, discutimos ainda por que surgem disso várias dificuldades de adotar o Scrum em sua plenitude e como contorná-las.

Time Scrum: funções e papéis principais

Todo projeto em Scrum tem três papéis: Product Owner, Scrum Master e time. Mas nem sempre esses papéis são atribuídos a pessoas específicas.

Vejamos cada um deles com mais detalhes.

1. Product Owner

O Product Owner (PO) é uma espécie de porta-voz dos negócios dentro do time. Ele compreende o que os stakeholders precisam e o que gera valor para eles e conecta esse conhecimento com a equipe, ajudando-a a focar no que precisa ser resolvido primeiro, no que é mais fácil de fazer e no que gera mais valor, mantendo e priorizando um product backlog, ou melhor, uma entrega efetiva e alinhada aos objetivos de negócio.

De forma geral, o gestor de projetos fala com os stakeholders, determina os requisitos, divide o trabalho, faz estimativas, atribui tarefas e constrói e cuida para manterem o cronograma e o plano.

No dia a dia, o PO também comanda a construção do backlog de produto. Mas ele não apenas entrega a lista de demanda para a equipe e fica esperando o sprint acabar.

Seu esforço diário é se certificar de que o time compreende tais objetivos e todos os detalhes sobre o que está construindo, apesar de quaisquer obstáculos que possam comprometer o trabalho, como mudanças de negócio, saída de membros etc. Ao final, é o PO que aprova cada item feito.

2. Scrum Master

O Scrum Master é um guia do projeto, que dá suporte e apoio a sua construção em comum com o time, assim como no bom uso do Scrum e de suas práticas. Mas ele não é dono do plano.

Na sua função está a diferença entre a gestão de projetos por comando-e-controle e em Scrum.

O Scrum parte da premissa de que, quando uma só pessoa detém a propriedade do plano, os demais membros do time lavam as mãos. Assim, o problema será todo do gestor, sobretudo quando o projeto estiver em dificuldades – o que vai acontecer em algum momento.

Sendo o responsável pela eficácia do Time Scrum, dentro do framework Scrum, este profissional é um verdadeiro líder que faz com que os membros melhorem suas práticas.

Isto é, de formas diferentes, o Scrum Master atende:

• O time, treinando e auxiliando os membros da equipe; 
• O dono do plano, ajudando a estabelecer o planejamento e facilitando a colaboração;
• A organização, liderando e orientando a empresa na adoção do Scrum.

3. Membros

A equipe que estará à frente da construção do projeto.

No Scrum, as equipes são pequenas, de 3 a 9 membros, mas devem sempre reunir todas as habilidades necessárias para produzir um projeto.

Saiba mais: Agile squads: quais os componentes-chaves e como são orquestrados?

Scrum: mecânica e práticas básicas

O Scrum não auxilia no processo de concepção do MVP de um produto, e sim depois dele, quando começa a execução. Para isso, ele engloba um conjunto básico de eventos ou cerimônias. Vejamos quais são elas.

Conheça a Lean Inception, o método de projeto do seu MVP em 5 dias:

1. Sprint

Sprint é uma iteração limitada no tempo. Normalmente tem 30 dias, mas isso pode variar: alguns times preferem iterações mais curtas, com duas ou três semanas, por exemplo.

2. Sprint planning

Reunião que precede cada sprint, feita pelo Scrum Master, PO e todo o time, a fim de determinar coletivamente que funcionalidades do backlog de produto serão construídas, com base nas necessidades dos usuários e no que gera valor. Seu resultado é um sprint backlog.

Entenda: 10 métricas ágeis que toda a squad precisa monitorar

Nessa reunião o Scrum Master trabalha com o time a fim de estimar tempo de execução, por meio de mecânicas como histórias dos usuários e story points - falaremos delas mais adiante -, e de decidir o que será feito por quem, baseado na disponibilidade e skills do time naquele momento.  

Nessa fase, não dá para cair em um hiperplanejamento. Atribuições, sequência e duração de tarefas são apenas estimativas. O tempo da maioria das atividades não pode ser bem estimado até que se comece a trabalhar nelas, por exemplo. É comum que gaps sejam descobertos ao longo do processo, originando novas tarefas. Pode ocorrer ainda que coisas que pareciam rápidas se tornem longas.

Por isso, muitas decisões necessariamente serão tomadas na daily scrum – que veremos abaixo.

Mesmo assim, o objetivo da sprint planning é chegar a um sprint backlog final, tão completo quanto possível, que deve ser acompanhado diariamente e visível para todo o time.

3. Daily Scrum

Reunião diária curta (15 minutos) para o time atualizar o progresso e discutir dificuldades por meio de três perguntas:

1. O que eu fiz desde a última daily?
2. O que eu vou fazer até a próxima daily?
3. Que obstáculos vão estar no meu caminho?

Como uma ferramenta para gerar transparência e visibilidade, a daily funciona para inspeção e adaptação. Primeiro, ela ajuda a identificar problemas, depois é uma oportunidade de tomar decisões e fazer adaptações de última hora, não previstas na sprint planning. Assim, é mais uma maneira de resolver as coisas e de evitar perda de tempo em atividades erradas.

Mas atenção: a daily não é um ritual nem uma reunião diária de status burocrática. Todos os participantes precisam estar presentes e engajados. É muito fácil que a daily se torne uma cerimônia vazia, cuja razão de ser ninguém mais se lembra.

Veja: Scrum com Kanban: como aplicar o Scrunban

4. Sprint review

A sprint review é a reunião que encerra cada sprint. Nela, o software é demonstrado ao PO, a usuários e stakeholders. Ou seja, é aquele momento em que o time senta em frente dos usuários e stakeholders para, olho no olho, demonstrar o fez no sprint. Por isso, ela inclui apenas itens funcionais, isto é, finalizados, testados e aprovados pelo PO.

Aqui, também, são respondidas quaisquer perguntas e dados feedbacks, que podem originar mudanças que serão trabalhadas no próximo sprint.

Por isso, é uma bela oportunidade de gerar aprendizado validado. Afinal, um MVP precisa ser constantemente testado pelos usuários.

Leia também: MVP: o que é, por que fazer e como?

5. Sprint retrospective

A retrospectiva é a reunião do time ao final de cada sprint, para olhar para trás, analisar o que foi feito e tirar lições aprendidas, a fim de melhorar os próximos sprints e o desenvolvimento do software.

Duas perguntas são respondidas:

1. O que foi bem durante o sprint?
2. O que pode ser melhorado para o futuro?

Ferramentas do Scrum

1. Histórias de usuários

Um projeto é uma promessa que precisa atender as expectativas de seus stakeholders. Já vimos que envolvê-los tanto quanto possível é fundamental para que não haja um desalinhamento nesse sentido.

Apesar disso, um software deve ser útil para os usuários. Para isso, é preciso entender o que os usuários querem.

Esse aspecto – pelo sucesso do projeto – deve superar todos os demais. Então, a colaboração dos clientes é fundamental, acima do que diz o contrato, das expectativas de stakeholders, do desejo da equipe e tudo o mais.

Mas como se garante que o software tenha funcionalidades que os usuários usem e amem? Com esta ferramenta simples: as histórias dos usuários. Uma história dos usuários é basicamente uma descrição bem concisa de como um usuário vai usar o software.

Leia mais sobre como garantir produtos funcionais e que os usuários amem: Design sprint: o método do Google passo a passo

Três pontos ficam óbvios nessa descrição: quem é o usuário, o que o usuário quer fazer e por que ele quer fazer isso.

Histórias de usuários estão da base de backlogs de produtos, dando um norte a toda a construção do software.

2. Story points

Como determinar quanto trabalho pode ser feito em um sprint?

Os story points têm sido uma ferramenta efetiva para entender quanto esforço é necessário para construir uma história do usuário e para criar essa estimativa com base em pontos, que podem ser da sequência Fibonacci ou simplesmente ir de 1 a 5.

Ao longo dos sprints, coisas como média de pontos, refinamento das estimativas, podem ganhar melhor precisão e até ser gerenciados. Para isso, são utilizados os gráficos de burndown. Vamos falar deles abaixo.

3. Gráfico de burndown

Os gráficos de burndown são uma maneira de visualizar como a performance do sprint está progredindo em relação a outras, por meio da relação entre a execução de story points por dia do sprint.

4. Quadro de tarefas

O quadro de tarefas é a visualização física (ou eletrônica) do sprint backlog e de sua evolução ao longo do sprint.

Valores do Scrum

Então, para ser uma equipe Scrum basta designar um PO e um Scrum Master para uma equipe de mais ou menos sete pessoas, seguir essa mecânica e utilizar essas ferramentas?

Você conseguirá fazer tudo isso com facilidade, mas não poderá dizer que tem uma equipe Scrum. Por quê?

Para uma equipe Scrum ser efetiva, ela precisa, mais do que apenas seguir a mecânica do Scrum, entender seus valores e como eles fazem com que práticas e mecanismos resultem em melhores softwares. Trata-se do aspecto iterativo da metodologia.

Esses valores serão influenciados e influenciarão a cultura de toda a organização, dando embasamento às práticas. Por isso, agilistas e agile coaches consideram os valores do Scrum – e como eles impactam na cultura da organização – uma boa porta de entrada para a metodologia e também uma boa maneira de solucionar problemas com a adoção da metodologia.

Ken Schwaber enumera os cinco valores do Scrum no livro Agile Project Management with Scrum, compartilhados desde o desenvolvedor mais júnior da equipe até o líder técnico sênior, o Scrum Master e o Product Owner. Vamos vê-los abaixo.

Veja mais: Lean Thinking: um breve e completo guia

1. Compromisso: todos são donos do projeto

A decisão e o planejamento, em times Scrum, não são privilégios reservados a gestores, mas um compromisso de todos, o que requer que o time esteja mais do que apenas envolvido.

Quem está comprometido com o projeto e com o time não se restringe a executar as tarefas que lhe são atribuídas, mas coloca o sucesso da entrega e da equipe em primeiro plano. Isso significa que quaisquer problemas serão seus problemas – mesmo que não estejam no escopo de sua função imediata –, se for para entregar o melhor software possível para clientes e stakeholders.

Esse nível de comprometimento não se conquista facilmente – nem sequer com Scrum –, porque se trata de cultura. No dia a dia, por pragmatismo, pode ser mais fácil colocar o fardo de pensar sobre o projeto nas costas de outras pessoas. Muitas empresas, aliás, não esperam ou não desejam isso de seus times. E automaticamente, têm mais dificuldades de praticar o Scrum e tornar-se ágeis.

2. Abertura

Em times Scrum todos devem saber, a todo o momento, o que cada colega de trabalho está fazendo e como esse trabalho vai colaborar para o alcance dos objetivos do projeto. Essa abertura ou transparência está implicada na própria mecânica do Scrum: quadro de tarefas, daily scrum, sprint review, retrospectivas, etc.

Só que, em algum momento, mesmo times que se comunicam bem terão problemas com mal-entendidos e comunicação incompleta.

Saiba mais: Desafios do agile no home office

No limite, o apelo à transparência vai bater diretamente de frente com a rígida hierarquia, que depende da opacidade para sobreviver. Além disso, não é fácil abrir tudo para o time e, com isso, encarar de frente o compartilhamento da liderança e a emissão de pontos de vista diferentes “sem a devida permissão”.

Só uma vez que esses pontos são superados que o time consegue aproveitar os benefícios de ser uma caixa aberta.

3. Coragem

Comprometimento e abertura requerem coragem. Não à toa, ela está aqui, como o terceiro valor do Scrum. Mas, juntos, esses valores produzem mais do que coragem: eles dão força e autoconfiança à equipe.

4. Respeito

Não é raro que programadores não respeitem Product Owners, sobretudo por eles não necessariamente compreenderem a fundo todos os detalhes técnicos do produto.

Por isso, o respeito mútuo – aquele senso de camaradagem pautado não apenas na habilidade técnica, mas na certeza e na confiança de que o todo é mais do que a simples soma das partes – deve ser uma busca constante de Scrum Masters.

Quando existe respeito, o time tem a liberdade de falhar, de assumir suas dificuldades e de ajustar o caminho pelo qual executa seus planos. Tudo isso, sem essa necessidade de ficar apontando dedos para culpados.

5. Foco

Pelo período do sprint, o sprint backlog é o único trabalho do time. E, para entregá-lo, todos têm liberdade para fazer qualquer trabalho ou mudança que seja necessária.

Coisas como realizar várias tarefas ao mesmo tempo, fazer reuniões de comitês inúteis, realizar atividades irrelevantes ao projeto e dar apoio a outros projetos que não o principal são maneiras de deixar um time desfocado e distraído.

Dificuldades de implementar o Scrum

Embora a mecânica e até valores do Scrum sejam simples, conectá-los na prática é a grande dificuldade dos times e das organizações. A teoria e o conceito podem ser claros, mas a prática nem sempre decorre sem percalços.

É por isso que nem todos os times que praticam Scrum obtém dele todas as benesses prometidas.

Vejamos os obstáculos mais comuns a uma adoção plena do Scrum:

1. Valores do Scrum não alinhados com os valores organizacionais

Esse é o primeiro entrave à adoção do Scrum. Esse tipo de metodologia, quando prospera, altera profundamente estruturas organizacionais tradicionais, como os silos e a hierarquia rígida.

Se a organização não reforma tais modelos, ela cai em uma adoção apenas parcial ou mecânica do Scrum.

2. Sensação de perda de tempo com a mecânica

Não é incomum que as mecânicas do Scrum – como a daily – se tornem rituais vistos como perda de tempo por alguns membros do time.

Manter o engajamento, que será fruto da percepção de valor daquele processo, é um dos outros desafios da adoção do Scrum para Scrum Masters e POs.

3. Valorizar o elemento técnico sobre os objetivos de negócio

Muitos times pensam que a programação é a parte mais importante de um produto e, por isso, todo o resto deve estar subordinado à parte técnica.

Isso é comum, sobretudo, quando os times se estruturam em torno de profissionais da área técnica, com POs e gestores de projeto separados do time. Por consequência, a opinião deles pode ser desvalorizada pelo time, afetando a adoção do Scrum.

O agile coach: conectando práticas a valores no Scrum

Como vimos, adotar o Scrum não é simples. Há uma grande diferença entre a teoria do Scrum e a prática do Scrum, que exige uma mudança cultural, no nível dos valores, mais do que a adoção da mecânica. Vimos também as dificuldades que surgem disso.

Alguns times lidam com esse processo com a ajuda de um agile coach. Esse profissional vai acompanhar e oferecer suporte a todo o processo de adoção da metodologia.

Ele ajudará a equipe a compreender os valores do Scrum e a tomar parte deles, mas também a relacionar tais valores à cultura organizacional e a entender como as práticas decorrem deles.

Entenda como funciona a Consultoria de desenvolvimento de software

Scrum: a porta de entrada para a agilidade

Se você chegou até aqui, deve ter entendido por que o Scrum é a porta de entrada de muitos times para a agilidade.

Simples de entender e de aplicar, o Scrum parece natural em muitos aspectos. Mas essa simplicidade toda é apenas aparente. Também vimos os valores e as dificuldades que as organizações têm ao adotá-lo, da qual surge a necessidade de contar com agile coaches.