O mundo dos negócios mudou drasticamente nas últimas décadas e agora vivemos em uma sociedade conectada onde as mudanças são rápidas, constantes e imprevisíveis.
O mundo atual está cada vez mais volátil, incerto, complexo e ambíguo, é o que chamamos de Mundo VUCA. VUCA é um acrônimo para Volátil, Incerto, Complexo e Ambíguo (em inglês) muito utilizado no mundo dos negócios para refletir sobre mudanças imprevisíveis que afetam as empresas e a necessidade de novas habilidades e comportamentos para gerenciar nesse contexto.
Quais são as características do Mundo VUCA?
- [V] Volátil – a mudança é rápida e imprevisível em sua natureza.
- [U] Incerto – a causa de um evento e o efeito de um evento é desconhecido, o presente não é tão claro e o futuro é incerto.
- [C] Complexo – diferentes variáveis, partes interconectados e grande volume de informações causam confusão em todo o processo
- [A] Ambíguo – Falta de clareza e consciência sobre as situações, nada é mais tão claro.
Onde o Scrum é utilizado?
Scrum é um framework ágil muito útil para ambientes ou projetos complexos e com alto grau de incerteza.
Ele tem sido aplicado em empresas de diversos setores e tamanhos, sendo muito utilizado na gestão de empresas, projetos, rotina, marketing, operações, desenvolvimento de produtos e serviços, desenvolvimento de software e quase tudo que é utilizado no dia a dia das empresas.
Continue lendo esse artigo se você quiser saber tudo sobre esse framework ágil e como usar cada um deles no seu trabalho, empresa e até na sua vida pessoal.
Origem do Scrum
O Scrum foi inserido pela primeira vez em um artigo publicado pela The Harvard Business Review, em 1986. O artigo “The new new product development game” (ou “O novo jogo no desenvolvimento de novos produtos”), publicado em 1986 por Takeushi e Nonaka foi principal fonte de inspiração direta para a criação do framework Scrum.
O nome Scrum é uma analogia entre o jogo de rugby, gestão de projetos e desenvolvimento de produtos. No rugby, Scrum é uma formação para reposição de bola no jogo, sendo esta a inspiração para o nome do framework.
No início dos anos 90, o Scrum foi inicialmente desenvolvido para gerenciar e desenvolver produtos.
Seus criadores, Jeff Sutherland e Ken Schwaber, foram os responsáveis por organizar as ideias e práticas já existentes no desenvolvimento de software e criaram o framework propriamente dito, com regras, papéis, eventos e artefatos e um guia de como colocar em prática.
O que é Scrum?
Segundo o Guia Scrum 2020:
“Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos.”
Guia do Scrum 2020
Scrum não é um processo, técnica ou metodologia. Scrum é um framework, uma estrutura propositalmente “incompleta” (espaços “vazios”), onde você pode empregar processos, técnicas e metodologias.
Caso você não tenha entendido o que é um framework, imagine uma casa vazia, onde você tem as divisões de sala, cozinha, banheiro e quarto.
Dentro de cada cômodo, você tem objetivos claros, por exemplo: dentro do quarto você tem que dormir. No entanto, se você vai dormir em pé, em uma rede, uma cama, no chão, 8 ou 12 horas, não importa, desde que você durma.
Essa é a ideia de um framework. As paredes da casa formam uma estrutura com objetivos definidos, onde dentro de cada “espaço” você aplica as melhores técnicas, processos ou metodologias para atingir o seu objetivo.
Portanto, o Scrum não fornece instruções detalhadas ou um passo a passo de como as pessoas devem agir. Ao invés disso, o Guia Scrum orienta os relacionamentos e interações das pessoas.
Cada elemento do framework serve a um propósito específico que é essencial para o valor geral e os resultados obtidos com Scrum.
Teoria do Scrum
O Scrum é uma abordagem iterativa e incremental com o objetivo de otimizar a previsibilidade e controlar o risco do projeto.
Abordagem iterativa
É uma abordagem onde o progresso se dá através de repetições sucessivas de refinamento. O objetivo é melhorar de forma contínua o projeto, produto, serviço ou processo.
Abordagem incremental
Em uma abordagem incremental, o projeto, produto, serviço ou processo, é construído e entregue por partes, mini-projetos. O incremento é um conjunto ou subconjunto de funcionalidades completas, sendo que cada etapa da construção se inicia após a finalização do estágio anterior.
Otimização da Previsibilidade
O desenvolvimento iterativo e incremental de um produto ou serviço, por exemplo, acelera o aprendizado pois a cada entrega e interação com cliente o time aprende mais sobre as reais necessidades do cliente, entregando o que realmente o cliente precisa e irá gerar resultado, adaptando as soluções a cada iteração.
Controle de Risco
O maior entendimento sobre as reais necessidades do cliente reduz o risco de fazer algo que o cliente não comprar ou utilizar.
Ciclos mais curtos, por mais que gerem um resultado ruim, os custos serão baixos e os impactos no produto serão pequenos, pois o time “perderia” somente o esforço mal direcionado desta interação e os impactos seria sobre o incremento, não sobre o produto inteiro.
Scrum é baseado no empirismo e no lean thinking.
Empirismo
O Empirismo afirma que todo o conhecimento se origina da experiência prática e de tomada de decisões baseadas no que é conhecido.
Lean Thinking
O lean thinking reduz o desperdício e se concentra no essencial. Esse pensamento enxuto busca otimizar os processos reduzindo os desperdícios, controlando os riscos e maximizando o valor entregue ao cliente, ao mesmo tempo que, realiza entregas incrementais de forma iterativa.
Pilares Empíricos do Scrum
Transparência
O processo, as atividades e expectativas devem ser visíveis tanto para quem executa o trabalho quanto para quem recebe o trabalho.
Essa transparência e visibilidade do que está sendo construído e executado ajuda no alinhamento e na comunicação do time.
Normalmente essa transparência é implementada através de um Quadro de Tarefas comum e visível para todo o time. Nesse quadro todo o trabalho que será executado, está sendo executado e já foi executado, está visível, garantindo o alinhamento.
Além disso, esse quadro ajuda também na comunicação, garantindo uma linguagem comum para todo time. Há uma confusão natural nas empresas sobre o que é falado, o que é compreendido e o que é realmente executado.
Com um quadro comum e tarefas compartilhadas, todos estarão olhando para o mesmo item, evitando falhas na comunicação e no entendimento.
Implementada a transparência, ele permite que ocorra a inspeção.
Inspeção
Antes de qualquer definição, inspecionar não é microgerenciar ou controlar time e/ou tarefas.
Inspecionar no Scrum é uma verificação (check) rotineira do progresso em direção aos objetivos e metas acordadas pelo time. Essa inspeção deve ser feita de forma frequente e com atenção para detecção de possíveis problemas.
Essa inspeção normalmente se dá através dos Eventos do Scrum, projetos para provocar mudanças.
A inspeção permite a adaptação.
Adaptação
Se a inspeção identificar que o time não está caminhando em direção aos seus objetivos ou algum aspecto está fora dos limites aceitáveis, o processo deve ser adaptado.
O ajuste deve ser feito o mais rápido possível para minimizar os problemas.
Valores do Scrum
Os valores do Scrum são princípios que ajudam o time na maneira de agir e se relacionar.
São 5 valores:
Compromisso
Com as pessoas do time, com as entregas, com a qualidade do produto ou serviço e em atingir os objetivos acordados.
Foco
Foco no cliente, nos resultados e no melhor progresso possível em direção aos objetivos do time e do projeto
Abertura
O Scrum Team e os Stakeholders devem estar abertos quanto ao trabalho e os desafios que vão surgir, com o objetivo de estimular a transparência e gerar confiança no time.
Respeito
Pelas pessoas, time e empresa.
Coragem
De fazer a coisa certa, trabalhar em problemas difíceis e tomar decisões difíceis.
Time Scrum
O Scrum Team é multifuncional e autogerenciável, ou seja, os membros do Scrum Team possuem todas as habilidades necessárias para criar valor durante a Sprint e decidem internamente quem faz o que, quando e como.
O Scrum Team possui normalmente 10 pessoas ou menos. Ele deve ser pequeno o suficiente para permanecer ágil e grande suficiente para entregar trabalhos relevantes.
Por exemplo: “times” com 2 pessoas são pequenos e ágeis mas talvez não tenham todas as habilidades necessárias para fazer entregas relevantes a cada Sprint. Já um time com mais de 10 pessoas, provavelmente terá membros com as habilidades necessárias para fazer entregas relevantes, no entanto, a comunicação, alinhamento e produtividade desse time será prejudicada devido ao tamanho do time.
Dentro do Time Scrum não há cargos ou hierarquias, todo o Scrum Team é responsável por criar um Incremento valioso e útil a cada Sprint.
Dentro do time existem 3 responsabilidades:
- Developers
- Product Owner
- Scrum Master
Developers (Desenvolvedores)
Os Developers são os responsáveis pelo Scrum Team que vão criar qualquer aspecto de um Incremento utilizável dentro de uma Sprint.
Desenvolvedores não necessariamente são programadores ou da área de TI. Se você é uma pessoa de negócios e é responsável por mapear os processos da sua área e implementar os novos fluxos, você está desenvolvendo um Incremento para o negócio.
As habilidades dos Developers dependem de cada negócio, no entanto, existem algumas características que independem disso:
- Eles são os responsáveis pelo Backlog da Sprint (plano da Sprint);
- Eles garantem a qualidade das entregas aderindo a um definição de Pronto;
- Diariamente, durante a Sprint, eles adaptam seu plano em direção a Meta da Sprint.
Como os Developers são uma responsabilidade dentro do Scrum Team, eles também são multifuncionais e autogerenciáveis.
Product Owner (Dono do Produto)
O Product Owner é responsável por maximizar o valor do produto ou serviço resultante do trabalho do Scrum Team.
O P.O. é responsável também por gerenciar o Backlog do Produto de forma eficaz:
- Criar e comunicar claramente os itens do Backlog do Produto;
- Ordenar os itens do Backlog do Produto;
- Garantir a transparência, visibilidade e entendimento dos itens do Backlog do Produto;
O Dono do Produto é somente somente uma pessoa: para um Produto, existe apenas um Backlog do Produto e um Product Owner.
Ele(a) também é responsável por representar e se relacionar com os Stakeholders, partes interessadas no produto ou serviço.
Scrum Master
O Scrum Master é responsável pela adoção do Scrum de acordo com o Guia Scrum. Ele(a) garante que o Scrum Team e a Organização estão entendendo a teoria e como praticar o Scrum.
O S.M. é um líder servidor, servindo o Scrum Team, Product Owner e Organização:
- Ela(a) ajuda o Scrum Team removendo impedimentos.
- Ajuda o P.O. com técnicas, gerenciamento do Product Backlog, planejamento e facilitações.
- E ajuda a organização no treinamento e orientação na implementação do Scrum.
Eventos Scrum
Os Eventos Scrum são desenhados para permitir a transparência necessária para o time ter a oportunidade de inspecionar e adaptar os Artefatos.
Esses eventos criam uma rotina para o time, reduzindo a complexidade e eliminando a necessidade de outras reuniões.
Todos os eventos no Scrum são Time-box, ou seja, possuem uma duração máxima. Se esse tempo acabar não tem como ser resposto.
O Scrum possui ao todo 5 eventos: Sprint, Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
Sprint
A Sprint é o coração do Scrum. É uma grande caixa onde todos os eventos ocorrem dentro dela.
É dentro de cada Sprint que as ideias são transformadas em valor. O objetivo da Sprint é produzir um Incremento pronto para ser liberado que tenha pelo menos uma funcionalidade.
A Sprint possui uma duração de 1 mês ou menos. Sendo que uma Sprint começa imediatamente após a conclusão da Sprint anterior.
Ela permite a previsibilidade, garantindo a inspeção e adaptação das entregas do produto ou serviço em direção da meta.
Uma Sprint só pode ser cancelada pelo P.O. se a Meta da Sprint se tornar obsoleta por algum motivo.
Lembrando que não existe Sprint 0 ou Release Sprint ou tempo entre duas Sprints ou alguma razão para atrasar o início de uma nova Sprint.
Sprint Planning (Planejamento da Sprint)
O Planejamento da Sprint é o evento que inicia a Sprint e tem uma duração máxima de 8 horas para uma Sprint de um mês de duração.
Todo o Time Scrum participa dele, definindo todo o trabalho que será realizado durante a Sprint de forma colaborativa.
Durante o Planejamento da Sprint, todo o Time Scrum define a Meta da Sprint e, de forma colaborativa com o Dono do Produto, os Desenvolvedores selecionam os itens do Backlog do Produto que serão feitos durante a Sprint.
Para cada item selecionado do Backlog do Produto, os Desenvolvedores estimam todo o trabalho necessário para criar um Incremento que atenda à Definição de Pronto.
Somente os Desenvolvedores são responsáveis por estimar a selecionar os itens que serão trabalhados durante a Sprint, pois somente eles sabem da sua capacidade e como transforma os itens selecionados em incrementos de valor. O Dono do Produto pode influenciar os Desenvolvedores na sua seleção, mas a palavra final é deles.
Portanto, com a Meta da Sprint, os itens do Backlog do Produto selecionados e o plano para entregar, fica definido então o Backlog da Sprint (Sprint Backlog).
Daily Scrum
Após o Planejamento da Sprint acontecem as Reuniões Diárias (Daily Scrum). Este evento tem duração de 15 minutos para os Desenvolvedores, sendo realizado sempre no mesmo local e horário, durante os dias úteis da Sprint, para reduzir a complexidade.
Durante este evento, os Desenvolvedores irão inspecionar o progresso em direção a Meta da Sprint, verificando o que já foi feito e o que resta ainda, e adaptar o Backlog da Sprint se for necessário.
O Dono do Produto e o Scrum Master não são obrigados a participar das Reuniões Diárias, mas podem participar se desejarem ou se solicitado pelos Desenvolvedores. O Scrum Master deve só garantir que a reunião aconteça e seja realizada dentro dos 15 minutos de duração.
As Reuniões Diárias melhoram as comunicações entre os participantes, ajudam no entendimento compartilhado das prioridades e facilitam a identificação de possíveis problemas e a rápida tomada de decisão.
Sprint Review
A Revisão da Sprint é um evento de no máximo quatro horas para uma Sprint com duração de um mês. O propósito deste evento é inspecionar o que foi feito durante a Sprint.
Durante este evento, o Time Scrum e os Stakeholders realizam o que foi feito durante a Sprint e como eles estão caminhando em direção a Meta do Produto. Com isso, todos colaboram para ajustar o Backlog do Produto.
Sprint Retrospective
A retrospectiva da Sprint é um evento de no máximo 3 horas para uma Sprint com duração de um mês. O propósito deste evento é o Time Scrum planejar maneiras de se tornar um time melhor.
Todo o Time Scrum deve participar desse evento.
Durante esse evento, o Time Scrum discute melhores formas de se comunicar, melhores formas do time se relacionar, melhores práticas para o Planejamento da Sprint, discute sobre a Definição de Pronto, conversa sobre como melhores os processos e ferramentas … o time busca a cada Sprint entender seus pontos fortes e fracos e melhorar a cada interação.
As melhorias identificadas durante essa reunião devem ser resolvidas o mais rápido possível e podem ser colocadas no Sprint Backlog da próxima Sprint como uma tarefa do Time Scrum.
Artefatos do Scrum
Partindo de uma definição informal, nos estudos arqueológicos, os artefatos culturais são aqueles produzidos a partir do trabalho do ser humano. Estes objetos, normalmente, apresentam características que ajudam a identificar alguns aspectos de determinadas culturas.
Trazendo para o nosso contexto, os artefatos são a materialização do trabalho ou valor gerado pelo Time Scrum.
Todos os artefatos no Scrum são projetados para maximizar a transparência das informações e garantir que todos estejam alinhados sob a mesma base de comparação para inspecionar e adaptar o trabalho.
Backlog do Produto
O Backlog do Produto é uma lista ordenada e viva (sempre atualizada enquanto o produto existir) do que é necessário para melhorar o produto. Sendo ele a única fonte de todo trabalho realizado pelo Time Scrum.
Durante a Sprint o Time Scrum trabalha para detalhar mais os itens do Backlog do Produto, tornando-os mais detalhados e precisos, adicionando descrição, ordem e tamanho, entre outros. Esta atividade contínua é chamada de Product Backlog Refinement ou Grooming.
A Meta do Produto, uma visão de futuro sobre o produto, serve como objetivo de longo prazo para o Time Scrum. Ela está contida no Backlog do Produto.
Backlog da Sprint
O Backlog da Sprint é o conjunto de itens do Backlog do Produto que foi selecionado para Sprint.
O Backlog da Sprint é feito pelos Desenvolvedores. Ele é o plano que os Desenvolvedores executar durante a Sprint para atingir a Meta da Sprint.
Somente os Desenvolvedores podem atualizar a Backlog da Sprint conforme acharem necessário.
A Meta da Sprint é o único objetivo da Sprint, ajudando todo o Time Scrum a trabalhar junto com coerência e foco.
Caso os Desenvolvedores percebam que não conseguirão realizar todo o trabalho selecionado, eles devem colaborar com o Dono do Produto para rever e ajustar o Backlog da Sprint sem desviar da Meta da Sprint.
Incremento
O Incremento é a materialização do trabalho do Time Scrum no final da Sprint. Ele é um passo em direção a Meta do Produto.
Durante a Sprint podem ser criados vários Incrementos. O Time Scrum deve garantir que todos os Incrementos criados funcionem juntos e sejam adicionados aos Incrementos anteriores.
Todo Incremento deve atender a Definição de Pronto, uma definição formal do que deve ser atendido em termos de qualidade para o produto.
A Definição de Pronto garante um entendimento compartilhado sobre o que precisa ser feito, criando transparência para todo o processo.
Se uma empresa já possui uma Definição de Pronto, todos os Times Scrum devem segui-lá como padrão mínimo. Caso a empresa não possua uma Definição de Pronto, o Time Scrum deve criar uma Definição de Pronto.
Se houver vários Time Scrum trabalhando em um mesmo produto, eles devem definir e cumprir a mesma Definição de Pronto