Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso @ UGF

Organização e gerenciamento de múltiplas equipes ágeis utilizando o
framework Large-Scale Scrum: um estudo de caso
André Luis Celestino
andredelphi@gmail.com
José do Carmo Rodrigues, MSc, PhD
jcrodrigues@uol.com.br
Curso de Pós-Graduação Lato Sensu em Engenharia e Arquitetura de Software
UGF - Universidade Gama Filho
Resumo
A adoção de metodologias ágeis vem se tornando cada vez mais predominante nas
empresas de desenvolvimento de software, visando uma melhor administração da equipe e
aprimoramento dos modelos de programação. Apesar de existir diferentes metodologias
ágeis, uma das mais observadas pelas empresas é o Scrum, concebido por Ken Schwaber em
1995, abordando melhores práticas para gerenciamento de equipes e projetos. O Scrum,
conforme consolidado nas literaturas, não é um modelo padrão de desenvolvimento de
software, mas um conjunto de princípios que deve ser adaptado de acordo com a realidade,
cultura e domínio de aplicação da empresa, sem fugir das diretrizes que a metodologia
sugere. No ambiente de ascensão de sistemas informatizados, é natural que as empresas
aumentem o quadro de funcionários para atender a demanda de novas implementações e
manutenção dos softwares dentro das Sprints. Entretanto, na mesma proporção que um
time ágil recebe mais integrantes, o gerenciamento da equipe se torna cada vez mais
complexo. Corre-se o risco de perder o controle das Sprints, revisões, retrospectivas e
principalmente da comunicação mútua entre a equipe. Visando solucionar este problema, o
Desenvolvimento Ágil propõe um framework interativo introduzido como Large-Scale Scrum,
especialmente voltado para a aplicação de práticas ágeis em larga escala. Este artigo aborda
os conceitos e as vantagens do Large-Scale Scrum através do acompanhamento de um
estudo de caso realizado no primeiro semestre de 2013 envolvendo a aplicação do
framework em uma equipe com vinte e seis desenvolvedores, com o objetivo de analisar os
parâmetros de comunicação e níveis de produtividade.
Palavras-chave: Gerenciamento de Equipes, Scrum, Metodologia Ágil, Large-Scale Scrum.
1. Introdução
Nos últimos anos, tem-se notado claramente as mudanças no ambiente corporativo,
exigindo que as empresas sofram adaptações contínuas para manterem-se ativas e capazes
de enfrentar a concorrência com segurança. Neste cenário competitivo, é fácil observar a
importância da TI e como ela pode afetar diretamente na produtividade da empresa e nas
decisões de negócio. Por esse motivo econômico e estratégico, a procura e aquisição de
sistemas de informação cresceram de forma notória, criando uma demanda cada vez maior
de prestação de serviços para as empresas de desenvolvimento de software.
Para suprir a demanda intensa da construção de novos sistemas, a engenharia de
software proporcionou a aplicação de modelos, práticas, técnicas e ferramentas para
sistematizar os processos de elaboração e produção de softwares, garantindo consistência
no objetivo e na qualidade do produto. Para isso, este ramo sugere a adoção de

2
metodologias de desenvolvimento para apoiar projetistas, gestores e desenvolvedores a
estabelecer e acompanhar as etapas do desenvolvimento de software, de modo que os
custos, prazos e principalmente os requisitos sejam atendidos em conformidade.
O Desenvolvimento Ágil é um dos métodos emergentes da engenharia de software e
ganhou um grande destaque nas empresas de desenvolvimento por apresentar resultados
rápidos e satisfatórios através de entregas incrementais de produtos de software. Apesar de
ainda existir resistências na adoção do Desenvolvimento Ágil, várias metodologias ágeis e
frameworks são criados e constantemente aprimorados por autores e profissionais com
conhecimento empírico na área de desenvolvimento de software.
A mudança nos paradigmas de desenvolvimento e de gerenciamento de equipes
exigiu que, assim como os padrões de arquitetura e as linguagens de programação, as
metodologias de desenvolvimento também contemplassem alterações na forma como são
conduzidas. Por exemplo, a partir do momento em que as equipes de desenvolvimento se
tornaram volumosas, o Scrum, uma das metodologias ágeis mais populares, foi considerado
inadequado para o gerenciamento destas equipes. Isso levou vários autores e especialistas a
criarem (ou expandirem) metodologias de desenvolvimento, para que estas pudessem
acompanhar o crescimento do número de desenvolvedores trabalhando em uma mesma
equipe. Neste contexto, surgiu o Large-Scale Scrum que, em resumo, é uma expansão da
metodologia Scrum para comportar equipes grandes, proporcionando uma forma de
decomposição em subequipes denominadas células de trabalho.
Este artigo visa introduzir, apresentar e avaliar a aplicação do Large-Scale Scrum em
uma empresa de desenvolvimento de software que presencia dificuldades no
gerenciamento de vários membros em uma mesma equipe, de modo que a efetividade
deste framework possa ser observada baseada em um ambiente real.
2. Fundamentação Teórica
2.1. Desenvolvimento Ágil
De acordo com Sommerville (2007, p. 392), devido ao ritmo constante de mudanças
no ambiente econômico, mercado empresarial e de novas tecnologias, as empresas se
encontraram em um cenário de negócios em que responder rapidamente às oportunidades
e lidar com ameaças competitivas se tornou uma atividade importante para a gestão
organizacional. Dentro desse cenário, o sistema de informação não deixa de ser um fator
essencial entre essas operações e, portanto, deve ser desenvolvido e atualizado de forma
rápida para acompanhar esse ritmo competitivo.
Em linhas gerais, o Desenvolvimento Ágil é uma coleção de metodologias de
desenvolvimento que surgiu na década de 90 como forma de solucionar os problemas
encontrados nas metodologias de desenvolvimento já existentes, como o Desenvolvimento
em Cascata (Waterfall, em inglês), no qual o processo de desenvolvimento ocorre de forma
linear, dificultando a resposta a mudanças no negócio, estimativas, métricas e trazendo uma
formalidade excessiva na produção de documentos.
O Desenvolvimento Ágil, conforme o próprio nome sugere, fornece uma maior
agilidade, colaboração e centralização das atividades de desenvolvimento, de forma que a
empresa possa atender as mudanças recorrentes do mercado empresarial. Na visão de
Shore e Warden (2008, p. 6), o Desenvolvimento Ágil proporciona sucesso organizacional por
focar na entrega de valor e na redução de custos, levando ao crescimento no retorno sobre
investimento (ROI). Em projetos ágeis, as funcionalidades de maior valor são desenvolvidas e
liberadas frequentemente em novas versões, trazendo valor ao negócio. Quando ocorre

3
alguma mudança nos requisitos durante o projeto, uma equipe ágil é capaz de gerenciar o
impacto e direcionar planos.
Como base de todo o contexto teórico do Desenvolvimento Ágil, há quatro valores
principais que compõem o Manifesto Ágil, fundamentados por um grupo de profissionais
com ampla experiência na área de engenharia de software, conforme Beck et al. (2001):
– Indivíduos e interação entre eles mais que processos e ferramentas
– Software em funcionamento mais que documentação abrangente
– Colaboração com o cliente mais que negociação de contratos
– Responder a mudanças mais que seguir um plano
Em suma, os autores desses valores destacam que, mesmo havendo valor nos
princípios abordados pelos modelos tradicionais de desenvolvimento, o Desenvolvimento
ágil valoriza mais o ambiente comunicativo e colaborativo visando a excelência técnica. Estes
quatro valores caracterizam a reação dessa nova metodologia em comparação com os
modelos tradicionais de desenvolvimento.
Conforme Stott e Newkirk (2007, p. 53), o fato que mais surpreende as pessoas no
primeiro contato com o Desenvolvimento Ágil é a ausência das fases hierárquicas de
modelagem do visual, codificação e testes. Em um método tradicional, essas atividades são
realizadas durante semanas ou meses, enquanto no Desenvolvimento Ágil elas são repetidas
continuamente como parte da validação das funcionalidades exigidas pelo cliente. Outro
aspecto que surpreende as pessoas é a abordagem ágil em relação ao levantamento de
requisitos, na qual é feita conforme o projeto é desenvolvido ao invés de levantar todos os
requisitos de uma só vez e documentá-los em arquivos extensos.
Por conta da insegurança e desconhecimento da metodologia, a princípio o
Desenvolvimento Ágil foi alvo de críticas e restrições por muitos profissionais que não
consideravam a aplicação de novos conceitos de desenvolvimento e gerenciamento de
recursos humanos nos projetos. Porém, o cenário mudou quando a indústria de software se
deparou com uma forte demanda de desenvolvimento de sistemas, exigindo equipes cada
vez mais capacitadas, comunicativas e regidas por um modelo de gerenciamento
centralizado. Este cenário trouxe a ascensão do conjunto de metodologias ágeis que
gradativamente foi sendo apreciado e adotado pelas empresas de desenvolvimento. O
Scrum, uma das metodologias deste conjunto, recebeu uma atenção especial principalmente
pela flexibilidade de adaptação na cultura das empresas e por trazer o conceito de Sprints,
unidades de tempo que representam um ciclo de iteração do software.
2.2. A metodologia ágil Scrum
O Scrum é uma das metodologias ágeis mais difundidas entre as empresas. Segundo
Smite (2010, p. 71), o Scrum consiste em um conjunto de técnicas organizacionais e
mecanismos de colaboração voltados principalmente para o trabalho colaborativo, em que
os processos de comunicação e feedbacks são mais adequados do que um processo
centralizado somente nos requisitos. Conforme Resnick et al. (2011, p. 25), equipes Scrum
são bem diferentes de equipes que utilizam métodos tradicionais de desenvolvimento de
software. Ao invés do conceito hierárquico de analistas, desenvolvedores, testadores,
engenheiros e gerentes de projetos, o Scrum envolve um núcleo de profissionais
responsáveis mutuamente pela construção, teste e entrega de produto com alta qualidade.
No Scrum é possível encontrar uma série de artefatos para auxiliar no gerenciamento
de equipes e na entrega contínua de valor no software. Entre estes artefatos, há o conceito
de Sprint, uma unidade temporal de desenvolvimento com duração entre 7 e 45 dias em que

4
um conjunto de requisitos previamente selecionado é implementado, verificado e entregue
ao cliente como forma de produto potencialmente utilizável. Para cada nova Sprint há uma
reunião de planejamento (Sprint Planning) envolvendo todos os integrantes da equipe para
a definição das próximas funcionalidades a serem implementadas até o final do ciclo de
desenvolvimento. Ao término da Sprint, quando o novo incremento do produto é gerado,
ocorre uma reunião de revisão (Sprint Review) e de retrospectiva (Sprint Retrospective) para
discussão das dificuldades enfrentadas, sugestões de melhoria e alinhamento do projeto
para as próximas versões.
2.3. O framework Large-Scale Scrum
No âmbito atual de desenvolvimento de sistemas, o crescimento do número de
desenvolvedores para trabalhar em um único projeto de software se tornou uma situação
comum. Embora as empresas utilizem o Scrum como metodologia ágil para o gerenciamento
da equipe, em determinado momento os parâmetros deste framework podem não ser
suficientes para abranger uma equipe com vários desenvolvedores trabalhando em módulos
distintos do produto. Conforme Larman e Vodde (2010, p. 11), em certo ponto do projeto, o
Product Owner, profissional que representa o cliente dentro da empresa, pode perder a
compreensão global do produto, a comunicação uniforme com os integrantes e o equilíbrio
entre o foco interno e externo. Consequentemente, a lista de implementações se tornará
tão extensa que apenas uma equipe, mesmo com vários integrantes, não será capaz de gerir
as atividades adequadamente. Manter vários integrantes em uma única equipe pode
também afetar as métricas de produtividade e dificultar a distribuição de atividades,
trazendo sobrecarga de trabalho e ociosidade entre os desenvolvedores. Na mesma
proporção que uma equipe ágil cresce, a responsabilidade coletiva, a coesão e a confiança
são cada vez menos estabelecidas.
Em complemento às observações no parágrafo anterior, é importante mencionar que
a comunicação mútua entre os próprios integrantes da equipe também será comprometida.
O repasse de conhecimento, o compartilhamento de informações e inclusive as reuniões
diárias (Daily Scrums) serão afetados pelo número excessivo de desenvolvedores. Além
disso, a própria literatura do Scrum sugere que um time ágil tenha entre seis a dez pessoas
para que seja eficiente. Segundo Cockburn (2001, p. 128), à medida que a equipe se
expande, os integrantes encaram dificuldades para acompanhar as responsabilidades
evitando a sobreposição de atividades, duplicação ou interferência no trabalho de cada um.
Ao mesmo passo que uma equipe cresce em integrantes, a forma de coordenação e
comunicação também devem acompanhar este crescimento.
Muitos autores destacam, nas literaturas, metodologias ágeis sendo aplicadas
somente em projetos de pequeno porte. Cohn (2009, p. 352) explica que este
conservadorismo não define que o Scrum é inconveniente para projetos grandes, mas deixa
claro que estes autores não tiveram a oportunidade de aplicar os processos ágeis em
projetos de larga escala e, por esse motivo, não incluíram essa experiência em seus
trabalhos. Nas literaturas mais recentes, devido ao crescimento das equipes e da dimensão
dos projetos, é possível averiguar que os princípios e práticas do desenvolvimento ágil
podem ser escaláveis e aplicadas em projetos ou equipes extensas. De um modo mais
prático, se uma empresa definir corretamente as responsabilidades, compartilhar a lista de
implementações, estiver atenta às dependências e coordenar o trabalho entre as equipes,
ela pode facilmente escalar a metodologia Scrum com sucesso.
Visando solucionar este paradigma, muitos profissionais da área de desenvolvimento
introduziram conceitos, práticas e inclusive novas metodologias voltadas para uma forma de
gerenciamento mais abrangente. As obras destes autores resultaram em uma ideia em

5
comum: dividir os desenvolvedores em múltiplas equipes de desenvolvimento, criando um
modelo de escalonamento ágil ou desenvolvimento ágil em larga escala, denominado Large-
Scale Agile, em inglês.
Segundo Ambler e Lines (2012, p. 90), equipes entre dez a quarenta pessoas devem
ser organizadas em pequenas subequipes. Cada subequipe trabalha em uma porção do
software em cada iteração, geralmente em uma ou mais funcionalidades divididas em
correção, evolução ou adaptação do software. Independente do método utilizado, o
trabalho de cada subequipe deve ser integrado para formar uma solução utilizável pelo
cliente final.
Uma das propostas para escalar equipes ágeis foi concebida por Ken Schwaber (2004,
p. 39), caracterizada como Scrum of Scrums, que é essencialmente um segundo nível (ou
terceiro, dependendo do tamanho da equipe) de Daily Scrums incluindo representantes de
cada equipe. Embora amplamente utilizado, a necessidade da abrangência da empresa
estudada neste trabalho é maior do que o Scrum of Scrums sugere, o que fez a empresa
descartar a inclusão desta proposta.
Leffingwell (2011, p. 32), trouxe um projeto de metodologia ágil intitulado como
Agile Enterprise Big Picture, com o objetivo de aplicar práticas ágeis em nível de escala
organizacional. Como parte do estudo deste artigo, surgiu o propósito de entrar em contato
com o autor para obter informações sobre essa iniciativa, principalmente sobre a
possibilidade de agregá-la ao Scrum, já que a empresa estudada não apresentava interesse
em substituir o Scrum por uma nova metodologia de gerenciamento. A intenção era analisar
a metodologia proposta com mais detalhes para que fosse possível viabilizar a
implementação deste framework na empresa objeto do estudo de caso. Em resposta ao
questionamento por e-mail, Leffingwell indicou o endereço oficial do framework na internet
(cujo foi renomeado para Scaled Agile Framework – SAFe) e afirmou que essa metodologia é
uma combinação do Scrum com Lean e outras extensões ágeis, resultando em um
framework remodelado. Após estudar as características da metodologia, foi verificado que
há certo nível de complexidade na implementação deste framework, no qual provavelmente
geraria resistência da equipe, além do alto custo de implementação.
Ainda no contexto sobre escalonamento ágil, Larman e Vodde (2010, p. 10)
propuseram um framework de escalonamento ágil definido como Large-Scale Scrum,
especialmente voltado para o ambiente corporativo que apresenta a fraqueza exposta pela
adoção do Scrum tradicional em equipes volumosas. Assim como rege as propostas de
escalonamento ágil, o conceito principal é fragmentar o número de desenvolvedores em
equipes menores para favorecer o gerenciamento dos recursos humanos e impedir as falhas
de comunicação oriundas da integração de várias pessoas ao mesmo tempo. Essa solução
reflete a ideia de melhoria contínua no trabalho através do envolvimento, inspeção e
adaptação de várias equipes ágeis em um mesmo projeto.
As equipes subdivididas são denominadas células de trabalho de alta performance.
Essa definição vem do conceito do Lean para criar uma maior interação entre equipes que
trabalham simultaneamente visando um mesmo objetivo que, no caso de uma empresa de
desenvolvimento, é o novo incremento da versão do software. Em linhas gerais, o Lean é
uma filosofia elaborada para aprimorar a gestão de recursos, processos e objetivos dentro
da empresa. Na explicação de Ambler e Lines (2012, p. 42), o Lean, no âmbito de
desenvolvimento de software, é uma coleção de princípios e estratégias que visam
simplificar o desenvolvimento de software, proporcionando recomendações e abordagens
para o escalonamento ágil.
A proposta de Larman e Vodde (2010, p. 11) para gerenciamento de múltiplas
equipes Scrum pode ser visualizada na figura 1.

6
Figura 1 – Estrutura do framework Large-Scale Scrum
Fonte: adaptado de [LARMAN; VODDE, 2010]
De uma forma prática, é correto afirmar que a visão central do Large-Scale Scrum é a
realização de várias Sprints em paralelo, conduzidas por diferentes líderes de equipe. As
Sprints devem ocorrer em sincronia, de modo que no fim do ciclo de iteração, a lista de
funcionalidades selecionadas para implementação (Backlog) de cada Sprint possa ser
consolidadas em um único incremento, ou seja, uma nova versão do produto de software.
Este conceito é complementado pela recomendação de Stott e Newkirk (2007, p. 69): não
dividir uma equipe grande em uma coleção de subequipes dependentes. Ao invés disso,
recomenda-se criar equipes ágeis separadas que trabalham em diferentes partes do
produto, e que estejam conectadas somente através de interfaces definidas.
De acordo com Leffingwell (2011, p. 65-67), há duas formas básicas de conduzir a
divisão e organização das equipes. A primeira delas é por componente: cada equipe recebe a
responsabilidade de desenvolver uma camada na arquitetura do software, na qual pode ser
classificada em visual (design), regra de negócio (business logic), banco de dados (database)
e núcleo do sistema operacional (kernel). A mesma equipe não trabalha em uma única
história do início até o encerramento, ou seja, a história é fragmentada em diferentes
camadas alocadas para cada equipe, e incorporadas novamente após todas as
implementações terem sido concluídas. Essa divisão induz a adoção de um padrão de
arquitetura, como, por exemplo, o MVC (Model-View-Controller) ou MVP (Model-View-
Presenter). O segundo tipo de organização, no qual será o foco deste trabalho, consiste na
divisão das equipes por funcionalidade. Neste tipo de organização, cada equipe recebe um
conjunto de implementações direcionadas para uma determinada área da regra de negócio
do cliente. Segundo Leffingwell (2011, p. 67), as vantagens deste tipo de divisão estão claras.
Cada equipe aprimora o conhecimento e experiência no domínio da regra de negócio em
que foi alocada. Ao longo das Sprints, por conta deste conhecimento, haverá um aumento

7
na produtividade e na qualidade das funcionalidades desenvolvidas. Além disso, essa divisão
proporciona menos sobrecarga, menor dependência, e as atividades de planejamento e
execução se tornam mais leves, respondendo aos objetivos do Lean.
Entretanto, um dos riscos no escalonamento ágil consiste justamente na
dependência entre as equipes, mesmo que gerenciadas. Conforme Woodward (2010, p. 75),
em uma equipe pequena, os desenvolvedores devem procurar meios de minimizar as
dependências entre as histórias do cliente (Product Backlog). No caso de uma equipe
grande, com vários membros, isso é ainda mais importante, uma vez que o nível de
dependência entre as histórias pode, por consequência, criar um nível de dependência maior
entre as equipes. Essas dependências devem ser devidamente coordenadas, de forma que
uma equipe possa fazer progresso sem necessariamente esperar por outra equipe. Portanto,
o escalonamento ágil não consiste apenas na divisão de desenvolvedores em equipes
menores, como também na distribuição do Product Backlog sistematicamente, ponderando
prioridades, complexidade e focando principalmente na redução de dependências.
Por outro lado, Shore e Warden (2008, p. 39) apontam que, antes de estender uma
equipe ágil, é importante lembrar que várias equipes incorrem em comunicação intensa e na
sobrecarga de processos, consequentemente reduzindo a eficiência individual e afetando a
produtividade em geral. Segundo o autor, o cerne das empresas em relação às equipes
deveria ser na qualidade, e não na quantidade. O autor recomenda a preferência de
contratar profissionais mais experientes e mais produtivos ao invés de escalonar uma equipe
ágil. Entretanto, a opção de contratar profissionais ao invés de estender a equipe não é
viável para a empresa estudada neste artigo, uma vez que, além do projeto de software
atual exigir demandas constantes, os desenvolvedores atuais já dispõem de grande
experiência na regra de negócio do cliente. Em outras palavras, o crescimento da equipe não
foi uma decisão opcional, mas uma exigência devido ao aumento da carga de trabalho.
Neste caso, o Large-Scale Scrum é a técnica mais adequada para ser combinada com a
cultura de trabalho atual da empresa e para a condução do projeto através da matemática
da divisão do Product Backlog entre o número de equipes.
3. Materiais e Métodos
Para acompanhar a aplicação do Large-Scale Scrum em um ambiente corporativo e
dar ênfase ao objetivo do estudo, esta seção do artigo apresenta um estudo de caso
realizado em uma empresa que apresenta problemas de gerenciamento de uma única
equipe Scrum com vários colaboradores. O objetivo desta seção consiste em expor o
processo de implantação e adaptação do framework em um dos setores de desenvolvimento
de software da empresa, dividindo-o em três equipes independentes, porém, ao mesmo
tempo, relacionadas por interfaces. Por meio deste estudo de caso, são mostrados os
critérios, vantagens, dificuldades e custos da aplicação do Large-Scale Scrum em relação à
situação atual da empresa.
3.1. A empresa
Localizada em Florianópolis (SC), a empresa atua no segmento de desenvolvimento
de software e possui soluções tecnológicas voltadas para a gestão pública, com clientes
diretos nos estados de Santa Catarina, Paraná, Bahia, São Paulo, Espírito Santo, Mato Grosso
do Sul, Rondônia e Acre.
Devido ao número crescente de colaboradores, principalmente desenvolvedores, a
empresa decidiu adotar o Scrum para apoiar o gerenciamento de projetos e da equipe de
desenvolvimento, bem como adequar as entregas das versões do software em um modelo
incremental e contínuo.

8
3.2. Problemas no gerenciamento da equipe
Aos poucos, a empresa notou um enorme crescimento no número de usuários do
sistema, logo, resultando também no aumento da demanda de modificações e correções de
erros dos produtos. Um dos softwares desenvolvidos é o projeto piloto da empresa, utilizado
pela maioria dos clientes, e é especialmente na equipe de desenvolvimento deste software
que o estudo de caso do Large-Scale Scrum foi aplicado.
A equipe de desenvolvimento deste sistema possui vinte e seis desenvolvedores e um
Scrum Master para toda a equipe. Como se pode observar, o número de integrantes da
equipe extrapola a quantidade indicada pela literatura do Scrum, na qual recomenda
equipes entre seis a dez membros. Essa sobrecarga de desenvolvedores sob a
responsabilidade de apenas um Scrum Master motivou a empresa a procurar por uma
solução de escalonamento da equipe, sem afetar as diretrizes ágeis que até o momento
estavam sendo adequadas para a cultura de trabalho.
Segundo o coordenador de desenvolvimento, não é possível utilizar técnicas do
Desenvolvimento Ágil em equipes muito grandes. A comunicação dentro de uma equipe é
exponencial, e quando se tem muitos caminhos de comunicação, naturalmente ela falha em
algum ponto. Equipes maiores que dez pessoas geralmente formam subequipes e param de
funcionar como uma unidade, ferindo um dos objetivos do Desenvolvimento Ágil. O
planejamento fica complexo e as cerimônias do Scrum (reuniões diárias, revisões e
retrospectivas) tendem a ficar muito extensas e não produtivas. Na realidade, uma equipe
com 20 pessoas é quatro vezes mais difícil de gerenciar que uma equipe com 10 pessoas.
3.3. Aplicação do Large-Scale Scrum na equipe
Antes de prosseguir com a ideia de desenvolvimento em larga escala, todos os
envolvidos foram comunicados sobre a aplicação do Large-Scale Scrum por meio de uma
reunião sobre as propostas da metodologia e como elas podem atender a empresa. O
objetivo foi manter todos os colaboradores cientes da ação da empresa na busca por uma
solução para o problema de gerenciamento da equipe. Entretanto, é fato que qualquer
mudança na cultura organizacional de uma empresa não é realizada de maneira simples. A
empresa tem ciência de que a mudança pode gerar impactos na produtividade, na qualidade
do produto e, consequentemente, na satisfação do cliente. Por esse motivo, a aplicação do
Large-Scale Scrum foi previamente analisada conforme uma série de critérios descritos a
seguir.
3.3.1. Agile Mentoring
Ambler e Lines (2012, p.90) afirmam que quanto mais desenvolvedores forem
atribuídos a um único mentor, menor será a eficiência devido à sobrecarga associada à
alternância entre tarefas. Assim sendo, decidiu-se que cada equipe responderia a um único
mentor e, por sua vez, cada mentor ficaria responsável por uma única equipe. Conforme
Subramaniam e Hunt (2006, p. 157), um mentor ágil (agile mentoring) é um papel no Scrum
que define o profissional que tem mais conhecimento técnico e de negócios do que os
outros integrantes da mesma equipe. Por este motivo, este profissional é promovido e
recebe a responsabilidade de compartilhar conhecimentos e ministrar orientações, elevando
o valor e a competência de toda a equipe. Os desenvolvedores com mais tempo na empresa
e que detém maior conhecimento no domínio de aplicação do cliente seriam os mentores de
cada célula de trabalho. Na realidade, como já havia um Scrum Master, dois
desenvolvedores foram promovidos para a função de mentoring, formando, portanto, os
três mentores necessários para o escalonamento ágil.

9
3.3.2. Definição de nomes, características e espaço físico
A reintegração de dois desenvolvedores para a função de agile mentoring resultou na
quantidade de vinte e quatro desenvolvedores para a função técnica. Com base no
fracionamento deste número, três equipes de oito desenvolvedores foram criadas de modo
equável. Para facilitar a comunicação e a alocação das atividades, cada célula de trabalho
recebeu um nome como identificação da equipe: Equipe A, Equipe B e Equipe C. Dessa
forma, a separação das Sprints, dos módulos e os resultados dos gráficos de produtividade
seriam feitos para cada equipe em particular. Por conta deste procedimento, foi necessário
que houvesse uma modificação no espaço físico para manter os desenvolvedores da mesma
equipe próximos um do outro.
A respeito da cultura de cada equipe, Cohn (2009, p. 364) explica que todas as
equipes devem entrar em acordo sobre como trabalhar com o Scrum. Não existe uma
exigência de que todas as equipes pratiquem o Scrum da mesma forma, mas elas devem se
atrelar às diretrizes ágeis que representam o núcleo da metodologia. Como o Scrum é um
framework, grande parte da sua implementação pode ser modelada pela própria equipe, ou
seja, cada equipe tem a oportunidade de conduzir a Sprint da forma mais adequada para
aprimorar a produtividade.
3.3.3. Alocação de desenvolvedores
A seleção dos desenvolvedores para cada equipe também foi feita sistemicamente. A
intenção é não agrupar desenvolvedores com mais experiência tanto na regra de negócio
quanto na habilidade em programação em uma mesma célula de trabalho, enfraquecendo o
potencial das outras células. Portanto, a empresa utilizou métricas de produtividade para
equilibrar o nível de experiência entre as células de trabalho, com base no tempo e esforço
de cada desenvolvedor para concluir uma atividade. Da mesma forma, colaboradores recém-
contratados ou com menos tempo de empresa também foram apropriadamente distribuídos
entre as células de trabalho.
3.3.4. Sprint Backlog
Na empresa, antes de aplicar o Large-Scale Scrum, as atividades eram disseminadas
entre os desenvolvedores sem algum tipo de critério, de modo que, caso o desenvolvedor
não conhecesse a área da regra de negócio de uma determinada atividade, era necessário
que outro colaborador o orientasse antes de realizar a implementação. Smite (2010, p. 221)
afirma que os integrantes devem se especializar em tarefas específicas associadas a uma
determinada área da regra de negócio (subsistema), transformando o compartilhamento de
conhecimento em uma atividade formal entre a equipe. Assim sendo, para aprimorar a
ênfase do escalonamento ágil, a empresa atribuiu responsabilidades individuais para cada
célula de trabalho, ou seja, cada equipe ficou responsável por determinados módulos do
software, com o objetivo de capacitar os desenvolvedores em regras específicas de negócio.
Essa distribuição resultou na elaboração de três Sprints Backlogs em cada ciclo de iteração
de software. Cada equipe trabalha na sua Sprint Backlog, conduzida em paralelo com as
Sprints Backlogs das demais equipes.
A atividade de configuração das equipes foi concluída com êxito após dois dias de
análise para alcançar um equilíbrio entre a capacidade, experiência e o tempo de empresa
de cada desenvolvedor. A aplicação da estrutura do Large-Scale Scrum na equipe de
desenvolvimento resultou na arquitetura exibida na figura 2.

10
Figura 2 – Arquitetura das células de trabalho utilizando Large-Scale Scrum
Fonte: do autor
Todos os critérios acima foram definidos mediante uma reunião exclusivamente
sobre o escalonamento das equipes, envolvendo a equipe de desenvolvedores, a gerência de
desenvolvimento e o Product Owner. A partir da Sprint de desenvolvimento seguinte, o
Large-Scale Scrum foi aplicado e as primeiras conclusões já puderam ser observadas pelos
gestores.
A primeira dificuldade observada na divisão de equipes foi a sincronia entre as células
de trabalho, ou seja, ao final da Sprint houve um atraso na integração das implementações
realizadas pelos desenvolvedores das diferentes células, causando, por consequência, um
atraso da liberação da versão. Embora o atraso tenha sido causado pela pré-adaptação ao
Large-Scale Scrum, a empresa já esperava por essa falta de alinhamento dos Sprint Backlogs
no primeiro ciclo, uma vez que isso serviria como subsídio para a melhoria da próxima
Sprint. Este atraso entra em conformidade com a justificativa de Cohn (2009, p. 344), que
afirma que todas as Sprints não precisam necessariamente terminar exatamente no mesmo
dia. Em projetos grandes, é aceitável que as Sprints entre diferentes equipes terminem em
uma diferença de dois ou três dias, no máximo. Na verdade, esse intervalo pode ainda trazer
vantagens. Se as Sprints terminarem em datas diferentes, se torna mais fácil organizar e
planejar reuniões de revisão para cada equipe. Na realidade da empresa, quando uma das
equipes termina a Sprint antes que as demais, o mentor ágil emprega a margem de tempo
dos desenvolvedores para realizar tarefas adicionais não planejadas, mas que contribuem
para a qualidade do produto, como cobertura de testes, implementações de padrões de
projeto e brainstorming para aprimorar funcionalidades existentes.
A questão do atraso foi solucionada com a alocação dos dois últimos dias da Sprint
para a integração das implementações. Por um lado mais prático, dos 45 dias que compõem
a Sprint de desenvolvimento, os 44º e 45º dias foram especialmente reservados para apurar
as horas de trabalho, validar as implementações e integrá-las ao repositório de código-fonte
principal (chamado de branch) para a compilação da versão final. Para isso, o número de
histórias do cliente teve de ser reduzido para cada Sprint, evitando que os dois últimos dias
ficassem comprometidos em virtude da sobrecarga de atividades.

11
O Large-Scale Scrum também levou cada equipe a organizar sua própria reunião de
revisão (Sprint Review) após o término da Sprint. Cada Sprint Review dura cerca de duas a
três horas para conclusão, contra quatro a cinco horas consumidas anteriormente. Essa
redução de tempo ocorreu naturalmente devido ao menor número de pessoas na reunião e
também pela uniformidade da discussão das implementações, uma vez que cada célula de
trabalho ficou responsável por módulos específicos do sistema. Em contrapartida, a reunião
de retrospectiva (Sprint Retrospective) continuou sendo frequentada por toda a equipe de
desenvolvimento, como parte da cultura de trabalho da empresa para o compartilhamento e
consenso dos pontos positivos e negativos do software sob uma perspectiva geral.
Outra questão observada envolve a comunicação mútua entre as equipes. Ao mesmo
passo que o Large-Scale Scrum trouxe a criação de equipes independentes, houve também
uma mudança na forma como os membros se comunicam. Neste novo modelo de
gerenciamento, os desenvolvedores devem reportar as informações imediatamente ao
mentor de sua equipe, e este, por sua vez, deve manter contato constante com os outros
mentores. É importante ressaltar que isso não significa que um desenvolvedor de Equipe A
não possa se comunicar com um desenvolvedor da Equipe B, mas que, caso se trate de
qualquer funcionalidade relacionada aos módulos trabalhados pelas duas equipes, então é
necessário que haja o consenso dos mentores.
Com o Large-Scale Scrum, para que todos os desenvolvedores tivessem a ciência da
execução das atividades da respectiva célula de trabalho, a empresa introduziu uma
ferramenta de gestão de histórias (post-its) online terceirizada chamada Trello, vinculada a
uma planilha do Google Drive. Esta ferramenta, na realidade, é o mesmo conceito do quadro
de tarefas do Scrum, com as tradicionais colunas de To Do, Doing e Done (a fazer, fazendo e
feito, respectivamente), salvo a exceção de que é automatizada e utilizada pela web. A
maior vantagem é o compartilhamento de status das atividades sem a necessidade de
conferir o quadro de tarefas fisicamente. O vínculo com o serviço do Google Drive permite
que os gráficos de progresso do projeto (Burndown) sejam atualizados conforme as histórias
são implementadas e sinalizadas como concluídas. Dessa forma, mesmo que haja um
mentor ágil em cada equipe, qualquer desenvolvedor pode obter informações e visualizar o
progresso da Sprint através da ferramenta.
4. Resultados
O acompanhamento do Large-Scale Scrum continuou sendo realizado durante as
próximas Sprints, realizando os ajustes temporais necessários. Ao término de cinco Sprints,
envolvendo um tempo total de 220 dias (aproximadamente 7 meses), os resultados obtidos
com o framework puderam ser consolidados e colocados em pauta pelos gestores, conforme
mostra a tabela 1.
Tabela 1 – Resumo da produtividade das equipes com a aplicação do Large-Scale Scrum
Fonte: do autor
Produtividade Cobertura de
TestesEquipe A Equipe B Equipe C Geral
Sprint 1 -15% -18% -12% -15% 35%
Sprint 2 -8% -10% -2% -11% 41%
Sprint 3 4% -3% 10% 6% 48%
Sprint 4 8% 6% 11% 18% 57%
Sprint 5 14% 12% 18% 31% 70%

12
Conforme exibido na tabela 1, a partir do 3º ciclo de desenvolvimento é possível
observar os resultados positivos obtidos com o Large-Scale Scrum. Antes deste período, as
células de trabalho estavam em processo de adaptação e treinamento das regras de negócio
específicas. O ritmo de produtividade cresce no 4º e 5º ciclos de desenvolvimento, indicando
que a tendência é a elevação gradual da eficiência de todas as equipes que, por sua vez,
refina a qualidade e pontualidade nas entregas do software para o cliente.
A simultaneidade de tarefas foi o ponto positivo mais observado pela empresa com a
adoção do Large-Scale Scrum. Para o Product Owner, o framework simulou uma
multiplicação de desenvolvedores ao invés da divisão. Como as Sprints ocorrem em paralelo,
equivalem, em um ponto de vista de produtividade, a três ciclos de desenvolvimento
ocorrendo ao mesmo tempo.
Para o setor de gerenciamento de projetos, houve uma consequência com a adoção
do Large-Scale Scrum. Uma vez que a equipe foi dividida em três subequipes, o trabalho do
assistente de projetos naturalmente foi triplicado, já que se tornou necessário repetir a
mesma avaliação das Sprints para cada equipe. Para contornar essa particularidade, a
empresa contratou mais dois colaboradores para atuarem também como assistentes de
projetos. A alocação de três pessoas para essa função facilitou o trabalho de elaboração dos
gráficos de Burndown, acompanhamento do Sprint Backlog, indicadores e impedimento de
cada equipe. Ao invés de desenhar um único gráfico de Burndown para toda a equipe Scrum,
os gráficos são elaborados para cada célula de trabalho, permitindo identificar as histórias
atrasadas bem como o cumprimento da Sprint planejada para cada equipe, conforme
apresentado na figura 3.
Figura 3 – Gráficos de Burndown para cada célula de trabalho
Fonte: do autor
Neste ponto, é importante ressaltar os custos gerados pela implantação do Large-
Scale Scrum na empresa. Além das contratações dos novos assistentes de projetos, os dois
desenvolvedores promovidos para a função de mentoring receberam um ajuste salarial
compatível com as novas responsabilidades a serem desempenhadas. Traduzindo em
valores, estima-se que a empresa teve um aumento de aproximadamente 14% nos custos

13
com as novas remunerações. A infraestrutura do setor também foi remodelada para
comportar a alocação das três equipes em espaços distintos, envolvendo reestruturação dos
cabos de rede, ramais, atualizações de hardware e outros periféricos físicos. Mesmo sendo
fixos, estes gastos também foram inclusos na apuração dos custos com a implantação do
Large-Scale Scrum. No entanto, o gerente de desenvolvimento destaca que a relação custo-
benefício é positiva, e o investimento foi extremamente necessário para a continuidade do
negócio.
Em nível de organização, observou-se uma extensão na duração das reuniões diárias.
Após a implantação do Large-Scale Scrum, as reuniões passaram a ter duração de 15 a 25
minutos, ao invés de 10 a 15 minutos antes da aplicação do framework. Essa extensão
ocorreu devido aos problemas de integração e principalmente pela discussão da análise de
impacto com outras equipes. Em outras palavras, além de discutir sobre o progresso das
implementações no dia atual, os membros também devem analisar o grau de envolvimento
com as outras equipes nessas implementações, para que não haja conflitos na integração
dos módulos.
Uma questão importante abordada pelos desenvolvedores é a reutilização de código.
Mesmo que muito importante, a refatoração de alguns pontos do código foi ignorada para
não prejudicar a produtividade das equipes. Como exemplo, se um determinado
componente do software é compartilhado entre módulos de diferentes equipes, a
refatoração pode voltar a causar dependência ou apresentar problemas na integração. Por
conta disso, a duplicação foi necessária e será tratada em outro momento pelos gestores.
5. Conclusões
Apesar do framework Large-Scale Scrum se mostrar adequado para a situação na
qual a empresa se encontrava, a equipe levou um tempo de carência para se adaptar à nova
cultura de trabalho, assim como ocorre com qualquer mudança organizacional.
Os desenvolvedores e os gestores da empresa verificaram e apontaram as principais
vantagens da aplicação do escalonamento ágil na empresa. Em primeiro lugar, o foco e a
contextualização de cada equipe permitiu maior centralização e uma comunicação menos
dispersa. Conforme o coordenador de desenvolvimento, é bem mais fácil administrar a
interação entre desenvolvedores e os repasses de conhecimento em equipes pequenas,
proporcionando reuniões e retrospectivas mais eficazes. Além disso, a metodologia facilitou
o planejamento e observou-se uma redução nos riscos do projeto.
Em contrapartida, também foram identificados alguns desafios com a metodologia. O
maior desafio dessa abordagem é fazer com que as diversas equipes, mesmo atuando de
forma isolada, mantenham uma comunicação contínua e consigam trocar experiências. Isso
nem sempre é alcançado. É preciso fazer o acompanhamento separado por equipe e ter uma
visão unificada de todos, gerando um pouco mais de trabalho no levantamento e
consolidação dos dados.
Em suma, os prós e contras mencionados no parágrafo anterior permitem concluir
que as vantagens se sobressaem frente às desvantagens. No período de aproximadamente
sete meses, no qual a empresa encerrou cinco Sprints completas, houve notáveis benefícios
com a abordagem do Large-Scale Scrum. Os resultados deste trabalho entram em
contradição com as literaturas que afirmam que o Desenvolvimento Ágil é uma metodologia
que não pode ser escalável, citadas por Cohn (2009, p. 352). No caso da empresa de
desenvolvimento estudada, este escalonamento é uma realidade alcançada, de forma que
pode ser empregada como exemplo por outras empresas que enfrentam as mesmas
dificuldades de gerenciamento.

14
Referências Bibliográficas
AMBLER, Scott W.; LINES, Mark. Disciplined Agile Delivery. Boston: Pearson, 2012. 513p.
BECK, K.; et al. Manifesto for Agile Software Development. Snowbird, Utah. 2001.
Disponível em: http://agilemanifesto.org/. Acesso em 30 jun. 2013.
COCKBURN, Alistair. Agile Software Development. 2 ed. Boston: Addison-Wesley
Professional, 2001. 504p.
COHN, Mike. Succeeding With Agile. Boston: Addison-Wesley Professional, 2009. 475p.
LARMAN, Craig; VODDE, Bas. Practices for Scaling Lean & Agile Development.
Massachusetts: Pearson, 2010. 613p.
LEFFINGWELL, Dean. Agile Software Requirements. Boston: Pearson, 2011. 518p.
RESNICK, Steve et al. Professional Scrum: With Team Foundation Server 2010. Birmingham:
Wrox, 2011. 336p.
SCHWABER, Ken. Agile Project Management with Scrum. Washington: Microsoft Press,
2004. 192p.
SHORE, James; WARDEN, Shane. The art of Agile Development. Sebastopol: O’Reilly, 2008.
409p.
SMITE, Darja et al. Agility Across Time and Space. Springer: New York, 2010. 341p.
SOMMERVILLE. Software Engineering. 8.ed. Harlow: Pearson, 2007. 840p.
STOTT, Will; NEWKIRK, James. Visual Studio Team System: Better Software Development
for Agile Teams. Boston: Pearson, 2007. 858p.
SUBRAMANIAM, Venkat; HUNT, Andy. Practices of an Agile Developer. New York: Pragmatic
Bookshelf, 2006. 176p.
WOODWARD, Elizabeth et al. A practical Guide to Distributed Scrum. Boston: Pearson,
2010. 189p.

Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso @ UGF

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso @ UGF (20)

Último (12)

Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso @ UGF