---

Como Escalar o Scrum Framework (Projetos Scrum Distribuídos e de Grande Dimensão)? Isto Pode Surpreendê-lo!

O Scrum Framework, tal como descrito até agora, funciona melhor para uma única Equipa Scrum num único local. Contudo, na realidade, uma só equipa frequentemente não consegue implementar um projeto na totalidade, ou os seus membros precisam de estar distribuídos por vários locais.

Quando uma equipa não consegue responder às necessidades do produto, a organização pode considerar equipas adicionais. A distribuição geográfica, por si só, não exige mais equipas, e acrescentar pessoas pode aumentar os custos de coordenação. Em muitos casos, também observamos equipas distribuídas por locais ou continentes geograficamente distantes.

Existem várias razões que motivam as organizações a distribuir as equipas por diferentes locais:

• Razões Técnicas: Alguns conhecimentos necessários para construir componentes específicos do software não estão disponíveis localmente na sede,
• Razões de Especialização: Algumas capacidades relativas a diferentes atividades de engenharia de software não estão disponíveis localmente. Por exemplo, a automatização de testes, a conceção de interfaces ou a integração de software interno com o de outros fornecedores podem exigir especialistas fora da sede,
• Razões de Dimensão: O projeto precisa de mais pessoas para entregar aos clientes num prazo predefinido. Nesse caso, a organização do projeto necessitará de mais membros do que os que cabem razoavelmente numa Equipa Scrum. Isto poderá exigir várias equipas coesas, em vez de expandir indefinidamente uma única equipa,
• Razões de Negócio: Utilizar recursos humanos de locais com custos mais baixos ou garantir a continuidade do trabalho com engenheiros em diferentes fusos horários pode ter uma boa justificação económica.

Como a comunicação é parte integrante do Scrum Framework, todos os membros devem procurar superar os desafios de trabalhar num projeto distribuído. Além disso, todos devem ter acesso a ferramentas de comunicação, incluindo audioconferência, videoconferência e partilha de ecrã.

Estas ferramentas habituais de gestão de projetos ajudam a manter uma comunicação saudável e contínua. Podem incluir Product Backlogs, Sprint Backlogs, listas de incidentes, ferramentas de partilha de conhecimentos e notícias, entre outras.

Organização do Projeto: Várias Equipas

A forma mais simples de expandir o Scrum Framework num projeto de maior dimensão é aumentar o número de equipas no mesmo local.

Se várias equipas precisarem de trabalhar em conjunto no projeto, é preferível aumentar o seu número progressivamente.

O que significa isto para si?

Várias Equipas num Único Local

Na maioria das organizações, o crescimento progressivo é mais fácil de gerir do que lançar dez equipas novas de uma vez. A boa prática é começar com uma Equipa Scrum. Após alguns Sprints bem-sucedidos, podem juntar-se mais uma ou duas equipas. Depois de garantir que estas várias Equipas Scrum (saiba mais sobre Várias Equipas Scrum) trabalham bem em conjunto, pode continuar a acrescentar equipas à organização do projeto distribuído.

Aumentar o Número de Equipas

Existem duas formas habituais de criar novas Equipas Scrum:

• Dividir uma Equipa Scrum existente em várias e acrescentar novos membros quando e onde for necessário,
• Construir uma nova Equipa Scrum com engenheiros completamente diferentes, que ainda não participaram no projeto.

Dividir uma equipa existente tem a vantagem de aproveitar os membros que já possuem conhecimentos e experiência do projeto em curso.

Por isso, as novas equipas são normalmente produtivas, pelo menos em parte, assim que se formam. A principal desvantagem é dividir em duas uma equipa existente e plenamente funcional. Isto pode causar dificuldades na motivação dos membros. Sobretudo quando as mudanças ocorrem sem aviso e justificação prévios da liderança sénior e os membros não estão preparados mental nem tecnicamente.

Ao acrescentar equipas completamente novas, as existentes podem preservar a sua estrutura e continuar os Sprints. Ainda é necessário cuidar da coordenação, integração e acolhimento das novas equipas. Contudo, desenvolver os conhecimentos e o ritmo necessários nas equipas inteiramente novas demora mais tempo.

Independentemente da forma como acrescenta Equipas Scrum à organização, tenha presentes os seguintes princípios:

• Comece com um número reduzido de equipas Scrum,
• Aumente o número de equipas gradualmente,
• Garanta a continuidade do trabalho e uma entrega fluida de software e valor de negócio durante as mudanças e o crescimento,
• Se existirem problemas significativos que prejudiquem a produtividade e a continuidade, concentre-se primeiro em resolvê-los, em vez de expandir com novas Equipas Scrum.

Organização do Projeto: Equipas Distribuídas

A principal complexidade de várias equipas manifesta-se quando as novas Equipas Scrum precisam de estar distribuídas por diferentes locais. Barreiras de comunicação, dificuldades de coordenação e interpretações diferentes das normas comuns são apenas alguns exemplos desta complexidade.

Várias Equipas em Vários Locais

As consequências de não resolver estes desafios são graves.

As empresas têm de contabilizar milhares de milhões de dólares de orçamento informático desperdiçado devido à falta de competências em Liderança Organizacional e Especialização em Scrum em Escala.

Apresentamos quatro sugestões fundamentais para enfrentar estes desafios:

• Garanta que os novos membros recebem formação no Scrum Framework como Especialista em Scrum em Escala,
• Garanta uma apresentação adequada do projeto aos novos membros, para que compreendam bem aquilo que servem, não só tecnicamente, mas também do ponto de vista do valor de negócio. Assim, poderão decidir de forma a aumentar o valor do seu contributo,
• Garanta o estabelecimento das normas do projeto. Tal como uma única Equipa Scrum tem normas de comunicação, planeamento e execução, uma organização de várias equipas deve ter normas de nível superior. Assim, podem comunicar, planear, trabalhar, resolver problemas e entregar valor aos clientes e ao negócio em conjunto.
• Garanta que os novos membros trabalham com os experientes, pelo menos temporariamente. Isto pode exigir visitas a locais remotos e formação no posto de trabalho. É perfeitamente aceitável e até desejável. Desta forma, o conhecimento pode ser transmitido sem dificuldades e pode estabelecer-se um diálogo pessoal e bidirecional entre pessoas de diferentes equipas e locais.

Equipas Virtuais

Outra opção de Equipa Scrum distribuída é ter os seus membros espalhados por vários locais. Chama-se «Equipa Virtual».

O principal desafio é garantir uma comunicação impecável entre os membros. As Equipas Scrum continuam a precisar de realizar todos os eventos prescritos para coordenar o trabalho, mas agora fazem-no sem estarem todos na mesma sala.

Equipas Virtuais

Os membros no mesmo local podem trabalhar numa sala comum quando útil, garantindo a participação plena dos remotos. Ainda assim, precisam de depender mais das ferramentas de colaboração e comunicação. Podem participar nos eventos a partir da mesma sala de reuniões e ligar-se à outra parte da equipa virtual por videoconferência.

Equipa de Product Owners Scrum

Como já abordámos várias vezes, a comunicação regular entre o Product Owner Scrum e a equipa é fundamental para entregar um projeto com sucesso.

As Equipas Scrum em diferentes locais precisam de acesso eficaz às decisões sobre o produto. Para um único produto, as equipas partilham um Product Owner, um Objetivo do Produto e um Product Backlog. O Product Owner pode delegar trabalho de apoio, mantendo a responsabilidade; não é necessário acrescentar um Product Owner com responsabilidade própria por cada equipa.

Esta edição descreve uma «Equipa de Product Owners Scrum» e um «Chief Scrum Product Owner» como padrão de colaboração organizacional. Um Product Owner pode trabalhar com delegados ou outros especialistas do produto, mas estes títulos não são responsabilidades específicas Scrum adicionais nem substituem o único Product Owner responsável por um produto.

O Product Owner responsável, apoiado por esta colaboração, concentra-se em garantir que:

• É construído o produto certo para satisfazer as necessidades do cliente,
• O Product Owner e os delegados colaboram eficazmente, ajudando as equipas a criar valor técnico e de negócio para os clientes.

O Product Owner mantém a responsabilidade pela gestão eficaz do Product Backlog. O trabalho de apoio aos requisitos pode beneficiar de outras competências e dos contributos das partes interessadas. Estes podem incluir representantes da justificação económica, partes interessadas relevantes, arquitetos empresariais e arquitetos tecnológicos.

Nas equipas que trabalham no mesmo produto, o Product Owner e os colaboradores de apoio utilizam um único Product Backlog ordenado em direção a um Objetivo do Produto partilhado. Cada equipa é responsável por entregar algumas destas histórias. Ainda assim, haverá histórias específicas que exigem a atenção e as entregas de várias equipas Scrum.

Equipas de Componentes vs Equipas de Funcionalidades

Ao distribuir o trabalho por várias equipas, podemos responsabilizá-las por componentes ou funcionalidades específicos do software. Por isso, chamamos-lhes «Equipa de Componentes» ou «Equipa de Funcionalidades».

Equipas de Componentes

Ao utilizar Equipas de Componentes, cada uma é responsável apenas pela implementação de componentes específicos do sistema global. Para concluir uma história, é normalmente necessário dividi-la em partes mais pequenas e implementá-las num único componente. As dependências entre os componentes tornam a integração contínua indispensável às entregas bem-sucedidas.

Equipa de Product Owners Scrum

Estas dependências podem dificultar a entrega de uma funcionalidade completa num Sprint. Devem ser tratadas através de colaboração e integração: equipas no mesmo produto continuam a precisar de um Incremento integrado e utilizável que cumpra a Definition of Done partilhada.

Isto aumenta as dimensões dos lotes e os tempos de atravessamento do trabalho em curso ainda não integrado. Isto não parece positivo, pois as Equipas Scrum devem procurar entregar incrementos de software prontos a disponibilizar em lotes mais pequenos e prazos mais curtos.

A vantagem das equipas de componentes é facilitar o foco e o desenvolvimento de conhecimentos sobre os detalhes de arquitetura e conceção de componentes específicos. Isto pode ser extremamente benéfico para componentes que exigem descoberta e inovação.

Por outro lado, os membros especializam-se apenas em componentes individuais do sistema. Podem perder a visão global e a necessidade de negócio das funcionalidades.

Tenha presente que os clientes não nos pagam para entregar componentes, mas funcionalidades com que irão desenvolver o seu negócio. Sem este foco incansável nas funcionalidades, a otimização global e a integração do software podem demorar mais. Como as decisões das equipas tendem a otimizar componentes isolados, podem criar estrangulamentos invisíveis ao sucesso e desempenho da solução global.

Equipas de Componentes

Equipas de Funcionalidades

As equipas de funcionalidades são plenamente responsáveis por implementar as histórias conforme especificadas no Product Backlog. As equipas deixam de precisar de ser divididas por componentes. Cada Equipa de Funcionalidades é responsável por entregar uma funcionalidade totalmente operacional e o valor de negócio associado.

Equipas de Funcionalidades

Os membros possuem competências multifuncionais. Atuam com a maior autonomia possível para entregar rapidamente. A vantagem é manterem o conhecimento do sistema, o que facilita a integração das funcionalidades com o restante sistema.

Contudo, pode ser mais difícil desenvolver conhecimentos suficientes sobre os componentes. Além disso, formar uma equipa autónoma que entregue depressa e de forma independente demora tempo, pois criar uma equipa interdisciplinar funcional não é fácil. Ainda assim, estas são as equipas de elevado desempenho que realizam o trabalho na maioria das organizações, provavelmente incluindo a sua.

Como Escolher entre Equipas de Componentes e Equipas de Funcionalidades?

Na prática, a maioria das grandes organizações utiliza tanto Equipas de Componentes dedicadas como Equipas de Funcionalidades.

Equipas de Componentes e de Funcionalidades

A Equipa C, no diagrama, é uma Equipa de Componentes. Fornece serviços de infraestrutura planeados e a pedido às outras equipas, que funcionam como Equipas de Funcionalidades. A Equipa C não implementa diretamente histórias de utilizador de ponta a ponta. Entrega os requisitos das histórias acordadas pelas Equipas de Funcionalidades.

Isto permite minimizar o número de pessoas qualificadas nas Equipas de Funcionalidades com conhecimentos desses componentes.

O Scrum Master no Ambiente de Projeto Distribuído

Num projeto distribuído, o papel do Scrum Master é ainda mais essencial. Nestas configurações:

• É necessário esforço adicional para alinhar as equipas com os valores do Scrum Framework,
• Demora mais tempo estabelecer normas individuais de equipa e de projeto que influenciam várias equipas,
• Por último, existirão muitos impedimentos devido ao maior número de dependências entre as equipas e as suas entregas.

Um Scrum Master precisa de estar acessível e apoiar eficazmente a equipa. Trabalhar fisicamente no mesmo local pode ajudar, mas não é um requisito de Scrum, sendo possível o apoio remoto. A organização distribuída deve permitir ao Scrum Master:

• Ajudar a promover a eliminação de impedimentos ao progresso da equipa,
• Ajudar a equipa a estabelecer acordos de trabalho eficazes e
• Ajudá-la a melhorar a utilização do Scrum Framework.

Algumas organizações utilizam um Scrum Master Principal para apoiar a orientação e a coordenação entre equipas. É um padrão organizacional opcional, não uma hierarquia obrigatória nem uma substituição das responsabilidades específicas de cada Equipa Scrum.

Cada Equipa Scrum na organização mais ampla continua a ter a responsabilidade específica de Scrum Master e precisa de apoio eficaz para os seus eventos, autogestão e melhoria.