Livro Scrum

Scrum
Como ele pode ajudar a cultura da sua equipe

Onde o Scrum vai impactar na cultura organizacional e no engajamento das pessoas?

Resolvi criar esse material sobre Scrum porque, há muitos anos atrás, foi através dele que tive meu primeiro contato com o mundo da gestão e desenvolvimento ágil de projetos. Ele surgiu e é muito utilizado no mundo de desenvolvimento de software, mas ele também é utilizado em diversos tipos de trabalho diferentes, por vários tipos de empresa.

O Scrum me ajudou muito a enxergar que várias coisas em que eu acreditava não funcionavam mais, era necessário uma outra forma de pensar. A estrutura de trabalho do Scrum pode trazer vários benefícios ao resultado do seu trabalho e também para seus clientes.

Se a equipe entender os benefícios que o Scrum pode trazer, e conseguir extrair o melhor dele na prática, pode apostar que essa equipe vai entregar um produto que atende melhor as necessidades dos clientes, desenvolvido muito provavelmente com esforço otimizado pela própria equipe.

Claro, entregar o maior valor para o cliente é o principal para qualquer negócio, mas uma coisa que me chama atenção na estrutura do Scrum são os Sábios da Gestão Moderna que ele ajuda a fortalecer na cultura de trabalho da equipe.

O Scrum é bastante difundido em desenvolvimento de software, mas podemos pensar nele como uma estrutura para gerenciar qualquer processo.

Vou descrever o Scrum da forma mais simples possível, para que você possa entendê-lo mesmo que nunca tenha tido nenhum contato com esse framework anteriormente.

Sugiro a leitura deste material para quem:

  • Tenha ouvido falar de Scrum e tenha curiosidade de entender em mais detalhes;
  • Queira introduzir na cultura da sua equipe o reforço diário de ideias como empoderamento, propósito, transparência, confiança e colaboração;
  • Faça parte de um time que desenvolve software ainda em formato cascata;
  • Deseja entender como o Scrum pode ajudar a aumentar o valor entregue para o seu cliente;
  • Não é da área de software e deseja conhecer uma forma de entrar no mundo ágil;

Como você está lendo é sinal que possui interesse no assunto, então vamos lá.

Sugestão para leitura

Scrum - A Arte de Fazer o Dobro do Trabalho na Metade do Tempo

Após a leitura deste texto, que procurei deixar bem completo, caso você queira se aprofundar ainda mais, minha sugestão seria você fazer como eu e acessar direto a fonte: Jeff Sutherland, um dos criadores do Scrum.

Todo o conteúdo abaixo é baseado nas experiências práticas que tive introduzindo e facilitando o Scrum nas equipes com que trabalhei, e também no conhecimento que adquiri com a leitura deste livro. Dessa forma acredito que esse texto que elaborei contém tudo o que você precisa para começar a trabalhar com Scrum, mas recomendo muito que você faça a leitura do livro Scrum - A Arte de fazer o dobro do trabalho na metade do tempo caso queira se aprofundar ainda mais.

Índice de Conteúdo

Sumário

Uma forma pouco eficiente de se fazer as coisas

Scrum foi criado por Ken Schwaber e Jeff Sutherland há mais de 20 anos atrás, como uma alternativa mais rápida, confiável e eficiente de desenvolver software.

Nessa época praticamente todo projeto de desenvolvimento de software utilizava o formato cascata.

Scrum Formato Cascata

Chamamos de formato cascata quando o projeto é concluído em etapas distintas, passo a passo, até finalmente chegar na mão dos usuários ou clientes.

Esse tipo de processo normalmente resulta em grandes atrasos de planejamento, é lento, e muitas vezes resulta em um produto que as pessoas não querem ou não estão dispostas a pagar.

Por qual motivo fazemos planejamento gigantes? Por que tentamos prever todas as situações futuras possíveis para um projeto?

Talvez por que a ideia de ter todo o trabalho a ser feito em um novo projeto, esmiuçado com datas de início e fim, seja muito tentadora.

Mas infelizmente ela não funciona!

Esses planos caem por terra tão logo o projeto se depara com a realidade. Ou assim era, até surgir o Scrum.

Uma forma mais eficiente de se fazer as coisas

O termo Scrum vem do esporte, do rúgbi mais precisamente, se referindo a maneira como um time se une para avançar a bola pelo campo.

Na essência, o Scrum se baseia em uma ideia simples.

  • Quando iniciamos um projeto, por que não verificar em intervalos regulares se ele está indo no caminho certo?
  • Por que não verificar periodicamente se aquilo é realmente o que as pessoas querem?
  • E por que não se perguntar se é possível melhorar a forma como se está trabalhando, com o objetivo de obter resultados mais rápidos e melhores?

O Scrum pode ser usado em qualquer tipo de projeto, desde fabricação de carros, gerenciamento de fast food, construção de foguetes, até mesmo na organização de um casamento.

Segundo Jeff Sutherland, ele criou o Scrum para ser uma estrutura onde fosse possível colocar os valores do Manifesto Ágil em prática.

Fiz abaixo uma imagem da estrutura básica do Scrum como exemplo, não se preocupe pois vou detalhar melhor tudo isso.

Estrutura-Scrum

Benefícios que o Scrum entrega para a sua equipe

Posso dizer que o Scrum é totalmente voltado para equipes, na minha opinião somente isso já é uma coisa muito boa. Não gosto de abordagens onde a gestão se concentra apenas nos indivíduos, ainda mais quando a produção é um trabalho em equipe. 

A ideia é que as equipes Scrum ideais possuam não mais do que 7 integrantes, podendo variar em no máximo 2 para menos ou 2 para mais.

O Scrum vai ajudar a formar equipes que sejam transcendentes, autônomas e multifuncionais.

Equipes que tenham uma noção de propósito que vai além do comum. Esse objetivo autoconcebido permite ultrapassar o básico e alcançar o extraordinário. 

Quantas vezes você já teve que realizar um trabalho sem saber exatamente o motivo?

Equipes auto-organizadas, que se auto-gerenciam, podem decidir como executar o trabalho e tem o poder de fazer com que suas decisões sejam respeitadas.

Se você está pensando em fortalecer sua Cultura Organizacional, lembre-se que uma excelente equipe precisa poder decidir como concretizar as metas que foram estabelecidas.

Um dos conceitos chaves do Scrum é que os integrantes da equipe decidam sozinhos como irão trabalhar.

A responsabilidade da definição dos objetivos estratégicos fica a cargo da gerência, mas é incumbência da equipe decidir como atingir esses objetivos.

Outro ponto importante no Scrum é que a equipe tenha as competências necessárias para conseguir realizar todo o trabalho.

Em uma situação cascata podem existir várias equipes, uma responsável por cada parte do projeto. Nesse tipo de formato o projeto somente é entregue quando passar por todas as etapas realizadas por diferentes especialistas, mas nenhuma dessas equipes é capaz de finalizar o produto por conta própria.

No Scrum em vez de manter equipes separadas por especialistas que quase nunca trocam informações, existe uma equipe multifuncional que tem as habilidades necessárias para executar o trabalho de forma completa, do inicio ao fim.

O Quadro Scrum

As equipes Scrum costumam utilizar gestão visual para deixar claro o fluxo de suas atividades.

Veja no simples exemplo que fiz abaixo, onde o quadro Scrum possui três status para as tarefas: A Fazer, Fazendo e Feito.

Quadro Scrum - ágil para equipes ágeis

A utilização do quadro permite que todos os integrantes da equipe possam ver exatamente quanto trabalho precisa ser feito na sprint, o status de cada atividade e quem está trabalhando nela. Isso gera uma transparência muito grande.

O backlog é onde ficam todas as atividades, ele pode conter centenas de itens ou apenas os próximos a serem trabalhados. Uma coisa muito importante, nem tudo que está no backlog será realmente realizado.

  • Como então tratar essa situação?
  • Temos muitos itens de trabalho no backlog, como a equipe sabe o que realizar primeiro?
  • O que impacta mais o negócio? Quais são mais importantes para o cliente? Qual trará mais resultado?

No Scrum existe um papel responsável por isso.

Scrum: O papel de Product Owner

Scrum Backlog - ágil para equipes ágeis
Crédito da imagem: Thea Schukken

Uma das principais diferenças entre o Scrum e o Método Kanban é que enquanto o Método Kanban não altera os papéis já existentes na equipe, o Scrum trás com ele alguns papéis necessários.

O papel de Product Owner, como o próprio nome já diz é quem controla o backlog do produto. Ele decide o que entra no backlog, e como ele é priorizado, porém não atua como um gerente da equipe, na verdade ele é quem precisa estar disponível para a equipe.

O Product Owner deve conhecer a fundo a necessidade do cliente e deve servir como uma ponte entre o cliente e a equipe, passando feedback para a equipe a cada entrega de sprint.

O cliente nesse caso é quem irá receber o valor daquilo que é feito pela equipe.

O Product Owner precisa ser alguém que consiga se colocar no lugar de quem receberá o valor produzido.

Ele é quem deve saber qual é a visão do produto e deve trabalhar para ajudar a equipe a alcançá-la, estando sempre disponível, explicando o que precisa ser feito e por quê.

Scrum: O papel de Scrum Master

Scrum Master - ágil para equipes ágeis
Crédito da imagem: Thea Schukken

O Scrum Master é quem garante que o processo funcione.

Acho importante ressaltar que estamos falando de um líder aqui e não de um gerente com status superior a equipe.

Alguém para conduzir todas as reuniões, se certificar de que houve transparência e, o mais importante, ajudar a equipe a descobrir o que está atrapalhando o andamento do trabalho.

É tarefa do Scrum Master guiar a equipe em direção ao aperfeiçoamento contínuo, perguntar regularmente:

Como podemos fazer melhor aquilo que fazemos?

Sprint, a essência do Scrum

Scrum Sprint - ágil para equipes ágeis
Crédito da imagem: Thea Schukken

Um dos maiores erros que podemos cometer em um projeto é desenvolvê-lo sem receber feedback sobre o que estamos fazendo. Quanto mais tempo ficamos sem saber se estamos no caminho certo, maior será o tempo desperdiçado.

Todos nós já ouvimos histórias de projetos que iniciaram seu desenvolvimento como sendo uma excelente ideia, mas quando finalizados não eram mais necessários.

Eles existem aos montes!

O tempo passa, as coisas mudam, o contexto muda, as necessidades mudam, aquilo que o cliente antes tinha certeza, já não tem mais.

Eu posso dizer que feedback constante não é aconselhável, é uma necessidade. Quanto mais cedo você receber feedback sobre o trabalho, mais rápido você pode saber se o que você está fazendo vai ser útil para alguém.

Sprint é a forma com que o Scrum aborda isso.

Segundo um dos criadores, Jeff Sutherland, foi batizado de Sprint para remeter a intensidade. A ideia é trabalhar a todo o vapor durante um curto período de tempo e então parar para verificar em que ponto se encontra.

As sprints precisam ter uma duração definida, não se faz uma sprint com duração de uma semana e depois uma com três semanas. É preciso ser coerente. O ritmo de trabalho é essencial, para que com o tempo, as pessoas descubram quanto conseguem fazer nesse tempo e busquem melhorar.

Uma das coisas que o Scrum coloca como crucial é que após a equipe se comprometer com aquilo que será feito durante o sprint, nada mais pode ser acrescentado por alguém de fora da equipe.

Daily Scrum – Revisão diária é a chave

Daily Scrum - ágil para equipes ágeis
Crédito da imagem: Thea Schukken

A comunicação diária de uma equipe Scrum é muito importante, ela deve ocorrer a todo momento, porém existe um momento onde isso é feito de forma oficial no Scrum.

Existem algumas boas práticas para a cerimônia diária, ou “Daily Scrum” , como por exemplo, todos os integrantes do time devem estar presentes.

Para que seja possível estabelecer um ritmo regular para a equipe, é importante que independente da hora selecionada, a cerimônia diária ocorra sempre no mesmo horário. Outra coisa importante, essa reunião não deve ser demorada, o tempo ideal de duração tem que ser no máximo de uns 15 minutos.

O Scrum coloca como importante que essa reunião seja feita em pé justamente por isso. É uma forma de evitar divagações e conversas desnecessárias.

Para incentivar que todos participem da conversa, a ideia é que cada integrante da equipe responda 3 perguntas:

  • O que foi feito desde a última vez que nos falamos?
  • O que será feito antes da nossa próxima reunião?
  • Quais dificuldades estão sendo enfrentadas?

O erro mais comum da Daily Scrum

Um dos problemas mais comuns, e que por experiência já vi acontecer, é quando a equipe trata essas perguntas como um relatório individual.

Fiz isso, vou fazer aquilo, próximo..

Esse problema é muito comum de ocorrer, a passividade ou comportamento preguiçoso de integrantes da equipe pode atrapalhar o desempenho do resto do grupo. Dessa forma é preciso estar atento para identificar e eliminar esses comportamentos.

Essa reunião serve para a equipe debater rapidamente como alcançar o objetivo. É preciso sair dela sabendo quais são as coisas mais importantes a serem realizadas naquele dia de trabalho.

É preciso interagir, se uma pessoa fala que determinada tarefa levará o dia, outra pode saber como fazê-la em menos tempo. Se alguém tem um problema, outros podem saber como ajudar.

A equipe precisa ter a vontade de querer ser excelente!

Essa é uma reunião estratégica, um comportamento robótico ou apenas de prestação de contas não acrescenta em nada aos objetivos da reunião.

Cartas de Planning Poker Scrum

Faça o Download do Template aqui!

Somos ruins em estimar quanto tempo algo vai levar

Se você já tentou estimar quanto tempo uma atividade vai levar já sabe que nós, os seres humanos, não somos bons nisso. Mas somos bons em fazer comparações, comparar um tamanho com outro, por exemplo. Quando você olha uma camiseta tamanho M e uma tamanho G você consegue dizer a diferença.

O Scrum sabendo disso nos apresenta uma forma que pode ser muito mais útil de se estimar uma atividade sem a necessidade de ser 100% exato. Isso é feito utilizando a sequência de Fibonacci, quando usamos a sequência de Fibonacci para comparar quanto tempo vamos levar para terminar uma tarefa, isso nos permite não ser 100% exatos.

Não precisamos saber a diferença de um 5 para um 6, seria muito pequena para identificarmos, mas temos ideia se uma tarefa é um 5 ou um 8 por exemplo, comparando com outras que já fizemos.

Usando esses números podemos obter a opinião de todos os integrantes da equipe sobre o tamanho de uma atividade usando aproximadamente a mesma escala de medida.

Como saber se minha atividade é um 3 ou um 8? E se não houver consenso? E se alguém estimar errado?

Scrum: O Pôquer do Planejamento

O Scrum nos ajuda na árdua tarefa de estimar utilizando uma prática muito criativa chamada de pôquer do planejamento (planning poker).

A ideia é simples, cada integrante do time utiliza um baralho de cartas contendo os números da Sequência de Fibonacci: 1, 2, 3, 5, 8, 13 etc.  Veja no exemplo acima que utilizei números redondos a partir do 13 apenas para facilitar.

Caso tenha interesse faça o download do arquivo contendo as cartas para impressão do Baralho  para Planning Poker Scrum ao final desta página.

Uma tarefa é avaliada por vez, cada integrante do grupo separa a carta que considera corresponder  a tarefa e coloca virada para baixo na mesa. Na sequência todos devem mostrar a sua carta selecionada ao mesmo tempo, isso evita que alguém seja influenciado pela escolha do outro. 

É importante lembrar que nesse momento não devemos estimar em horas, já falamos como nós seres humanos não conseguimos fazer isso com precisão. Estamos utilizando pontos para comparar as coisas de modo relativo, da mesma forma que fazemos quando estamos comparando dois tamanhos de camiseta por exemplo.

Outro ponto importante é que toda a equipe participa, compartilhando conhecimento e opinião. É essencial que a estimativa seja feita por quem irá realizar o trabalho e não por uma pessoa considerada “ideal”.

Ao final da sprint saberemos quantos pontos a equipe fez, isso vai servir de base para a próxima. Não precisamos saber quantas horas uma atividade vai levar.

Casos de divergência na estimativa

Quando as cartas selecionadas pelos integrantes forem muito distantes uma das outras, quem selecionou a mais alta e a mais baixa deve explicar seu raciocínio para os demais. Dessa forma é realizada outra rodada.

Quando as cartas selecionadas são próximas em até 2 números (3, 5 e 8 por exemplo), a equipe pode somar e fazer a média para ter o resultado.

Tratar estimativa dessa forma deixa claro que se trata apenas disso, uma estimativa e não um cronograma detalhado que não condiz com a realidade.

Scrum: Histórias de Usuário

No Scrum tratamos os itens de trabalho como histórias.

Quando estamos fazendo um trabalho, nem todos da equipe possuem o mesmo conhecimento sobre o motivo de cada atividade ser realizada. Muitas vezes não estamos envolvidos com tudo de forma a saber qual é o resultado desejado.

Quantas vezes em seu trabalho você já teve que fazer tarefas e não sabia o motivo? Aposto que algumas.

Dessa forma é preciso deixar claro todas as informações necessárias para que o trabalho seja realizado. O Scrum faz isso através de narrativas chamadas histórias.

Já ficou provado que as pessoas tem muita facilidade em entender o que precisa ser feito quando conseguem compreender intimamente as motivações, desejos e personagens envolvidos.

Estrutura-História-de-Usuário

Para que possamos estimar com mais facilidade é essencial que o escopo das histórias seja o menor possível. 

Um exemplo errado de história seria o seguinte:

Como líder, quero uma empresa onde todos amem trabalhar, para criarmos as coisas mais incríveis possíveis.

Essa narrativa sem dúvida resume muito bem o propósito da Amo Onde Trabalho, mas é uma narrativa com escopo muito grande, não saberíamos por onde começar. 

Abaixo um exemplo mais correto. 

História-de-Usuário-Frente

Repare que essas atividades possuem o escopo em um tamanho ideal para que a equipe execute como achar melhor.

É possível debater sobre elas, não dizem Como fazermas podemos colocá-las em prática.

Também é comum adicionarmos critérios de aceitação no verso do cartão, para sabermos se estamos entregando o valor necessário, veja um exemplo a seguir.

História-de-Usuário-Critérios-de-Aceitação-2

Quando o Épico entra no jogo

Como líder, quero uma empresa onde todos amem trabalhar, para que possamos criar as coisas mais incríveis possíveis.

Essa narrativa anterior com escopo muito grande poderia ser o conjunto de histórias, que quando reunidas, poderiam se tornar a ideia de uma empresa com uma cultura organizacional excelente.

Chamamos isso de Épico.

Scrum – O Planejamento da Sprint

Scrum - Planejamento - ágil para equipes ágeis
Crédito da imagem: Thea Schukken

Essa é a reunião onde fazemos o planejamento, dessa forma ela ocorre uma vez por sprint.

Durante a reunião de planejamento de sprint, o Product Owner descreve os recursos de maior prioridade para a equipe utilizando as histórias.

A equipe toda tem então a oportunidade de fazer perguntas suficientes para transformar uma história de usuário de alto nível, que está no backlog do produto, em tarefas mais detalhadas que vão entrar na sprint.

A equipe precisa sair dessa reunião com dois artefatos definidos:

  • Um objetivo para a sprint
  • Um backlog de itens selecionados para entrar na sprint

Todos precisam saber qual o objetivo, e facilita também na hora de reportar aquilo que está sendo feito para quem está fora da sprint. Outros interessados não precisam ouvir detalhes sobre cada item do backlog do produto (história do usuário).

Já o backlog da sprint é uma lista dos itens de backlog do produto que a equipe se compromete a fazer durante a sprint.

Um ponto importante que reforço aqui, a equipe é quem seleciona quanto trabalho eles podem fazer, isso não é determinado pelo Product Owner.

Qual a velocidade do seu time?

Vamos considerar que nossa sprint tenha uma semana de duração.

Quando ela for finalizada iremos saber quantos pontos o time conseguiu fazer, isso nos dá uma ideia de qual é a velocidade do time.

A partir daí podemos trabalhar para otimizar e chegar na velocidade desejada no decorrer de outras sprints, coletando feedback e fazendo ajustes.

A equipe pode fazer isso na reunião de retrospectiva da sprint com apoio do Scrum Master.

Scrum – A Revisão da Sprint

Scrum Revisão - ágil para equipes ágeis
Crédito da imagem: Thea Schukken

Ao final de cada sprint a equipe faz uma reunião chamada de Revisão da Sprint. É o momento para o time mostrar o que foi feito durante a sprint e avaliar se os objetivos foram atingidos.

O legal dessa reunião é que além da participação do Product Owner, do time e do Scrum Master, é possível que outros interessados participem também. Como por exemplo a gestão da empresaclientes integrantes de outros times e projetos.

Lembre-se de que não é necessário que a equipe tenha completado cada um dos itens trazidos para fazer parte da Sprint.

O importante mesmo é que a equipe tenha atingido o objetivo geral definido para a sprint.

Scrum – A Retrospectiva

Uma parte importante do Scrum é a melhoria contínua.

Qual a pequena mudança que podemos fazer nesse momento que trará uma melhoria para a próxima sprint?

Ao final de uma sprint já temos uma imagem de como as coisas foram, o que funcionou, o que não deu certo, onde podemos fazer alguma melhoria.

O foco da reunião de retrospectiva deve ser o que podemos melhorar no processo, não é o foco fazer reclamações ou apontar culpados. Acredite, já vi isso se tornar comum em equipes que trabalhei quando o ambiente não tinha a confiança necessária.

Problemas podem ser discutidos desde que o foco seja a equipe e não o indivíduo. É importante que todos tenham a oportunidade de dar sua opinião sobre um possível problema.

Outra coisa que vi acontecer bastante é a equipe levantar vários problemas ocorridos e não traçar ações para corrigir os problemas na próxima sprint. Nesses casos, com o tempo, a reunião acaba virando apenas um momento para lamentações, dessa forma é necessário que o Scrum Master fique atento a isso.

Scrum – Dicas para começar

Essa é a pessoa que tem a visão daquilo que a equipe irá desenvolver.

Ele precisa entender os riscos e também qual o maior valor a ser entregue, precisa ter a paixão pela visão daquilo que se busca.

Quem serão as pessoas que vão realizar o trabalho.

Uma coisa importante que já mencionei antes, a equipe selecionada precisa ter todas as habilidades necessárias para poder realizar a visão que o Product Owner possui.

Times de 5 a 7 pessoas são o ideal, mas não é uma regra, você pode tentar com menos ou mais pessoas.

Essa pessoa vai precisar saber bem como funciona a estrutura do Scrum, pois será ela que irá treinar os demais.

Também deverá ajudar a eliminar obstáculos e facilitar as cerimônias durante o dia a dia de trabalho.

Será necessário ter uma lista daquilo que é necessário fazer para que a visão do Product Owner se torne realidade.

Esse backlog deve ser atualizado durante todo o tempo. É muito importante que ele sempre esteja ordenado de acordo com as prioridades do Product Owner.

Product Owner deverá definir e tomar decisões sobre como realizar a priorização dos itens do backlog.

Essa atividade precisa ser realizada pelas pessoas que de fato irão trabalhar nos itens. 

É a equipe também que deverá identificar se algum item solicitado pelo Product Owner não pode ser realizado por algum motivo.

É importante que todos da equipem tenham a mesma definição daquilo que é considerado feito.

Quais são os critérios de aceitação? A tarefa está entregando o valor que se propõe?

Não estime em horas, será muito difícil ser assertivo. Utilize o Planning Poker para ter um tamanho relativo para cada tarefa.

O planejamento é a primeira cerimônia do Scrum. Todos precisam participar, a equipe,  o Scrum Master e o Product Owner.

Vimos antes que a Sprint precisa ter uma duração determinada, e é importante que ela seja sempre a mesma. Dessa forma é possível acompanhar a velocidade da equipe. Minha sugestão é que a Sprint tenha de 1 a 2 semanas de duração no máximo, mas novamente, não é uma regra. 

Na hora de incluir histórias na sprint a equipe precisa ter uma ideia de quantos pontos é possível fazer no decorrer do período da sprint. Conforme sprints forem sendo feitas existirá um histórico para usar como base.

sprint precisa ter uma meta! Todos da equipe precisam saber como os itens da sprint irão contribuir para a visão do produto se tornar real.

É necessário tornar o trabalho visível para todos, a melhor forma de fazer isso é utilizando um quadro, que podemos chamar de quadro Scrum.

No Scrum utilizamos apenas 3 colunas para o fluxo do trabalho: A Fazer, Fazendo e Feito.

Também é comum uma coluna para o backlog, conforme no exemplo que mostrei anteriormente.

Os post-its irão servir para representar os itens de trabalho.

A cerimônia diária, que deve ocorrer sempre no mesmo horário, será o lugar para deixar toda a equipe ficar por dentro do que está sendo feito. Isso é feito com todos participando e informando a equipe.

  • O que foi feito ontem para ajudar a equipe no objetivo da sprint?
  • O que será feito hoje para atingir o objetivo?
  • Existe algum obstáculo impedindo que o objetivo da sprint seja atingido?

Essa cerimônia deve durar no máximo 15 minutos, todos em pé ajuda na hora de ser objetivo. 

Evite comportamentos robóticos, imagine essa reunião como o intervalo de um jogo de futebol, onde a equipe tem 15 minutos para melhorar sua estratégia para o jogo.

Revisão da Sprint é o momento para que a equipe apresente aquilo que foi realizado durante a sprint.

Todos podem participar, inclusive interessados que não façam parte do time, como os próprios clientes e gestão da empresa.

Importante: se algum item de trabalho não atendeu aos critérios de feito, não está concluído, deve ficar fora da apresentação.

Utilize as Retrospectivas da Sprint para pensar no que deu certo, no que deu errado e principalmente, o que pode melhorar para as próximas sprints.

Não é o momento de apontar culpados, sempre pense no que pode ser feito para melhorar o resultado do time como um todo. 

No final da retrospectiva o Scrum Master e o time devem ter chego a um acordo sobre qual é a melhoria a ser realizada durante o próximo ciclo.

Como o Scrum vai ajudar no fortalecimento dos Sábios da Gestão Moderna

Microgerenciamento Vs Confiança

Como essa prática fortalece a Confiança?

A utilização do Scrum fornece a equipe a possibilidade de escolher a forma como deseja trabalhar para atingir o objetivo proposto para a sprint. A própria equipe se compromete com o trabalho a ser realizado no início de cada sprint, não existe necessidade de realizar microgerenciamentos pois todas as informações sobre o andamento das atividades estão visíveis a todo o momento no Quadro Scrum. A própria equipe é quem realiza as checagens e tratamento de problemas relacionados ao trabalho.

Como essa prática fortalece a Colaboração?

Como mencionei antes, o Scrum é totalmente voltado para equipes, dessa forma a Colaboração é essencial. Não gosto de abordagens onde a gestão se concentra apenas nos indivíduos, ainda mais quando a produção é um trabalho em equipe. Utilizando o Scrum a Colaboração será reforçada diariamente na cultura da sua equipe.

Como essa prática fortalece a Transparência?

Uma das principais vantagens por trás da gestão visual é a Transparência, e o Scrum fornece isso através do seu quadro. Outro ponto importante é a Transparência que o Scrum fornece a todos os interessados no trabalho que está sendo feito, suas cerimônias consistem em trazer transparência durante todas as etapas, inclusive para o próprios clientes.

Como essa prática fortalece o Empoderamento?

A equipe vai se sentir empoderada pois ela vai participar de todo o processo ativamente, dando sua opinião, ajudando a estimar e resolvendo problemas. O comprometimento com as atividades que serão desenvolvidas é realizado no começo da sprint e a própria equipe se coordena para escolher a melhor forma de realizar o trabalho.

Como essa prática fortalece o Propósito?

Toda a sprint deve ter um objetivo, uma meta, um propósito. Esse objetivo deve ficar visível durante o trabalho, tornando claro para todos onde as atividades que estão sendo realizadas durante a sprint estão impactando nos objetivos maiores da equipe. Isso é muito importante para que as pessoas não se tornem apenas executoras de atividades.

Finalizando

Você pode fazer o download das cartas para o Planning Poker Scrum ao final da página.

Como descrevi anteriormente, o Scrum teve origem no mundo de desenvolvimento de software, porém hoje ele é utilizado em uma infinidade de outros ambientes de trabalho.

O Scrum pode trazer resultados importantes ao seu trabalho, ajudando a equipe a entregar maior valor aos seus clientes, otimizando o time para que consiga entregar o trabalho mais rapidamente.

Mas não esqueça que além do resultado para o cliente, o Scrum também estará reforçando comportamentos diariamente, e são esses comportamentos que formam a cultura do seu time ou empresa.

Empoderamento, Propósito, Transparência, Confiança, Colaboração.

Espero que tenha gostado das dicas e também da leitura. 

Um grande abraço e até a próxima!

Cartas de Planning Poker Scrum

Faça o Download do Template aqui!

Contribuição de:

Teste grátis nossa plataforma com a sua equipe por 7 dias, sem custos, sem cartão de crédito.

Aprenda a construir uma cultura que valorize sua marca, resolva os problemas de gestão, melhore os resultados dos negócios e atenda ao propósito da sua organização.

Os templates e ferramentas são exclusivos para usuários da nossa Plataforma de Cultura, Engajamento e Experiência Humana no Trabalho.

Faça uma análise gratuita do seu engajamento e da cultura da sua equipe de trabalho!

Faça um tour pela Amo Onde Trabalho totalmente de graça, conheça como a plataforma funciona e quais os benefícios que ela pode trazer para a sua equipe de trabalho!

Conheça, não custa nada :)

Está gostando desse conteúdo? Temos uma dica para você!

Faça uma análise gratuita do seu engajamento e da cultura da sua equipe de trabalho!

Faça um tour pela Amo Onde Trabalho totalmente de graça, conheça como a plataforma funciona e quais os benefícios que ela pode trazer para a sua equipe de trabalho!

Conheça, não custa nada :)

× Fale com a gente!