Scrum
O Scrum é uma estrutura ágil que ajuda as equipas a lidar com trabalho complexo em ciclos curtos e iterativos, através de papéis, eventos e artefactos fixos.
O Scrum é uma estrutura ágil para desenvolver e gerir produtos complexos, moldada originalmente no desenvolvimento de software e hoje usada em muitas indústrias. Assenta na ideia de controlo empírico do processo: em vez de planear uma tarefa do início ao fim à partida, uma equipa trabalha em janelas de tempo curtas e fixas, chamadas sprints, tipicamente de uma a quatro semanas. Cada sprint termina com um incremento de trabalho utilizável, o que cria espaço para feedback e permite à equipa ajustar os próximos passos. Essa combinação de transparência, inspeção e adaptação torna o Scrum adequado para trabalho em que os requisitos são incertos ou suscetíveis de mudar.
O Scrum define três papéis fixos. O product owner é responsável pelo valor do produto e mantém o product backlog, uma lista priorizada de tudo o que precisa de ser feito. O scrum master mantém a equipa a trabalhar dentro da estrutura, remove obstáculos e facilita a colaboração sem atribuir tarefas diretamente. A equipa de desenvolvimento planeia e executa o trabalho por conta própria. Quatro eventos recorrentes dão estrutura a cada sprint: o sprint planning no início, a daily scrum para alinhamento rápido, o sprint review para mostrar o que foi construído e a sprint retrospective para melhorar a forma como a equipa trabalha em conjunto.
O Scrum funciona melhor em tarefas em que o âmbito ou a solução não estão totalmente claros à partida, como o desenvolvimento de produto ou projetos complexos com muitas partes interessadas. Distingue-se do Kanban pelas suas janelas de tempo fixas e papéis definidos, enquanto o Kanban assenta mais num fluxo contínuo sem iterações definidas. Em comparação com o planeamento clássico em cascata, a sua vantagem é a inspeção regular: falhas de avaliação surgem cedo, em vez de apenas no final do projeto. Na prática, o Scrum tende a falhar não por causa da estrutura em si, mas por uma execução pouco empenhada, por exemplo quando as retrospetivas são saltadas ou o backlog fica por manter.
Exemplo pratico
Uma empresa de construção de máquinas de média dimensão está a desenvolver um novo software para monitorizar o seu equipamento de produção. A equipa de cinco pessoas trabalha em sprints de duas semanas: no início de cada sprint, escolhe os dez itens mais importantes de cerca de 40 entradas abertas no backlog, alinhando-se diariamente numa daily scrum de 15 minutos. Ao fim de dez sprints, cinco meses depois, uma primeira versão utilizável está pronta, em vez dos nove meses de desenvolvimento sem qualquer resultado intermédio que a equipa tinha originalmente planeado. As retrospetivas revelam que requisitos pouco claros custaram à equipa cerca de 20% da sua capacidade durante os três primeiros sprints, pelo que o product owner passa a escrever descrições de backlog mais precisas a partir daí.
Como a Leanshift ajuda
No fundo, a sprint retrospective é apenas um ciclo Kaizen recorrente: a equipa faz uma pausa, olha honestamente para o trabalho acabado de concluir e introduz deliberadamente uma melhoria na forma como trabalha, antes de continuar. Isto encaixa na visão da Leanshift de que a melhoria não é um projeto pontual, mas um hábito regular integrado no trabalho do dia a dia. As equipas que vivem desta forma não melhoram apenas o produto, constroem mais pessoas que sabem melhorar as coisas por conta própria.
Perguntas frequentes
O Scrum só é útil para o desenvolvimento de software?
Não. O Scrum começou no desenvolvimento de software, mas é hoje usado no marketing, no desenvolvimento de produto, na educação e noutras áreas, sempre que o trabalho é complexo e os requisitos podem mudar pelo caminho.
Em que difere o Scrum do Kanban?
O Scrum funciona em janelas de tempo fixas, chamadas sprints, com papéis e eventos definidos, enquanto o Kanban visualiza um fluxo contínuo de trabalho sem iterações definidas e foca-se em limitar quanto trabalho está em curso ao mesmo tempo.
Uma equipa pequena precisa mesmo de um scrum master dedicado?
Não necessariamente como função a tempo inteiro. Em equipas pequenas, alguém assume-a frequentemente a par do seu trabalho normal; o que importa é que a facilitação e a própria estrutura sejam efetivamente respeitadas.