3.7 Como escalar o Scrum

Os elementos obrigatórios do Scrum foram descritos, bem como as regras para jogar o jogo do Scrum, as regras que unem coesamente esses elementos. As regras permanecem consistentes e são independentes da escala em que o Scrum é organizado.

Scrum promove a simplicidade. O Scrum promove a responsabilidade clara e a colaboração de pares para lidar com a imprevisibilidade e formular respostas a problemas complexos.

A simplicidade, a responsabilidade e a colaboração bottom-up não estavam no cerne de muitas empresas ao escalar suas organizações e seu trabalho sobre o paradigma industrial. O principal desafio ao escalar o Scrum não está no encaixe do Scrum nas estruturas existentes, mas sim na revisão das estruturas existentes por meio de uma compreensão, implementação e crescimento bottom-up do Scrum, mantendo as regras básicas do jogo intactas e respeitando-as. Adaptar a organização ao Scrum, não o contrário.

Existem algumas táticas que permitem que o Scrum seja jogado em uma escala maior, dependendo do contexto.

3.7.1 Scrum de Um time (“Single-team Scrum”)

A situação mais simples para entregar produto com Scrum é ter um Product Backlog expressando os desejos para o produto e ter um time entregando incrementos de produto em Sprints com time-box.

O Development Team tem todas as habilidades para transformar vários itens de Product Backlog em um incremento lançável de produto por Sprint, guiado pela Definição de Pronto. O Development Team gerencia seu trabalho de forma autônoma através do Sprint Backlog e garantem direção e alinhamento por meio da Daily Scrum. O Product Owner fornece esclarecimentos funcionais e de negócios no tempo certo. O Scrum Master treina, facilita e serve o time e a organização.

O único time é o Scrum Team, tendo um Product Owner, um Development Team e um Scrum Master. A fim de prover as funções do produto que fornecem valor ao usuário de ponta-a-ponta, o Development Team é o que normalmente é chamado de um “feature team”.

O maior desafio reside em ter todas as habilidades de desenvolvimento colaborando como um time. Mas se esse problema estiver superado, a Sprint Review é totalmente transparente, um importante pré-requisito para fazer a abordagem empírica do Scrum funcionar. O time usa a Sprint Retrospective para melhorar a si mesmo.

3.7.2 Scrum de Vários Times (“Multi-team Scrum”)

Para produtos maiores ou resultados mais rápidos, a necessidade de criar e lançar um produto com vários times pode emergir.

Os vários times entregam um só produto. Eles trabalham no mesmo Product Backlog. O sistema coletivo possui um Product Owner, vários Development Teams e um ou mais Scrum Masters. Cada Development Team cria seu Sprint Backlog para trabalhar a partir da previsão. Cada Development Team se auto adapta através da Daily Scrum e assegura a integração do trabalho com os outros Development Teams.

A necessidade por transparência total na Sprint Review permanece, transparência completa sobre a versão do produto como lançado ou potencialmente lançável. Os Incrementos de Produto não podem ter trabalho não-finalizado escondido deixado para trás. No entanto, os múltiplos times estão construindo conjuntamente o mesmo produto. Apenas um Incremento totalmente integrado assegura ao Product Owner e aos stakeholders total transparência.

Os múltiplos times se auto organizam, dentro dos limites das regras e princípios do Scrum. Ao trabalhar num conceito de Múltiplos Times Scrum, ou seja, várias equipes que criam e sustentam o mesmo produto, os times se organizam na expectativa de criar um incremento integrado até o fim da Sprint.

Comunicação regular através dos múltiplos times é necessária, durante toda a Sprint, para alinhar os planos de trabalho do time com o objetivo de criar um Incremento integrado. Os times entendem o princípio e propósito da Daily Scrum a um nível inter-equipes e organizam eventos Scrum-of-Scrums.

A fim de manter o todo otimizado, o Scrum-of-Scrums acontece antes das Daily Scrums individuais. Os representantes mais apropriados dos Development Teams se reúnem para trocar informações de desenvolvimento, centrando-se principalmente no estado de integração do produto. Posteriormente, cada Development Team pode otimizar o planejamento e ajustar os Sprint Backlogs individuais dentro do ecossistema multi-time. Como resultado, os múltiplos times otimizam o seu progresso conjunto para um incremento integrado de produto, o mais tardar ao final de cada Sprint. O Incremento tecnicamente saudável pode ser liberado após a avaliação do Product Owner considerando se tem o nível funcional correto, não prejudicado por demandas de desenvolvimento em aberto ou desconhecidas, ainda a serem realizadas.

Os múltiplos times trabalham pelos mesmos critérios de qualidade para o produto como expressos na Definição de Pronto. Os múltiplos times podem achar mais fácil trabalhar em Sprints do mesmo tamanho, para simplificar planejamento, integração, lançamento e revisão do trabalho. Serão previstas tarefas adicionais nos Sprint Backlogs individuais para manter o trabalho integrado e saudável.

A fim de trabalhar em Sprints de diferentes tamanhos, um acordo claro e políticas são cruciais para assegurar que todo o trabalho será mantido integrado continuamente, uma política da árvore verde que tem precedência em todos os momentos. Se alguma coisa quebra o todo, é imprescindível que isso seja corrigido primeiro. Como resultado, cada time individual ou cada combinado de times (potencialmente independente) pode derivar um incremento lançável da base de código compartilhada. Sprint Reviews compartilhadas ainda fazem muito sentido.

Todas as responsabilidades definidas pelo Scrum são cumpridas. O todo do sistema é reconhecidamente Scrum. Para entregar incrementos de produto que proveem o valor ao usuário do início ao fim, o todo é um “feature system”. Independente da composição dos times individuais, eles coletivamente entregam incrementos integrados de produto, o mais tardar até o fim de uma Sprint.

3.7.3 Scrum de Vários Produtos (“Multi-product

Scrum”)

De acordo com a interdependência funcional ou técnica de vários produtos, pode haver a necessidade do planejamento e implementação dos mesmos serem alinhados e sincronizados.

Cada produto tem um Product Owner. Para cada produto existe um Product Backlog com um ou vários times para criá-lo, entregá-lo e mantê-lo. Cada ecossistema de produto é um Scrum de time único ou uma instância Scrum de vários times.

Das responsabilidades do Scrum, está claro que alinhamento e sincronização primariamente acontecem ao nível dos Product Backlogs por meio dos respectivos Product Owners. Product Backlogs individuais são adicionalmente ordenados sobre a otimização da linha de produtos, a suíte de produtos, considerações de programa ou portfólio. Os Product Owners, auxiliados pela organização, gerenciam incrementalmente seus Product Backlogs com base em informações compartilhadas e em progresso compartilhado.

As dependências técnicas e de desenvolvimento são tratadas dentro da Sprint pelos Development Teams dos diferentes hubs de produtos num espírito em rede, não hierárquico.

OceanofPDF.com 4. O estado futuro do Scrum