Como implementar scrum em sua empresa: Passo a passo

Se você deseja implementar o Scrum em sua empresa ou esteja tendo problemas para agilizar os processos internos, este artigo é para vai te ajudar muito.

Sobre a Popularidade do Scrum

Que implementar Scrum é uma febre entre praticamente todas as Startups e diversas empresas em ramos tradicionais, todos já sabemos.

Mas caso ainda deseje implementar o Scrum em sua empresa ou esteja tendo problemas com a mudança para ele, este artigo é para você!

Primeiro, por que eu deveria implementar Scrum em minha empresa?

Digamos que você é um gerente de projetos ou um gerente estratégico da empresa onde trabalha e seus projetos tem constantes atrasos ou remarcações de deadlines, e quando conseguem terminar o trabalho, demoram para saber se as features ou funções novas que foram implementadas realmente surtem o efeito desejado nos clientes que você deseja que sejam impactados por aquilo.

Você faz tudo como o livro manda, estuda os pré-requisitos necessários para realizar a tarefa, estuda a disponibilidade de membros nas suas equipes, realiza as estimativas do tempo e recursos necessários para implementar a mudança, mas por algum motivo, sempre acaba tendo atrasos e a funcionalidade nem sempre é o que os clientes realmente querem. A causa desses problemas provavelmente não é de responsabilidade dos seus times, que não entregam no prazo, a causa deles muito provavelmente é pelo método utilizado para gerenciar o trabalho deles. Então, você decide implementar Scrum. E foi por isso que, no começo da década de 1990, foi criado o Scrum.Esta metodologia foi criada juntando-se alguns conceitos de Lean e desenvolvimento iterativo, com o intuito de, a cada Sprint (um período de tempo fixado entre 1 a 4 semanas, normalmente) fosse entregue valor e testados as novas ferramentas ou features e atualmente é usada em cerca de 60% dos projetos que se utilizam das metodologias ágeis de desenvolvimento.“Ok, eu entendi o que é e quero implementar Scrum em minha empresa, como eu faço?”Simples, siga este guia e você, passo a passo, estará implementando esta metodologia em seus times, um por um, até que tenha uma empresa completamente ágil!

Não comece tentando aplicar em toda a empresa de uma vez!

Este passo pode parecer controverso, já que, se todos falam que é uma ótima metodologia para se trabalhar. Por que não implementar Scrum diretamente em todos os setores da minha empresa?A resposta é: EXPERIÊNCIA!

Quando se inicia o processo de transição de um modelo tradicional de gerenciamento para o Scrum, tanto os times quanto os gestores não costumam ter experiência em trabalhar com o novo modelo, e nós não desejamos perder a produtividade até que se adequem, não é?

Então a nossa dica, como experientes nisso, é: comece implementando alguns princípios, pouco a pouco, em uma equipe específica que esteja disposta a mudar o modelo de trabalho atual para um mais efetivo e, depois de ver os resultados, siga implementando outros princípios até que aquela equipe esteja realizando as boas práticas da metodologia Scrum.

Defina um Product Owner (PO) para a sua equipe

Você não precisa contratar alguém novo para a sua equipe para ser seu Product Owner, com o pensamento de começar tudo por um teste, o membro mais experiente na área (não necessariamente o mais antigo) pode ser o PO.

A função do PO é a de ser a voz do cliente dentro do time. Ele será o responsável por criar as tarefas a serem realizadas, descrever os critérios de aceitação delas (para o time saber quando a tarefa está efetivamente pronta) e priorizá-las por quais gerarão mais valor aos clientes e é o único que tem o poder de dizer se a tarefa gera o valor necessário ou não. Ele é dono do Produto, não do processo.

Para se ter um bom PO, procuramos uma pessoa que tenha maior contato com os stakeholders, conseguindo assim ter uma ideia maior de o que vai gerar valor para estes, além de ter uma elevada habilidade de comunicação, para que todos os membros entendam o que é a entrega de cada tarefa.

Defina um Scrum Master para a sua equipe

Pronto, você já tem sua equipe e seu PO, mas quem vai direcionar o time para que realizem o trabalho com as melhores práticas para você implementar Scrum?

É aí que entra a figura do Scrum Master, um líder-servidor que tem como função de auxiliar o time para que estes sigam as melhores práticas do Scrum, tornando o trabalho mais relevante e ágil!

“Calma, mas o que é um líder-servidor?”

Um líder servidor é aquele que permite que haja no time um sistema de cooperação mútua e contínua, no qual o líder e a equipe tem o mesmo poder de fala e influência nas decisões, possibilitando a adoção de práticas e políticas mais eficientes.

“E como o Scrum Master deve agir para atingir isso?”

Valorizando as ideias e opiniões do time ao incentivar a inovação e a criatividade, fortalecendo o respeito pelas diferenças e construindo relações de confiança. Possuindo um poder de persuasão elevado, através do poder de comunicação e do questionamento. Reconhecendo as necessidades, de forma de manter a gestão alinhada ao que realmente importa. Identificando e preparando outros líderes servidores dentro da própria equipe, de modo a torná-la mais independente e pensando no indivíduo de forma completa, não apenas profissional, percebendo e agindo diante de problemas e necessidades pessoais.

Criar um Backlog com todas as tarefas que podem gerar valor

Agora, com todas as funções determinadas, é hora de começar a pensar o que a equipe pode fazer que traria valor aos clientes ou leads da empresa.

Futuramente, esta será uma função principalmente realizada pelo PO, criando tarefas e definindo objetivamente a partir de qual momento elas poderão ser consideradas como “prontas”. Mas inicialmente, principalmente por inexperiência do PO em sua nova função, é comum utilizar uma reunião de Brainstorming com os membros para que se defina, e documente, tudo que pode gerar valor de alguma maneira a quem queremos atingir.

Neste momento, não precisa se focar em qual ordem as tarefas deverão ser realizadas, só tentem extrair tudo o que for possível dentro da criatividade e conhecimento da equipe e do PO sobre geração de valor.

Ordenar o Backlog em ordem de valor

Ok, neste momento nós já temos as funções de cada membro determinadas e uma lista de tarefas a fazer, e agora?

Dentro do framework do Scrum, a prioridade de realização das tarefas deve ser realizada pensando: “O que vai gerar mais valor/impacto para quem estou tentando atingir?”. Assim como no ponto anterior, futuramente esta função vai ser principalmente do PO, mas como aqui ainda estamos mostrando como implementar Scrum e às vezes você pode não ter tanta experiência com ela, em um primeiro momento podemos (e devemos) utilizar os conhecimentos de todo o time com o intuito de definir quais atividades vão gerar mais impacto para que se alcance os objetivos do time.

Definir a duração de um Sprint

“Calma, o que É um Sprint?”.Um Sprint é um evento time-boxed (de duração pré determinada e imutável) em que o time realizará as tarefas do Backlog e as entregarão para a aprovação do PO de acordo com as definições de “pronto” que foram definidas durante a criação deste Backlog.

Um Sprint normalmente tem duração de 1 a 4 semanas, e este tempo é determinado pensando em: “Em quanto tempo conseguiremos gerar valor real aos nossos alvos (clientes, leads, etc)?”. Normalmente, Sprints mais curtos são utilizados para times com maior incerteza e com maior ocorrência de tarefas não planejadas, como chamados de clientes e outras situações necessárias de serem resolvidas e que não podem ser deixadas para depois.

Por exemplo, um time de Customer Success, que frequentemente recebe chamados de clientes, é um time com mais incerteza do que um time de Marketing, logo, normalmente tem Sprints com menor duração.

Estimar o tamanho das tarefas

Neste ponto surge uma das principais diferenças entre os métodos tradicionais de gerenciamento e das metodologias ágeis, como o Scrum.

Nas metodologias tradicionais, os gerentes de projeto se esforçam para tentar definir a quantidade de tempo que será necessária para que cada tarefa seja realizada.

Mas como diz o autor do livro “Scrum: a arte de fazer o dobro do trabalho na metade do tempo”, Jeff Sutherland, quando estimamos uma tarefa utilizando o método de horas, normalmente erramos em um grau de 4 vezes, para menos ou para mais.

Por exemplo, se estimamos que uma tarefa levará 2 horas para ficar pronta, o mais comum é que o tempo seja entre 30 minutos e 8 horas de duração, visto que não somos acostumados a realizar tais estimativas naturalmente. Ao implementar Scrum, nós preferimos utilizar dois métodos diferentes, os Story Points ou os T-Shirt Sizes.

Story Points

Ao estimar a duração de uma tarefa pelo método de Story Points, cada membro do time deverá ter acesso a um baralho de cartas com os números da sequência de Fibonacci (1, 2, 3, 5, 8, 13), escolher uma carta que, em seu entendimento, considera equivalente à quantidade de esforço necessária para a conclusão daquela tarefa e após todos terem escolhido, virar a carta para cima.

Caso haja uma diferença de mais de duas cartas, por exemplo, um membro votou que a tarefa tem tamanho 2, e outro votou que tem um tamanho 8 (3 cartas de diferença), cada um deve explicar a motivação que o levou a escolher a carta (um pode achar mais complicado pois não se lembrou de uma ferramenta que ajuda, ou o outro pode achar a tarefa menos complexa do que realmente é por inexperiência, etc), e assim se realiza uma nova rodada de votação com o objetivo de o time estar mais alinhado e chegar em números mais próximos.

Após a rodada ser efetuada, faz-se uma média simples de todos os números de Story Points que foram escolhidos. Exemplo: Matheus achou que a tarefa tinha uma complexidade 3, Ana votou por 5 e João votou por 3. Soma-se os resultados (3+5+3 = 11) e se divide pelo número de participantes da reunião (11/3 = 3,67).

T-Shirt Sizes

Esta é a maneira que mais recomendamos que seja utilizada para times que estão iniciando suas jornadas de implementar Scrum, pois é mais simples de se entender e chegar em um consenso. Por este método, utilizaremos tamanhos de camisa (PP, P, M, G, GG, XGG), sendo que cada membro terá um baralho com estes tamanhos e votará, da mesma maneira, na complexidade que considera aquela tarefa (tarefas pouco complexas são PP, enquanto tarefas super complexas são XGG).Assim como no exemplo anterior, caso haja uma diferença de mais de 2 cartas entre membros, deverá ser realizada uma explicação pelos membros que votaram nos tamanhos mais discrepantes, a fim de se chegar a um consenso mais próximo.

Após realizar a rodada, utilizaremos os números da sequência de Fibonacci para representar cada tamanho de camisa (PP = 1; P = 2; M = 3; G = 5; GG = 8; XGG = 13) e realizaremos uma média para saber quantos pontos aquela tarefa “vale”.

Exemplo: Matheus achou que a tarefa tinha uma complexidade M, Ana votou por G e João votou por M. Transforma-se estes T-shirt Sizes em números, soma-se os resultados (3+5+3 = 11) e se divide pelo número de participantes da reunião (11/3 = 3,67).

Importante: Caso haja consentimento unânime de que uma tarefa é XGG, deve-se quebrar esta tarefa em outras menores que sejam possíveis de serem atingidas durante um Sprint.

Planeje o seu primeiro Sprint

Nesta etapa, nós temos como objetivo determinar a quantidade de Story Points que o time conseguirá “consumir” durante o tempo do Sprint, além de deixar claras as Definições de “Pronto” para todos os que participarão do Sprint.

Como para um primeiro Sprint nós não temos dados sobre a performance do time anteriormente, recomendamos uma abordagem diferente para ele. Não defina a quantidade de tarefas ou Story Points como objetivo, e sim a conclusão do máximo possível delas.

Realizando o primeiro Sprint desta maneira, nós teremos uma base para os próximos Sprints de quanto aquele time é capaz de produzir, e faremos o possível para aumentar estes números nos Sprints posteriores.

Caso o time tenha uma velocidade muito acima do esperado, pode haver a necessidade de estimar o tamanho de tarefas que não foram estimadas antes. Se você observar que o time vai ultrapassar a quantidade de tarefas que foram estimadas, realize uma nova reunião (mais curta desta vez) para estimar algumas tarefas a mais.

Acompanhe o seu primeiro Sprint

Não basta ter definido as funções, priorizar tarefas, estimar o tamanho delas e começar efetivamente seu primeiro Sprint para dizer que você está utilizando o Scrum. Sendo um framework ágil de gerenciamento, devemos acompanhar o time para ajudar onde pudermos, e fazemos isso principalmente por meio de um evento chamado Daily Scrum.

Daily Scrum

O Daily Scrum consiste de uma reunião com tempo máximo definido de 15 minutos, nos quais cada integrante do time deve responder 3 perguntas simples:

  • O que você fez ONTEM para ajudar a equipe para concluir o objetivo do Sprint?
  • O que você vai fazer HOJE para ajudar a equipe para concluir o objetivo do Sprint?
  • Existe algum IMPEDIMENTO para a equipe concluir o objetivo do Sprint?

O objetivo dessa reunião é alinhar o time para que cada um saiba o que os outros estão fazendo, saber em que ponto estão no Sprint.

Com essas informações, é possível ter noção de algumas coisas, como: “As tarefas serão concluídas a tempo?” e “Existe alguma oportunidade para ajudar os membros da equipe a superar seus obstáculos?

Revisão de Sprint (Sprint Review)

Chegando aqui, já passamos pela definição de funções, priorização e cálculo de estimativas das tarefas e por um Sprint inteiro! “Mas o que fazemos agora? Repetimos indefinidamente?”.

Não. nós devemos aperfeiçoar o processo para que a cada Sprint, tenhamos uma melhoria de produtividade em nossas equipes, e o primeiro passo para isso, é conduzir uma reunião de Revisão de Sprint com o time ao final do Sprint.

A reunião de Revisão de Sprint tem como objetivos validar o trabalho realizado e dar feedbacks sobre a qualidade das entregas, demonstrando na prática o que foi realizado durante a duração do Sprint. Ressaltando que aqui só é apresentado o que foi 100% realizado (cumprindo com as definições de “pronto”), pois nesta metodologia, dizemos que metade do trabalho feito é pior do que não ter feito nada, visto que foi despendido tempo na realização daquela tarefa, mas ela não gerou nenhum valor final, então o que ocorreu foi um desperdício.

É nesta reunião que o seu PO (Product Owner) vai dizer se as tarefas na coluna FEITO estão de acordo com os padrões de qualidade necessários para gerar valor ao cliente ou público alvo, tendo ele o poder de vetar quaisquer alterações realizadas pelo time.

Retrospectiva do Sprint

Nós não temos o poder de mudar os processos realizados no passado, mas sempre podemos aperfeiçoá-los para um melhor resultado no futuro.

Por querermos aumentar a produtividade do time, precisamos de feedbacks sobre o que deu certo e contribuiu para a agilidade do time durante o Sprint, para que possamos replicar estes comportamentos nos próximos Sprints, assim como o que deu errado e prejudicou a agilidade do time, para que possamos fazer um plano de ação para não cometermos os mesmos erros.

É importante se lembrar que nessa reunião nós não queremos achar culpados ou campeões, mas sim processos benéficos e processos maléficos. É aqui que conseguimos reajustar o rumo de um time para que as entregas futuras sejam sempre maiores do que as entregas passadas.

Para ajudar a guiar essa reunião, pode-se utilizar um modelo de 3 perguntas para saber onde é possível melhorar e o que devemos continuar realizando, são elas:

  • O que aconteceu durante esse Sprint que prejudicou a agilidade do time?
  • O que aconteceu durante esse Sprint que auxiliou na agilidade do time?
  • O que fez vocês felizes durante esse Sprint?

Com base nas respostas obtidas na Revisão do Sprint e na Retrospectiva do Sprint, deve-se criar um Plano de Ação para que possamos resolver os problemas que surgiram e replicar as ações que deram certo, alcançando assim a melhoria contínua desejada.