Machine Translated by Google
Investigando a Adoção e Aplicação de
Scrum em larga escala em um automóvel alemão
Fabricante
¨ Uluda gÿ
Omer *
, Martin Kleehaus* , Niklas Dreymann* ,¨ Christian Kabelin† , Florian
*Cadeira de Informática 19, Universidade Técnica de M ¨ unchen (TUM), D-85748, Garching E-mail:
{oemer.uludag,martin.kleehaus,niklas.dreymann,matthes}@tum.de †Ventum Consulting, D
-80797, Munique ¨ E-mail:{christian.kabelin}
@ventum.de
Resumo—Ao longo das últimas duas décadas, métodos ágeis têm sido
adotados por um número crescente de organizações para melhorar seus
processos de desenvolvimento de software. Em contraste com os métodos
tradicionais, os métodos ágeis colocam mais ênfase em processos flexíveis
do que em planos iniciais detalhados e documentação pesada. Como os
métodos ágeis provaram ser bem-sucedidos no nível da equipe, as grandes
organizações agora pretendem escalar os métodos ágeis para o nível
empresarial, adotando e aplicando as chamadas estruturas ágeis de
escalonamento, como Large-Scale Scrum (LeSS) ou Scaled Agile Framework
( Seguro). Embora haja uma literatura crescente sobre desenvolvimento ágil
em larga escala, a literatura que documenta experiências reais relacionadas
ao dimensionamento de estruturas ágeis ainda é escassa. Este artigo
pretende preencher esta lacuna fornecendo um estudo de caso sobre a
adoção e aplicação do LeSS em quatro produtos diferentes de um fabricante
de automóveis alemão. Com base em sete entrevistas, apresentamos como
a organização adotou e aplicou o LeSS e discutimos os desafios relacionados
e os fatores de sucesso. A comparação dos produtos indica que a
transparência, os cursos e workshops de formação e a gestão da mudança
são cruciais para uma adoção bem-sucedida.
Termos de indexação – desenvolvimento ágil em larga escala, escalação
de estruturas ágeis, scrum em larga escala, estudo de caso
I. INTRODUÇÃO
Surgindo na década de 1990, métodos ágeis de desenvolvimento de
software, como Extreme Programming [1] e Scrum [2], transformaram e
trouxeram avanços sem precedentes para a prática de desenvolvimento de
software, enfatizando a tolerância à mudança, a colaboração da equipe e o
envolvimento do cliente [3], [4 ]. Com esses métodos, equipes pequenas, co-
localizadas e auto-organizadas trabalham em estreita colaboração com o
cliente empresarial em um contexto de projeto único, maximizando o valor do
cliente e a qualidade do produto de software por meio de iterações rápidas e
ciclos de feedback frequentes [3]. Como os métodos ágeis provaram ser bem-
sucedidos no nível da equipe, as grandes organizações agora pretendem
escalar os métodos ágeis para o nível empresarial [5]. A 12ª pesquisa da
Versão Um sobre o estado do ágil [6] também reflete essa tendência da
indústria de adotar métodos ágeis em grande escala. A pesquisa mostra que
52% dos 1.492 entrevistados trabalham em empresas onde a maioria das
equipes é ágil. No entanto, a adoção acarreta novos desafios, como
coordenação entre equipes, dependências de outros ambientes existentes ou
resistências gerais a mudanças [7], [8]. Promovido principalmente por
consultores, escalando estruturas ágeis como Scaled Agile Framework (SAFe),
Disciplined Agile Delivery
Matthes*
(DAD) e Large-Scale Scrum (LeSS) [4], [5] comprometem-se a resolver os
problemas acima mencionados. Embora o número de organizações que
utilizam estruturas ágeis de escalonamento esteja aumentando, a literatura
científica que fornece estudos de caso aprofundados sobre a adoção e
aplicação ainda é escassa [6], [7]. Pretendemos preencher esta lacuna
apresentando um estudo de caso sobre a adoção e aplicação do LeSS em
quatro produtos diferentes de um fabricante automóvel alemão. Com base
nesses objetivos, nossas duas questões de pesquisa são: • Pergunta de
Pesquisa 1 (RQ 1): Como o
LeSS foi adotado?
em produtos diferentes?
• Pergunta de pesquisa 2 (RQ 2): Como o LeSS é aplicado em
diferentes produtos?
O restante deste artigo está estruturado da seguinte forma. Na Seção II,
apresentamos o histórico do nosso artigo e fornecemos uma visão geral dos
trabalhos relacionados. Na Seção III, apresentamos a abordagem de pesquisa
deste artigo. Descrevemos brevemente a organização do caso e apresentamos
os resultados do nosso estudo de caso na Seção IV. Discutimos as principais
conclusões na Secção V antes de concluir o artigo com um resumo dos
nossos resultados e observações sobre pesquisas futuras na Secção VI.
II. ANTECEDENTES E TRABALHOS RELACIONADOS
A. Scrum em larga escala
A estrutura LeSS (ver Figura I) foi lançada em 2008 com base nas
experiências de Craig Larman e Bas Vodde [9].
Ele estende o Scrum com regras e diretrizes de escala sem perder de vista os
objetivos originais do Scrum. Ao contrário do Scrum tradicional, o LeSS
especifica mudanças organizacionais. Além disso, visa facilitar a coordenação
entre múltiplas equipes Scrum, tendo um proprietário do produto (PO)
responsável por um backlog central e diversas equipes. A coordenação entre
as equipes é feita de forma semelhante ao Scrum, onde eles realizam o
planejamento e a revisão do sprint. Para produtos menores, todos os membros
do produto participam do mesmo planejamento e revisão do sprint. Para
produtos maiores, um representante da equipe deverá ser enviado às reuniões.
Embora o LeSS pretenda trabalhar apenas com base em princípios, ele ainda
compreende os seguintes quatro componentes [10]: • Regras: As regras
definem a base do LeSS. Semelhante ao
Scrum, o foco está na estrutura das equipes, funções
Machine Translated by Google
Figura I: Visão geral da estrutura LeSS [10].
dentro da equipe, definição dos requisitos do produto e do processo de
desenvolvimento.
• Princípios: Os princípios fornecem respostas sobre como aplicar o LeSS
em contextos empresariais específicos. •
Guias: Os guias apoiam a adaptação das regras e de um subconjunto dos
experimentos, fornecendo dicas e melhores práticas.
• Experimentos: o LeSS incentiva as equipes a experimentar, falhar e
aprender novos conceitos.
Quando as organizações pretendem escalar mais de oito equipes, o LeSS
Huge deve ser usado. LeSS Huge introduz elementos adicionais necessários
para gerenciar centenas de pessoas, como o conceito de áreas de requisitos
(RAs). Os RAs são organizados em torno de requisitos centrados no cliente.
Todos os RAs seguem a mesma cadência de sprint e buscam integração
contínua em todo o produto. Um PO de área (APO) concentra-se em um RA e
é responsável por um backlog de produto de área (APB). O APO atua
essencialmente da mesma forma que o PO agiria na estrutura menor do LeSS.
B. Trabalho Relacionado
De acordo com a 12ª pesquisa da Version One sobre o estado do ágil, 29%
dos 1.492 entrevistados relataram usar SAFe e 5% LeSS. Embora o número
de organizações que usam estruturas ágeis de escalonamento esteja
aumentando, existem apenas alguns artigos que documentam os usos
relatados [7]. No entanto, algumas revisões da literatura foram conduzidas
por acadêmicos para estudar cientificamente o dimensionamento de estruturas
ágeis. Por exemplo, Alqudah e Razalo [5] fornecem uma revisão da literatura
sobre escalonamento de estruturas ágeis. Nele, eles comparam sete estruturas
ágeis de escalonamento identificadas, como DAD, LeSS, Nexus, SAFe e Spo-
tify, com base em cinco critérios: tamanho da equipe, treinamento e
certificação, métodos e práticas adotados, práticas técnicas exigidas e tipo de
organização. Com base em uma revisão estruturada da literatura, Uludag et
al. [11] fornecem uma análise primária de 20 estruturas ágeis de escalonamento As entrevistas seguiram um questionário semiestruturado e foram de natureza
ÿ
identificadas, como DAD, Enterprise Scrum, LeSS, Nexus, SAFe, Scrum at
Scale e Spotify. Por último, mas não menos importante, Putta et al. [12]
fornecem uma revisão multivocal da literatura, que inclui estudos de caso
revisados por pares e não revisados por pares e relatórios de experiência
sobre organizações que adotaram o SAFe. Além desses estudos secundários,
alguns pesquisadores também apresentam estudos primários na forma de
estudos de caso sobre a adoção de frameworks ágeis de escalonamento.
Por exemplo, Pries-Heje e Krohn [13] descrevem um estudo de caso da
empresa de software financeiro SimCorp sobre como eles adotaram o SAFe.
Além disso, Paasivaara [14] fornece um estudo de caso destacando os fatores
de sucesso e os desafios da adoção do SAFe na empresa de desenvolvimento
de software distribuída globalmente Comptel. Além disso, Paasivaara e
Lassenius [15], [16] descrevem um estudo de caso sobre escalonamento do
Scrum em um grande projeto de desenvolvimento de software distribuído
globalmente na empresa global de telecomunicações Nokia. Nele, os autores
descrevem desafios significativos que o projeto enfrentou ao aplicar o LeSS.
ÿ
Por último, Uludag et al. [17] apresentam um estudo de caso de uma grande
companhia de seguros sobre como eles combinaram design orientado a
domínio com LeSS para apoiar um programa de desenvolvimento ágil em larga
escala com três equipes ágeis. Embora existam alguns estudos primários e
secundários, eles apenas mencionam o LeSS de passagem. Até onde
sabemos, a literatura que documenta estudos de caso aprofundados sobre a
adoção e aplicação do LeSS num contexto da vida real ainda é escassa.
III. DESENHO DE ESTUDO DE CASO
Um estudo de caso é uma metodologia de pesquisa adequada para este
artigo, pois pretendemos estudar um fenômeno contemporâneo inexplorado,
nomeadamente a adoção e aplicação do LeSS, em um contexto complexo da
vida real [18]. Seguimos as diretrizes descritas por Runeson e Host [18] para
¨
o processo de pesquisa do estudo de caso.
Desenho de estudo de caso: O objetivo principal deste artigo é estudar a
adoção e aplicação do LeSS em uma grande organização de TI. Com base no
objetivo declarado, definimos duas questões de pesquisa (ver Seção I). Nosso
estudo de caso único é de natureza exploratória, pois analisamos um fenômeno
inexplorado [18]. A organização do caso foi selecionada propositalmente por
oferecer uma oportunidade única de comparar diferentes ocorrências de LeSS
dentro de uma única empresa e por representar um caso rico em informações
[19]. Nossas unidades de análise são quatro produtos do departamento de TI
da montadora que usam LeSS para desenvolver software complexo.
Preparação para coleta de dados: Focamos nas técnicas de coleta de dados
de primeiro grau de acordo com Lethbridge et al. [20].
Assim, coletamos dados através da realização de sete entrevistas
semiestruturadas com um membro da feature team (FT), um PO, um ágil
coach (AC), um scrum master (SM) e três arquitetos diferentes (EA - arquiteto
corporativo, SA - arquiteto de soluções e IA - arquiteto corporativo de TI) em
quatro produtos diferentes, todos adotando e aplicando a estrutura LeSS (ver
Tabela I). Todas as entrevistas duraram entre 45 minutos a uma hora cada.
bastante conversacional para manter a adaptabilidade aos papéis e
experiências individuais dos entrevistados. Entrevistamos sete funções
diferentes de quatro produtos diferentes para permitir a triangulação de fontes
de dados [18].
Análise dos dados coletados: Todas as entrevistas foram transcritas e
codificadas utilizando codificação aberta conforme sugerido por Miles et al. [21].
Depois de criar códigos preliminares, refinamos e consolidamos nossos
códigos mesclando os relacionados e removendo duplicatas.
Com base nisso, analisamos grupos de frases de código e mesclamos
Machine Translated by Google

TABELA I: Visão geral das funções entrevistadas e suas atribuições B. Adoção do LeSS
produtos.
Utilizamos questões exploratórias para as seguintes categorias:
Papel MPN OTD PPM PFS (1) momento e duração, (2) razões e questões a serem abordadas
DEPOIS
- - - 1 problemas, (3) estruturas combinadas, (4) treinamento, (5)
adaptações, (6) desafios e (7) lições aprendidas para
TF - - - 1
avaliar a adoção do quadro.
AC/SM 1 1 - - Todos os quatro produtos adotaram recentemente o LeSS por não mais
do que dois anos. No entanto, a duração das adoções
EA/SA/IA - - 3 -
variou entre três meses a um ano devido a diferentes
Total 1 1 3 2
complexidades. LeSS foi introduzido para lidar com problemas entre equipes
coordenação e equilibrar as limitações do Scrum em
projetos de grande escala. Razões adicionais foram a sua moderação
em conceitos, que mais tarde foram relacionados ao nosso formulado grau de complexidade, mantendo orientação suficiente
questões de pesquisa. para a coordenação de múltiplas equipes ágeis trabalhando no
mesmo produto. Antes da adoção, os produtos apresentavam problemas
4. RESULTADOS com a sincronização de equipes, gerenciamento de suas dependências e
perda de informações entre equipes. LeSS também foi selecionado

A. Descrição do Caso para permitir a transição do pensamento de projeto tradicional

orientação para o produto e para o cliente. Durante a adoção,
O caso sob investigação diz respeito a uma empresa multinacional alemã
LeSS foi combinado com métodos enxutos e ágeis preexistentes
que actualmente fabrica automóveis de luxo e
como Kanban e DevOps. Por exemplo, MPN e PPM
motocicletas e emprega mais de 120.000 pessoas em
adotou LeSS em combinação com Kanban para gerenciar épicos
toda a organização e cerca de 4.500 pessoas em sua área de TI
e recursos e para acompanhar o progresso das tarefas usando Kanban
departamento. No passado, o departamento de TI concentrava-se principalmente
Pranchas. Em todos os produtos, a adoção foi acompanhada de uma
na padronização e otimização de custos da TI em funcionamento.
treinamento abrangente de todos os funcionários, que vão desde
Impulsionada pela digitalização, a gestão de TI viu o aumento
uma única apresentação do SM/AM para um período de dois dias
na agilidade do departamento de TI como uma melhoria essencial para
workshop ajustado individualmente com especialistas externos desde
seu desempenho e flexibilidade. No final de 2016, a gestão de TI decidiu
os funcionários possuem vários níveis de conhecimento prévio em ágil
transformar o departamento de TI em uma empresa ágil
desenvolvimento de software. A adoção do LeSS em cada produto
organização do produto nos próximos dois a três anos após
levou a ajustes individuais, por exemplo, todos os produtos foram estendidos
o slogan “100% ágil”. Comprometeu-se com o objectivo de
LeSS por um nível de domínio com uma camada de portfólio superior
transformando todos os projetos de TI atuais em ágeis e alinhando o
coordenar todos os produtos dentro do departamento de TI e alinhar
Organização de TI completamente com princípios ágeis até o final de
com os objetivos estratégicos da organização. Um chamado
2019. Contemporaneamente, o departamento de condução autônoma
abordagem de “um calendário”, gerida centralmente pelas subunidades
da organização do caso escolheu o LeSS como seu novo trabalho
do departamento de TI, facilitou a adoção, permitindo
modelo com o objetivo de alcançar uma comunicação mais fácil e
cadências de sprint entre produtos. Embora esta abordagem tenha sido
coordenação, mais transparência e tomada de decisões mais rápida
percebido como contraditório aos valores ágeis, especialmente em termos de
caminhos por todo o departamento. Histórias de sucesso do
auto-organização, um entrevistado ressaltou sua importância:
departamento de direção autônoma com LeSS chegou ao TI
departamento. Paralelamente, a gestão de TI permitiu que indivíduos
“Na verdade, trata-se de auto-organização ágil. Mas com
Projetos de TI para escolher uma estrutura ágil de escalonamento apropriada
algumas centenas de equipes, é difícil se houver uma reunião
por si mesmos, e é por isso que muitos projetos de TI decidiram
lá ou outro tem a diária em outro horário. De alguma forma
adotar o LeSS no início de 2017. Ainda assim, uma grande parte
eles têm que sincronizar. Então este calendário único foi o nosso
das atividades de desenvolvimento de software são terceirizadas para
abordagem para trazer estrutura a ele.
parceiros que trabalham parcialmente orientados por planos.
-SM, OTD
Os quatro projetos de TI investigados (doravante produtos):
”Número de peça do material” (MPN), “Pedido até entrega” (OTD), Identificamos quatro problemas comuns durante a adoção
”Dados mestres de produtos e preços” (PPM) e “Localização de preços De menos. Primeiro, embora o LeSS seja minimalista e tente
Service” (PFS) também decidiu adotar LeSS para seu produto definir funções, artefatos ou processos que sejam pelo menos necessários para
desenvolvimento (ver Figura II). MPN pretendia substituir o caso desenvolvimento ágil em larga escala [10], os produtos tinham preocupações
antigo sistema legado da organização para gerenciar e armazenar seus relativamente a numerosas reuniões de coordenação. O SM do OTD
listas de materiais. OTD desenvolvido, mantido e melhorado descreveu o problema da seguinte forma:
Sistemas de TI para a logística intra-fábrica da organização do caso.
A PPM foi responsável pelo design sustentável do case “Muitas pessoas são simplesmente presas em milhares de outras
aplicativo de dados mestre da organização. A PFS foi responsável reuniões e se o PO estiver faltando em uma reunião como sprint
para o desenvolvimento de um novo software de precificação. planejamento, isso é bastante abaixo do ideal.
Machine Translated by Google
TABELA II: Visão geral dos produtos entrevistados e informações gerais.
MPN
Início da adoção Abril de 2017
Número de Colaboradores envolvidos ÿ600
Locais Alemanha
Número de equipes de recursos 15
Duração do sprint (em semanas) 3 3
Adoção do LeSS Menos
-SM, OTD
Ter muitas reuniões pode reduzir a produtividade do
funcionários:
“O PO participa de tantas reuniões que não tem tempo
para escrever ele mesmo histórias de usuários. . . . E se você não escreveu
você mesmo, é incrivelmente difícil aceitá-los.”
-PO, PFS
Em segundo lugar, devido à actual estrutura organizacional, cada
produto tinha dois pedidos de compra, um do departamento especializado e
um do departamento de TI, o que levou ao chamado “dual
liderança” (ver Seção IV-C). Terceiro, os funcionários temiam
perdendo status e poder. Este problema afetou principalmente
funcionários de gerência média que foram parcialmente retreinados para
POs durante a adoção. Quarto, a adoção foi dificultada
pela falta de mentalidade ágil e compreensão sobre o LeSS.
Por último, mas não menos importante, perguntamos a todos os entrevistados sobre lições
aprendido. Ex post, comunicação clara do panorama geral
da adoção pode aumentar a transparência e aprimorar
conscientização das partes interessadas envolvidas. Além disso, um FT
membro mencionou que exercícios práticos em cursos de treinamento
pode facilitar a adoção:
“À primeira vista, facilita a adoção do LeSS
ao praticar e compreender a teoria em pequenos
projetos, de preferência de forma lúdica.”
-FT, PFS
Uma comparação resumida das quatro adoções do LeSS pode
encontram-se na Tabela III.
C. Aplicação LeSS
Perguntamos aos entrevistados como seus produtos eram aplicados:
funções, artefatos e processos.
Funções: Todas as três funções padrão, nomeadamente FT, PO e SM, são
incluídos nos respectivos produtos (ver Tabela IV). Em contraste
para Scrum, o número de FTs (equipes de desenvolvimento em Scrum)
é de dois a oito no LeSS. No LeSS Huge, esse número
pode ser escalado ainda mais. Embora o MPN tenha 15 FTs,
decidiu usar múltiplas implementações LeSS porque o
produtos subordinados não têm um produto abrangente
personagem. FTs de OTD, PPM e PFS foram espalhados por
OTD PPM PFS
Início de 2017 Fim de 2017 Março de 2018
ÿ70 ÿ90 ÿ40
Alemanha, Alemanha, Polónia, Alemanha, Portugal,
África do Sul Portugal, Rússia Rússia
5 6 3
3 3
Menos Menos Enorme Menos
o mundo. De acordo com o SM no DTA, um problema foi
que o FT ainda era demasiado controlado por factores externos
e, portanto, não eram totalmente auto-organizados. Para o PPM,
parecia ser um problema menor. Os FTs da PFS já eram 90
– 95% auto-organizado. Por esta razão, existe um grande potencial
para melhoria, permitindo que os FTs atuem como organizações auto-organizadas
unidades. Conforme já indicado na Seção IV-B, o papel do PO
foi compartilhado por várias pessoas, ou seja, um OP era responsável
para o lado comercial e outro para o lado de TI. Isso surgiu
do fato de que uma pessoa sozinha não tinha o necessário
conhecimento para gerenciar o produto adequadamente, para que os produtos
decidiu dividir as responsabilidades. A “dupla liderança”
criou dificuldades na coordenação para atividades externas e internas
equipes.
“. . . ainda existe um pedido de compra no negócio e um
PO é do lado de TI, mas também na forma de um líder duplo. Se
você olha para LeSS ou Scrum, então devo dizer que tenho um duplo
líder é a pior coisa a fazer.”
- EA, PPM
A melhoria sugerida foi remover a liderança dupla
agrupando responsabilidades em um PO. A EA do PPM
sugeriu que o PO de TI deveria trabalhar mais com FTs e
atuar como uma OP substituta, onde poderia coletar informações valiosas
percepções. Além disso, o PPM tinha seis proprietários de produtos que eram
responsável pelas subáreas, representando as APOs conforme sugerido pelo
Menos Enorme [10]. Por último, mas não menos importante, todos os produtos introduzidos
o papel do Domínio PO (DPO) com mais tradicional
funções de gerenciamento de projetos. Sua responsabilidade incluía
sincronização das FTs e planejamento do orçamento e
capacidades. Eles também assumiram a responsabilidade geral pela
produtos e coordenados entre si em nível de portfólio.
“Eles [OPDs] são na verdade apenas responsáveis pelo orçamento
e capacidades e não deve estar envolvido no processo real
trabalhar."
- EA, PPM
A Figura II fornece uma visão geral das diferentes funções do PO em
os respectivos produtos. No DTA, o papel do SM não
existe por si só, mas sim o papel do mestre ágil (AM).
O AM do OTD não foi apenas responsável por ajudar os FTs
Machine Translated by Google

TABELA III: Comparação das adoções do LeSS nos quatro produtos.

MPN OTD PPM PFS

• Metas de otimização do
sistema do LeSS •
• Simplicidade do LeSS • Histórias de sucesso do
• Reduzir dependências entre
Otimização do corte de • Lidar com projetos de equipes ágeis • Minimizar
Razões para departamento de direção
produtos • Lidando com alta complexidade • a perda de informações
autônoma •
Adoção alta complexidade de Permitir mudanças de projeto integração entre equipes ágeis •
Introdução de três dias
projetos • Possibilitando para produto Lidar com a coordenação
para LeSS por Craig Larman entre equipes
mudanças de projeto para produto
• Permitir mudanças de projeto
para produto

• LeSS combinado com SAFe • LeSS combinado com

• Combinado LeSS Huge
ter um nível de portfólio DevOps para que os FTs
Combinado com Kanban para rastrear e
–
superior • LeSS tenham o conjunto de
Estruturas monitorar o progresso das
combinado com Kanban para gerenciar habilidades necessário e a
tarefas
épicos e recursos responsabilidade total para lançar software

• Programa de treinamento de
• Coaching SM •
Menos • Programa de treinamento de 2 2 dias para cada
Coaches ágeis externos • Coaches ágeis externos
dias para cada funcionário estendido com LeSS Huge
Treinamento
funcionário estendido com LeSS treinar funcionários internos treinar funcionários internos
• Coaches ágeis externos
que, por sua vez, treinam FTs
treinam funcionários internos

• LeSS estendido por um • LeSS estendido por um

nível de domínio • nível de domínio •
• LeSS Huge estendido por um • LeSS estendido por um
Adaptações Cadências comuns de sprint são Cadências comuns de sprint são nível de domínio nível de domínio
facilitadas por uma facilitadas por uma
abordagem de calendário único abordagem de calendário único

• Numerosas reuniões de
• Numerosas coordenações
• Compartilhando uma visão comum coordenação • Numerosas reuniões de
reuniões •
• Medo de perder poder • • Divisão de grandes requisitos em coordenação
Alta complexidade devido ao
Lacunas de comunicação número de FTs
requisitos menores • APOs • Medo de perder poder •
entre produtos • Alta mantendo seus próprios APBs • Departamentos especializados têm
• Baixo conhecimento prévio
complexidade do produto Sincronização de APBs • baixo conhecimento de LeSS
de métodos ágeis •
Desafios • Cortes corretos Lidando com questões culturais • Estabelecendo uma mentalidade
As responsabilidades de linha
de produtos • Equilibrando diferenças entre FTs ágil • Mudança de funções e
tradicionais dos funcionários
planejamento antecipado versus • Falta de transparência em responsabilidades devido
complicam seu foco no trabalho
design emergente • Liderança relação às funções ao trabalho ágil •
ágil • Liderança
dupla da função do PO e responsabilidades • Liderança dupla da
dupla da função de PO
Liderança dupla da função de PO
função do PO

• Comunicar o panorama geral da

adoção para obter o
• Redução de responsabilidades • Exercícios práticos em cursos
Lições compromisso • Realizar inspeção e
Aprendido de todas as partes interessadas
para algumas pessoas para aumentar a de formação aprofundam a
Adapte-se em intervalos regulares
velocidade da tomada de decisões compreensão do LeSS
• Realizar inspeção e
Adapte-se em intervalos regulares

TABELA IV: Resultados identificados para aplicação de papéis dentro dos

produtos. “O mestre ágil é responsável pela metodologia, ou seja, treinar o método,

Papel MPN OTD PPM PFS blindar a equipe dos stakeholders que querem algo, eliminar impedimentos e
organizar eventos.”
TF ÿ ÿ ÿ ÿ

DEPOIS ÿ ÿ ÿ ÿ -SM, OTD

SM ÿ ÿ ÿ ÿ
Todos os produtos envolveram funções adicionais que vão além do LeSS. Por
Funções Adicionais ÿ ÿ ÿ ÿ exemplo, o PFS incluiu a função de suporte do PO, que era responsável pela
criação de histórias de usuários, já que o PO não tinha tempo para isso. O
PFS também introduziu a função de analista de negócios (BA), responsável
por lidar com os problemas e requisitos dos FTs. Ele também foi o primeiro
para aplicar o LeSS e se auto-organizar, mas também para a gestão da ponto de contato para partes externas. Cada produto foi
mudança e gestão de pessoas:
Machine Translated by Google

MPN OTD PPM PFS

Domínio

Nível
Pedido de compra de domínio Pedido de compra de domínio Pedido de compra de domínio Pedido de compra de domínio

Negócios PO de TI Negócios PO de TI Negócios PO de TI Negócios PO de TI

DEPOIS DEPOIS DEPOIS DEPOIS

produtos produtos produtos produtos

Pendências Pendências Pendências Pendências

Área de Requisito Área de Requisito Área de Requisito

Recurso Recurso Recurso

Equipes Equipes Área PO Área PO Área PO Equipes

produto
Nível

Produto de área Produto de área Produto de área

do

Pendências Pendências Pendências

Recurso Recurso Recurso
Equipe Equipe Equipe

subproduto
Área de Requisito Área de Requisito Área de Requisito

Nível
de
Área PO Área PO Área PO

Produto de área Produto de área Produto de área

Pendências Pendências Pendências

Recurso Recurso Recurso
Equipe Equipe Equipe

Figura II: Visão geral das diferentes funções do PO nos quatro produtos.

acompanhados por diferentes tipos de arquitetos, como TI TABELA V: Resultados identificados para aplicação dos artefatos

arquitetos, arquitetos corporativos e arquitetos de soluções que dentro dos produtos.

atuou principalmente como consultores externos para vários projetos de arquitetura

Artefatos MPN OTD PPM PFS
tópicos. Tais tópicos incluem: mostrar o posicionamento do
Backlog do produto ÿ ÿ ÿ ÿ
produto no contexto geral da organização, orientando os FTs em
a realização da futura arquitetura do produto, e Pendências da Sprint ÿ ÿ ÿ ÿ
garantindo que os FTs cumpram os padrões arquitetônicos. Nisso
Meta de sprint ÿ ÿ ÿ ÿ
Neste contexto, a EA do PPM afirmou ainda que:
Incremento do produto ÿ ÿ ÿ ÿ
“Minha opinião pessoal é que quando alguém não
Definição de Concluído ÿ ÿ ÿ ÿ
sabem como continuar chamam os arquitetos. Eles são realmente
apenas extintores de incêndio ad hoc, que precisam chegar rapidamente.” Artefatos Adicionais ÿ ÿ ÿ ÿ
- EA, PPM

Artefatos: A Tabela V fornece uma visão geral dos artefatos usados.

Em geral, existia um backlog de produto para todos os produtos. - AC, MPN
A principal diferença era que MPN, OTD e PFS tinham um
Isto foi validado pela IA do PPM:
pendências de produto, enquanto o PPM tinha uma pendência de produto comum e seis
pendências de produto específicas de RA, as chamadas pendências de produto de área.
“Provavelmente [o DoD] foi introduzido uma vez no início
Segundo um entrevistado, isso causou os seguintes
e agora está em algum canto, em algum lugar em Confluence
problema: se houver apenas um backlog de produto comum em
alguma página subordinada, que ninguém acessou por um
nível de produto para diversas subáreas, a única priorização
muito tempo. Isso parece muito plausível para mim.”
com base na importância torna-se difícil, pois geralmente não pode - IA, PPM
pode-se dizer que um subproduto é mais importante que outro
um. Em geral, todos os produtos tinham um backlog de sprint, sprint Os entrevistados consideraram a falta de uso do DoD para
objetivo e incrementos de produto como artefatos. A definição de ser problemático, pois o incremento do produto não foi avaliado
done (DoD) foi implementado por todos os produtos e foi de acordo com critérios pré-definidos. OTD seguiu um caminho diferente
foram muito discutidos porque não foram totalmente utilizados. O PO abordagem. Uma equipe externa desenvolveu um DoD geral e
do PFS descreveu o DoD como particularmente importante, uma vez que então o PO adaptou-o para que suas respectivas características se ajustassem
define expectativas claras em relação às histórias de usuários em relação requisitos individuais. Alguns entrevistados mencionaram dois
parceiros externos. No entanto, o PFS foi o único produto que artefatos adicionais. PPM e PFS também usaram a definição de
tinha um DoD finalizado. Em vez disso, o entrevistado no MPN afirmou: entrada (DoE) que foi criada pelo PO. O DoE foi usado
para descrever requisitos aproximados para histórias de usuários individuais. Em
“Artefatos básicos como o DoD existem em todos os produtos, Além disso, MPN, PPM e PFS usaram a definição de pronto
no entanto, não são usados. (DoR) como a última etapa antes da implementação. O DoR foi
Machine Translated by Google
utilizado para descrever histórias de usuários prontas para implementação”.
Contudo, um entrevistado (SA) do PPM afirmou que o DoE
eventualmente desapareceu.
TABELA VI: Resultados de identificação para aplicação dos processos
dentro dos produtos.
Processos MPN OTD PPM
Corrida ÿ ÿ ÿ ÿ
Refinamento do Backlog do Produto ÿ ÿ ÿ ÿ
Planejamento de Sprint (1 e 2) ÿ ÿ ÿ ÿ
Scrum Diário ÿ ÿ ÿ ÿ
Revisão da Sprint ÿ ÿ ÿ ÿ
Retrospectiva (equipe e geral) ÿ ÿ ÿ
Processos Adicionais ÿ ÿ ÿ ÿ
Processos: Em geral, todos os eventos LeSS foram amplamente adotados
em todos os produtos (ver Tabela VI). De acordo com a SA de
PPM, foi difícil conseguir que todas as pessoas relevantes participassem
Encontros. Reuniões foram planejadas nos produtos no
mesmo tempo (abordagem de calendário único), o que tornou a cooperação
e coordenação entre pessoas em diferentes reuniões muito
difícil. Além disso, as retrospectivas dentro do PFS não foram
implementado ainda:
“Bem, não temos acompanhado o retrô tão de perto
até agora, mas decidimos fazer mais.”
-FT, PFS
Todos os produtos organizaram comunidades de práticas (CoPs)
para colaboração e troca de informações dentro de equipes técnicas
e domínios de negócios em todos os produtos. Um entrevistado também
acrescentou que:
“Comunidades de práticas são muito úteis para o
coordenação de processos, métodos e ferramentas, bem
quanto à harmonização e padronização abrangentes.”
-SM, OTD
A arquitetura CoP foi a CoP que mais se destacou dentro
todos os produtos conforme foram implementados por todos os produtos. Lá,
arquitetos e outras partes interessadas discutem questões relacionadas à arquitetura
tópicos, tomar decisões e projetar diretrizes de arquitetura
que também afetam os FT:
“Existe uma comunidade de arquitetura que não apenas discute,
mas também pode tomar decisões. . . . Você tem que ser capaz de
fornecer informações às equipes, mas de preferência por meio de uma comunidade
abordagem e não através de papéis externos fortes.”
- AC, MPN
CoPs adicionais foram organizadas para OPs e SMs, bem como
para o domínio de teste. O primeiro permite que DPOs e OPs
coordenar e encontrar uma direção comum em matéria empresarial
nível. Em intervalos regulares, o MPN e o OTD também organizaram
inspecionar e adaptar eventos para verificar onde eles estão no
processo de adoção, o que melhorar e como ajustar seu
comportamento respectivamente. Por último, mas não menos importante, PPM e PPM
organizou grandes eventos que aconteciam uma ou duas vezes por ano em
um dos sites para facilitar a coerência e confiança da equipe.
V. DISCUSSÃO
PFS
A. Principais conclusões
Discutimos agora os principais resultados de nossas descobertas.
Principais conclusões RQ1: Depois de analisar diferentes adoções de
LeSS em quatro produtos, identificamos após cinco sucessos
fatores. Primeiro, a adoção deve ser 100% transparente, pois
a transparência incentiva os FTs a fornecer software em níveis mais elevados
qualidade.
Em segundo lugar, cursos e workshops de treinamento abrangentes
ÿ facilitam a adoção, pois fornecem um entendimento compartilhado
de novas práticas, funções e responsabilidades. Terceiro, funcionários
devem ser envolvidos o mais cedo possível, a fim de minimizar
resistência à mudança. Em quarto lugar, os gestores devem estar conscientes
funcionários insatisfeitos para manter seu status e poder.
Assim, os gestores devem conscientizar sobre o
valor da mudança para a organização. Quinto, a motivação
por trás do LeSS deve ser devidamente promovido, anunciado e
comunicado.
Principais conclusões RQ2: Com base nas quatro aplicações LeSS,
emergem as seguintes seis conclusões principais. Primeiro, embora o
auto-organização dos FTs foram reconhecidos dentro do
organização, as cadências de sprint foram organizadas centralmente usando um
a chamada abordagem de “calendário único”. Em segundo lugar, todos os quatro produtos
foram estendidos por um nível de domínio e apoiados por um DPO
já que os produtos não eram necessariamente independentes uns dos outros
outro. Terceiro, devido à actual estrutura organizacional, o
o papel do PO era partilhado por duas ou três pessoas, resultando
na chamada “liderança dupla ou mesmo tripla”. Muitos
entrevistados reclamaram dessa situação, pois desacelerou
processos inativos e prejudicou o que o LeSS deseja alcançar:
decisões rápidas e ágeis. Quarto, todos os produtos estenderam o LeSS
envolvendo funções adicionais, como BAs, suporte de PO,
serviços compartilhados e arquitetos de soluções e corporativos.
Quinto, todos os quatro produtos ampliaram o LeSS com recursos adicionais
processos para facilitar a troca de conhecimento compartilhado
entre os produtos. Esses eventos incluíram vários tipos
de comunidades de práticas como arquitetura, SM &
PO ou comunidades de teste. Em sexto lugar, os produtos entrevistados
organizou grandes eventos de formação de equipes que aconteceram uma vez
ou duas vezes por ano em um dos sites. Com eles, eles visaram
na construção de confiança entre FT e na superação de barreiras culturais.
B. Ameaças à validade
Discutimos ameaças potenciais à validade juntamente com um esquema de
¨
avaliação sugerido por Runeson e Host [18]. Primeiro, abordamos a validade
do construto entrevistando múltiplos papéis
em quatro produtos diferentes. Também transcrevemos, codificamos,
e analisou as entrevistas. Em segundo lugar, a validade interna não é
relevante, pois esta pesquisa não foi explicativa nem causal
Machine Translated by Google

¨ ÿ

[18]. Terceiro, abordamos a validade externa fornecendo uma [8] O. Uluda g, M. Kleehaus, C. Caprano e F. Matthes, “Identificando e estruturando desafios

descrição detalhada do caso e focando na generalização analítica
[18]. Este artigo fornece insights empíricos que permitem uma
compreensão profunda da adoção e aplicação do LeSS. As
conclusões apresentadas devem ser vistas como informações
valiosas para outras organizações que pretendem adotar e aplicar
o LeSS. Por último, garantimos a confiabilidade dos nossos
no desenvolvimento ágil em larga escala com base em uma revisão de literatura
estruturada”, na 22ª Conferência Internacional sobre Computação de Objetos Distribuídos
Empresariais (EDOC). IEEE, 2018, pp.
[9] C. Larman e B. Vodde, Dimensionando o Desenvolvimento Lean e Ágil: Pensamento e Ferramentas
Organizacionais para Scrum em Grande Escala. Addison-Wesley, 2008.
[10] ——, ¨ Scrum em larga escala: mais com LeSS. Addison-Wesley, 2016.
ÿ

[11] O. Uluda g, M. Kleehaus, X. Xu e F. Matthes, “Investigando o papel dos arquitetos no

resultados utilizando um protocolo de estudo de caso com
procedimentos detalhados para coleta e análise de dados.
Também coletamos dados de diferentes fontes por vários
entrevistadores para permitir a triangulação de dados e observadores [12]
VI. CONCLUSÃO E TRABALHO FUTURO
O sucesso dos métodos ágeis para pequenas equipes inspirou
grandes organizações a aplicá-los em larga escala usando
estruturas ágeis escalonáveis [4], [5]. Embora o número de
organizações que utilizam essas estruturas esteja aumentando, a
literatura científica que fornece análises aprofundadas ainda é
escassa [6], [7]. Nosso objetivo foi preencher essa lacuna
fornecendo um estudo de caso sobre a adoção e aplicação do
LeSS em quatro produtos diferentes de um fabricante de
automóveis alemão. Nossas descobertas indicam que uma
dimensionamento de estruturas ágeis”, na 21ª Conferência Internacional sobre Enterprise
Distributed Object Computing Conference (EDOC). IEEE, 2017, pp.
[18].A. Putta, M. Paasivaara e C. Lassenius, “Benefícios e desafios da adoção da estrutura ágil
em escala (segura): Resultados preliminares de uma revisão de literatura multivocal”, na
Conferência Internacional sobre Melhoria de Processos de Software Focada no Produto.
Springer, 2018, pp.
[13] J. Pries-Heje e MM Krohn, “O caminho seguro para a organização ágil”, em Proceedings of
the XP2017 Scientific Workshops. ACM, 2017, pág. 18.
[14] M. Paasivaara, “Adotando segurança para escalar ágil em uma organização distribuída
globalmente”, na 12ª Conferência Internacional IEEE sobre Engenharia de Software
Global. IEEE, 2017, pp.
[15] M. Paasivaara e C. Lassenius, “Escalando scrum em um grande projeto distribuído”, no
Simpósio Internacional de Engenharia e Medição de Software Empírico (ESEM). IEEE,
2011, pp.
[16] ——, “Escalando scrum em uma grande organização distribuída globalmente: Um estudo de
caso”, na 11ª Conferência Internacional sobre Engenharia de Software Global (ICGSE).
IEEE,
¨ 2016, pp.
ÿ

[17] O. Uluda g, M.Hauder, M. Kleehaus, C. Schimpfle e F. Matthes, “Apoiando o desenvolvimento

adoção transparente incentiva as equipes a fornecer software de
alta qualidade e que cursos de treinamento e workshops
abrangentes facilitam a adoção. Descobrimos também que a
organização do caso ampliou o LeSS com funções e processos
ágil em larga escala com design orientado a domínio”, na Conferência Internacional sobre
Desenvolvimento Ágil de Software. Springer, 2018, pp.
¨
[18] P. Runeson e M. Host, “Diretrizes para conduzir e relatar pesquisas de estudos de caso em
engenharia de software”, Empirical Software Engineering, vol. 14, não. 2, pág. 131, 2009.

adicionais para facilitar a troca de conhecimento compartilhado

[19] MQ Patton, Avaliação qualitativa e métodos de pesquisa. Publicações SAGE, 1990.
entre produtos, para construir confiança entre as equipes e para adaptá-lo à estrutura organizacional atual.
Embora estejamos confiantes de que nossas descobertas [20] TC Lethbridge, SE Sim e J. Singer, “Estudando engenheiros de software: técnicas de coleta
de dados para estudos de campo de software”, Empirical Software Engineering, vol. 10,
contribuirão para o corpo de conhecimento existente sobre
não. 3, pp. 311–341, 2005.
experiências reais relacionadas ao LeSS, encorajamos outros [21] MB Miles, AM Huberman e J. Saldana, Análise qualitativa de dados: um livro de referência
pesquisadores a realizar estudos de caso mais aprofundados de métodos. Publicações SAGE, 2014.

sobre LeSS e outras estruturas ágeis de escalonamento. Por

exemplo, seria interessante estudar até que ponto as empresas
têm de adaptar as suas estruturas e processos organizacionais
para utilizar o LeSS. Em estudos futuros, os investigadores
deverão também realizar análises cruzadas com o objetivo de
comparar a adoção e aplicação do LeSS em diferentes tipos de
organizações, por exemplo, nativos digitais vs. empresas tradicionais.

REFERÊNCIAS

[1] K. Beck, Programação extrema explicada: abrace a mudança. Addison-Wesley, 2000.

[2] K. Schwaber e J. Sutherland, “O guia do scrum”, Scrum.org, Tech.

Rep., 2017.
[3] P. Kettunen, “Estendendo a agilidade do projeto de software com a agilidade empresarial no
desenvolvimento de novos produtos”, Processo de Software: Melhoria e Prática, vol. 12,
não. 6, pp. 541–548, 2007.
[4] T. Dingsøyr e NB Moe, “Rumo aos princípios do desenvolvimento ágil em larga escala”, em
Métodos Ágeis. Desenvolvimento, refatoração, teste e estimativa em larga escala, T.
Dingsøyr, NB Moe, R. Tonelli, S. Counsell, C. Gencel e K. Petersen, Eds. Springer, 2014,
pp.
[5] M. Alqudah e R. Razali, “Uma revisão do dimensionamento de métodos ágeis no
desenvolvimento de software em grande escala”, International Journal on Advanced
Science, Engineering and Information Technology, vol. 6, não. 6, pp. 828–837, 2016.

[6] VersionOne, “12º relatório anual sobre o estado do ágil”, VersionOne, Tech. Deputado,
2018.
[7] K. Dikert, M. Paasivaara e C. Lassenius, “Desafios e fatores de sucesso para transformações
ágeis em larga escala: Uma revisão sistemática da literatura”, Journal of Systems and
Software, vol. 119, pp. 87–108, 2016.