Guia Scrum | 16. Escalando Scrum

O Time Scrum deve ser composto por até dez pessoas. Mas o que fazer quando um grupo maior de especialistas precisa trabalhar em um projeto? Ou se a organização decidir seguir uma forma ágil de gestão? Para resolver este problema, os desenvolvedores do Scrum propuseram [email protected] É uma arquitetura livre de escala para organizar equipes inteiras de acordo com os princípios do Scrum.

Escalando Scrum - índice:

1. Introdução
2. [e-mail protegido]
3. O Scrum dos Scrums
4. Problemas adicionais de dimensionamento e [protegido por e-mail]
5. Resumo

Introdução

Assim que uma organização cresce, novos tipos de problemas aparecem. Por exemplo, uma queda na eficácia do funcionário causada por estrutura interna complexa, difícil tomada de decisão ou definição de direção. As empresas que operam com agilidade no nível da pequena equipe de projeto geralmente procuram escalar.

Muitas empresas se saem bem sem escalar o Scrum. Mesmo que muitos times Scrum estejam rodando simultaneamente, eles não precisam de coordenação, pois os grupos operam independentemente. No entanto, isso não significa que seja um Scrum multi-time. A necessidade de dimensionamento surge apenas quando a maior parte da organização está trabalhando em um produto e pode sincronizar seus vários times Scrum de forma eficaz.

A maioria das organizações que adotam métodos de gerenciamento ágil em escala escolhe o modelo SAFE, ou Scaled Agile Framework. Hoje, no entanto, não vamos nos concentrar no SAFE , mas discutiremos um modelo diferente chamado [email protected] , pois de acordo com o 15º relatório State of Agile de 2021, é a segunda melhor escolha entre as empresas que optam pelo ágil.

[e-mail protegido]

Em 1996, os criadores do Scrum, Jeff Sutherland e Ken Schwaber, estavam trabalhando em um grande projeto. Enquanto faziam isso, eles estavam tendo problemas para manter equipes menores trabalhando em sincronia com Scrum. Eles criaram uma maneira de dimensioná-lo, que eles eventualmente chamaram de [email protected]

Análogo ao Guia oficial do Scrum foi o Guia [email protected] , que define essa forma de dimensionar o trabalho como:

Uma estrutura dentro da qual as redes de Times Scrum operam seguindo o Guia Scrum para resolver problemas adaptativos complexos e entregar produtos de forma criativa com o máximo de valor possível.

A premissa básica do [email protected] é simplicidade e eficiência. Portanto, sua operação é baseada em uma arquitetura livre de escala. Em outras palavras, ele usa o Scrum para dimensionar o Scrum. Desta forma, uma equipe scrum composta por indivíduos atuando como Product Owner, Scrum Master ou Desenvolvedor torna-se o Scrum dos Scrums: uma equipe composta por equipes.

O Scrum dos Scrums

O Scrum of Scrums é uma equipe scrum com pessoas que assumem os papéis tradicionais do Scrum. No entanto, como a tarefa do Scrum de Scrums é integrar os resultados do trabalho de vários Times Scrum, ele precisa de postagens adicionais:

• Equipe do Product Owner – um grupo de Product Owners que se reúne para concordar com as prioridades e criar uma visão coesa do produto
• Chief Product Owner – Product Owner do Time Scrum ou uma pessoa que lida exclusivamente com o Scrum de Scrums
• Scrum of Scrums Master – a pessoa que supervisiona a eficácia do Scrum of Scrums.

Eles se reúnem nos mesmos eventos do Scrum e usam artefatos semelhantes.

Problemas adicionais de dimensionamento e [protegido por e-mail]

A arquitetura livre de escala do [email protected] significa que permite escalar mais de uma vez. Se uma organização precisa coordenar equipes em uma escala ainda maior, ela pode configurar o Scrum of Scrums.

No entanto, escalar o Scrum, como qualquer outra metodologia de gestão, tem suas falhas e, neste caso, são semelhantes às dos times básicos do Scrum, só que proporcionalmente maiores. É por isso que recomendamos trabalhar os detalhes da colaboração dentro de cada Time Scrum antes de iniciar o Scrum em uma escala maior. Sugerimos dimensionar o Scrum para equipes experientes que tenham um bom conhecimento e compreensão dos valores e funcionamento do Scrum.

Escalando Scrum - resumo

Escalar Scrum não é brincadeira de criança. Requer que os times Scrum apliquem proficientemente os princípios do Scrum e sincronizem suas tarefas com outros times Scrum. Portanto, a pergunta básica a ser respondida é: o dimensionamento é necessário? Só porque existem muitos times Scrum em uma organização não significa automaticamente que coordená-los trará melhores resultados.

Se uma organização optar por aumentar o Scrum, ela ganha uma arquitetura livre de escala que pode ser aumentada com sucesso ainda mais. No entanto, cada aumento é acompanhado por um aumento no nível de complexidade com o qual a equipe do Product Owner, o Chief Product Owner e o Scrum of Scrums Master devem lidar.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Ver todas as postagens

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto