O que o Scrum pode fazer pelo seu time

Rita Lino
Creditas Tech
Published in
7 min readApr 2, 2019
O "S" no peito do Superman é de "Scrum"

Aqui na Creditas, os times de tecnologia valorizam muito o desenvolvimento de projetos através de metodologias ágeis. Isso porque elas se baseiam no manifesto ágil, uma filosofia que declara 4 valores principais:

  • Indivíduos e interações mais que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano

Por fim, essas metodologias acabam prezando por potencializar entregas de valor ao cliente de maneira colaborativa e otimizada. Geralmente, os nossos times acabam optando pela utilização do Scrum e/ou Kanban.

Scrum

O Scrum é um framework para gerenciamento de projetos e desenvolvimento ágil de software bastante prescritivo. Ele é focado em entregas incrementais de valor e os projetos são divididos em ciclos chamados Sprints. Cada Sprint tem um tempo de iteração de 1 a 4 semanas. O Scrum também possui alguns papéis específicos como o do Scrum Master e do Product Owner. Também faz parte dessa metodologia algumas cerimônias:

  • Daily: reunião diária de 15 minutos onde cada membro do time diz no que trabalhou no dia anterior, no que está trabalhando, e se há algum impedimento. O Scrum Master irá garantir que os impedimentos sejam removidos.
  • Planning: reunião de planejamento onde será definido quais tarefas do backlog (lista de funcionalidades a serem implementadas) serão priorizadas, com a ajuda do Product Owner, para entrar no backlog da próxima Sprint.
  • Review: reunião feita no final da Sprint onde o time apresenta as entregas feitas.
  • Retrospective: reunião também realizada no final da Sprint onde os membros da equipe fazem uma retrospectiva da Sprint para ver o que fizeram bem e o que poderiam melhorar.

Kanban

O Kanban é um método visual para controle de produção ou gestão de tarefas. Ele foi desenvolvido pelos japoneses da Toyota dentro do modo de produção Just In Time (JIT). O JIT é uma filosofia de trabalho que busca evitar o desperdício de estoque e garantir a qualidade do produto, enquanto o Kanban é uma ferramenta que auxilia esse controle. Ele funciona através de um quadro (Kanban Board) com colunas e cartões coloridos, onde na maioria das vezes, as colunas representam os status das tarefas enquanto os cartões representam as tarefas em si, sendo possível visualizar o andamento delas e oferecendo uma maior transparência do processo a todos os membros da equipe. Diferente do Scrum, o Kanban não possui papéis específicos, cerimônias específicas, nem time-boxes.

Mas qual é a melhor?

Apesar de parecer, a adoção de uma metodologia ágil não é uma receita de bolo que você deve seguir e que, na maioria das vezes, vai ter sucesso. Nem sempre o Scrum é o ideal a se utilizar, assim como o Kanban também não. Não existe melhor ou pior. Tudo depende do contexto do time, e é só depois de conhecê-lo que será possível definir o processo de trabalho que melhor se encaixa. Antes de decidir a metodologia é preciso levar em consideração alguns fatores:

  • Maturidade da equipe: O Kanban pode ser menos eficaz em equipes com pouca experiência no desenvolvimento e gestão de projetos justamente por impor poucas restrições. Nesse caso, o Scrum se torna mais apropriado porque suas práticas dão um auxílio maior ao time para que ele performe bem.
  • Tamanho da equipe: Enquanto o Kanban não estipula o número mínimo e máximo de membros na equipe, o Scrum é recomendado para equipes de 3 a 9 participantes.
  • Demandas da equipe: Se as prioridades da sua empresa mudam constantemente então talvez o Scrum não seja a melhor opção por trabalhar com o planejamento de tarefas a serem feitas em uma Sprint. O Kanban oferece uma maior liberdade à mudanças mas também dificulta planejamentos e previsibilidade.

Um case Creditas

Quando cheguei na Creditas, em novembro de 2018, entrei no time recém-formado de Mobile, eu e mais duas pessoas. Na época, já havia sido decidido que usaríamos o método Kanban, em partes porque a maioria dos times da empresa seguiam apenas com o Kanban e tudo corria bem para elas e, em outras, porque não foi enxergada a necessidade de adotarmos um método mais rigoroso como o Scrum. “Vai dar certo”, nós dissemos.

Não deu certo.

Nosso time se viu em um cenário onde não tínhamos objetivos bem definidos, com erros de previsibilidade e pouca vazão de entrega. Em 3 meses utilizando Kanban, entregamos apenas 8 tarefas com tempos de duração diversos que variavam entre 1 e 19 dias. Passávamos semanas sem fazer entregas de valor e tarefas que supostamente levariam 7 dias para serem feitas, às vezes levavam quase 20! Você pode ter uma melhor visualização da nossa vazão com o nosso Lead Time Histogram, que mostra quanto tempo nossas tarefas demoravam para ir do Backlog ao Done:

Gráfico de Lead Time referente ao período utilizando Kanban. Os intervalos de “lead time values (classes)” se referem a quantidade de dias e “frequency” a quantidade de tarefas.

Repensando os processos

A “liberdade” que o Kanban nos dava não foi adequada à nossa pouca experiência com métodos ágeis. Observando nossas métricas e com receio do time perder sua credibilidade nos comprometimentos, foi necessário repensar nosso processo de desenvolvimento.

Uma equipe inexperiente dificilmente vai conseguir lidar com a falta de regras, como é o caso do Kanban. Nesse caso, a opção mais adequada seria o Scrum por ter cerimônias específicas, papéis específicos e equipes auto-organizadas e multifuncionais, ou seja, que sejam capazes de projetar, planejar e executar as tarefas.

Outro fator que, no contexto dado, deu mais um ponto para o Scrum foi o fato de termos uma equipe com 3 pessoas, já que essa metodologia é recomendada para times de desenvolvimento de 3 a 9 pessoas.

Além disso, as Plannings e Refinings nos dariam uma percepção completa sobre o que deveríamos fazer e como fazer, ao mesmo passo que o tempo de iteração que o Scrum impõe através das Sprints faria com que tivéssemos um maior comprometimento com as entregas e uma reflexão maior sobre o tempo de desenvolvimento de cada tarefa.

E foi levando todos esses pontos em consideração que, por fim, decidimos não só adotar o Scrum como também manter o Kanban. Afinal, ele permite que todo o time (incluindo o Scrum Master e o Product Owner que ganhamos ao adotarmos o Scrum) tenha uma visão clara quanto ao andamento das tarefas. Também optamos por manter o WiP (Work in Progress), que se refere a quantidade de tarefas em execução ao mesmo tempo, o limitando a dois.

Depois da adoção

Após 1 mês utilizando Scrum, em Sprints com time-box (tempo de duração máximo) de duas semanas e seguindo todas as cerimônias (Daily, Planning, Refining, Review, Retrospective), esse foi o resultado que obtivemos:

  • 18 tarefas entregues
  • Duas Sprints completadas com sucesso
  • 225% de superação em relação ao desempenho que tivemos em 3 meses usando apenas Kanban
  • Reduzimos nosso tempo máximo de entrega de 19 para 9 dias

Você pode conferir nosso Lead Time Histogram, depois da adoção do Scrum, abaixo:

Gráfico de Lead Time referente ao período utilizando Scrum

Observe que, comparando com o Lead Time Histogram de quando usávamos Kanban, o valor máximo de itens que entregamos em determinados períodos de tempo estão entre 1 e 6, enquanto no Kanban a frequência era de 1 item.

Através do gráfico de Throughput (número médio de unidades processadas por unidade de tempo), também conseguimos ver o crescimento exponencial que tivemos a partir da semana que adotamos o Scrum (25/02).

Gráfico de Throughput que mostra um melhor desempenho das entregas a partir da adoção do Scrum (25/02–01/03)

Conclusão

Não existe método melhor ou pior que outro, você precisa escolher o mais adequado para sua situação e ver o que melhor se alinha com o contexto do time e com as expectativas da empresa. Acompanhe de perto os processos e resultados e tenha em mente que o que serve para um time hoje, pode deixar de servir em algum tempo, então será necessário rever a metodologia e sua necessidade.

Ainda utilizando o case apresentado, hoje temos um time muito mais motivado em cumprir as entregas, comprometido com os processos e preocupado em gerar resultados tanto para os clientes quanto para a empresa.

Pode ser que daqui a um tempo nosso time entre em um contexto onde vamos lidar com mudanças constantes, então as Sprints planejadas do Scrum não serão mais tão eficazes. Ou então, pode ser que o time se torne maduro o suficiente a ponto de não precisar de todas as cerimônias e papéis do Scrum, fazendo com que tiremos etapas do nosso processo.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” ― Antoine de Saint-Exupéry, Airman’s Odyssey

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.

--

--