ÁGIL EM ESCALA SAFe, LESS, NEXUS(NPG5639) IPE3452_EBOOK_Apresentacao

Prévia do material em texto

E-book
Ágil em escala 
SAFe®, LeSS® e 
Nexus®
Sumário 
1. O que é ágil em escala?
2. Introdução ao SAFe®
3. Fundamentos do SAFe®
4. Estrutura do SAFe® Essencial
5. Estruturas maiores do SAFe®
6. Introdução ao LeSS®
7. Estrutura do framework LeSS®
8. Introdução ao Nexus®
9. Estrutura do Nexus®
10. Revisão, comparativo e referências
Capítulo 1 – O que é ágil em escala?
1.1 O que é ágil em escala?
1.2 Por que usar ágil em escala?
1.3 Alguns conceitos ágeis
1.4 Necessidade de coordenação do ágil em escala
1.1 O que é ágil em escala?
Primeiramente, vamos separar as
coisas...
Gestão ágil de projetos é uma
modalidade de gerenciamento
que nasceu na engenharia de
software.
Em 2001, em Utah (EUA), 17
desenvolvedores de software se
reuniram e criaram o Manifesto
Ágil, que aborda valores e
princípios no desenvolvimento de
software.
1.1 O que é ágil em escala?
A partir daí, várias abordagens
“leves ou ágeis” nasceram e
outras que já existiam se
fortaleceram, criando grandes
movimentos na indústria de
software de substituir os
métodos em cascata de
desenvolvimento por métodos
ágeis.
DSDM
1.1 O que é ágil em escala?
Estruturas ágeis como o scrum e o
kanban vêm provando, há algum
tempo, que conseguem entregar
soluções melhores e mais rápidas
aos clientes, além de garantir a
capacidade de mudança de direção
com mínimo risco e impacto no
projeto, já que, através das
iterações, partes granulares
funcionais do projeto são testadas e
entregues com maior frequência.
1.1 O que é ágil em escala?
Mas onde entra o ágil em escala?
Organizações de todos os tamanhos
já estão observando bons resultados
em equipes individuais ágeis, mas, e
quando isso não é mais suficiente?
É necessário institucionalizar o ágil
em toda a organização, para assim
conseguir que múltiplas equipes
ágeis, com um objetivo em comum,
atendam à necessidade do cliente.
1.1 O que é ágil em escala?
Para o ágil em escala ser adotado
por toda a organização, desde o C-
Level até a operação, é necessário
muita coordenação, gestão de
dependências e integração entre
diferentes equipes e áreas.
A estrutura tradicional deve ser
alterada para criar maior
envolvimento entre equipes e
pessoas, todas igualmente com foco
no produto. E
n
ge
n
h
ar
ia
 d
e 
si
st
em
as
D
es
en
vo
lv
im
en
to
Te
st
es
 d
e 
so
ft
w
ar
e
Im
p
la
n
ta
çã
o
 e
 s
u
st
en
ta
çã
o
1.1 O que é ágil em escala?
Ágil em escala não é uma organização com
vários times ágeis trabalhando, cada um deles,
em um produto diferente.
Ágil em escala é quando um único
produto/serviço ou resultado possui vários
times ágeis trabalhando com o mesmo objetivo
(meta), de forma integrada e colaborativa.
1.2 Por que usar ágil em escala?
O mundo mudou...
O mercado pede cada vez mais e
mais rápido por inovações e
melhorias. Produtos se tornam
obsoletos em pouco tempo, se não
houver atualizações constantes e de
valor ao novo contexto dos usuários
(perda de competitividade).
V
Volatility
U
Uncertainty
C
Complexity
A
Ambiguity
1.2 Por que usar ágil em escala?
Questão de sobrevivência...
Deve-se responder à necessidade
dos clientes e se tornar cada vez
mais competitivo, utilizando
tecnologias como habilitadores
estratégicos e inspirar colaboradores
com formas ágeis de trabalhar.
1.2 Por que usar ágil em escala?
Conecta a estratégia ao
desenvolvimento...
• Vincula as metas do
negócio ao
desenvolvimento ágil.
• Temas, objetivos e métricas
definidos claramente.
1.3 Alguns conceitos ágeis
Planejamento
Backlog do produto
Time scrum individual
Sprint 
backlog
30 dias
execução
24h
Incremento do produto 
potencialmente utilizável
Sprint
1.3 Alguns conceitos ágeis
Planejamento 
geral
Time scrum em escala
Plan
Daily
Daily
Review
Retro
Retro
Plan
Daily
Retro
Plan
Daily
Retro
A
B
C
Plan
Daily
Daily Retro
Retro
Plan
Daily
Retro
Plan
Daily
Retro
A
B
C
Plan
Daily
Daily Retro
Retro
Plan
Daily
Retro
Plan
Daily
Retro
A
B
C
Review Review
Backlog 
do 
produto
Incremento do 
produto 
potencialmente 
utilizável
1.4 Necessidade de coordenação do ágil em escala
É um grande desafio de estender a cultura a todas equipes e áreas
da organização, porém muitas organizações tiveram sucesso
utilizando frameworks para a coordenação de toda a estrutura ágil
em escala.
Em nosso módulo abordaremos três populares frameworks:
Capítulo 2 – Introdução ao SAFe®
2.1 Sobre o Scaled Agile Framework (SAFe®) 
2.2 Introdução ao Scaled Agile Framework
2.1 Sobre o Scaled Agile Framework (SAFe®): o início
Criado em 2011 por Dean
Leffingwell, uma das maiores
autoridades em desenvolvimento
de software e autor de vários
livros sobre desenvolvimento e
requisitos de software. Seus
trabalhos formam grande parte
da base do pensamento moderno
em desenvolvimento de software
lean-agile em escala corporativa.
2.1 Sobre o Scaled Agile Framework (SAFe®): Dean 
Leffingwell
Entre suas obras, as mais conhecidas são: SAFe Reference Guide
(2018), Agile Software Requerimentos (2010) e Scaling Software
Agility (2007).
2.1 Sobre o Scaled Agile Framework (SAFe®): missão
Permitir a agilidade comercial
necessária para as empresas
competirem e prosperarem na era
digital.
Essa missão exige que todas as partes
interessadas da organização sejam
envolvidas em soluções adotando os
princípios e práticas de lean e agile.
2.2 Introdução ao Scaled Agile Framework
É uma base de conhecimento
disponível gratuitamente para
ajudar pessoas e organizações a
desenvolver softwares e
sistemas melhores.
Ela ajuda a fornecer produtos,
soluções e serviços no menor
tempo e maior qualidade
possível.
2.2 Introdução ao Scaled Agile Framework
O SAFe® é uma junção de
práticas de desenvolvimento
ágeis (scrum, XP...),
desenvolvimento enxuto de
produtos (lean) e o
pensamento sistêmico, tudo
isso fundamentado nos
princípios e valores lean-agile.
2.2 Introdução ao Scaled Agile Framework
Além disso, o framework
fornece orientações,
responsabilidades e
ferramentas que ajudam a
impulsionar o valor dos
resultados do negócio.
2.2 Introdução ao Scaled Agile Framework: 
“Big Picture”
No site do framework
(https://v46.scaledagileframew
ork.com/#) você encontra o
“Big Picture”, um gráfico
interativo que fornece a visão
geral do SAFe®.
Neste site também é possível
baixar uma variedade de
materiais relacionados à
implantação e manutenção da
estrutura SAFe®.
https://v46.scaledagileframework.com/
2.2 Introdução ao Scaled Agile Framework: 
adaptável ao tamanho da corporação
Dependendo do contexto da
organização, tamanho e área de
atuação, o SAFe® pode ser
utilizado em sua configuração
mínima (50 a 125 profissionais)
até corporações complexas com
milhares de profissionais.
2.2 Introdução ao Scaled Agile Framework: 
as configurações
Na versão do SAFe® 4.6, é
possível encontrar quatro
modelos prontos para
implantação do framework,
desde o menor até o maior
ambiente:
• Essential SAFe®
• Large Solution SAFe®
• Portfolio SAFe®
• Full SAFe®
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Essential SAFe®
• Essential SAFe®
É o coração e o ponto inicial do SAFe®. O nível de equipe e programa
formam uma estrutura chamada agile release train (ART) ou trem de
lançamento ágil.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Essential SAFe®
Destaques do Essential SAFe®
• O ART faz o alinhamento de gerência, equipes e partes
interessadas para um objetivo em comum e também fornece
funcionalidades e infraestrutura técnica através de incrementos a
cada duas semanas.
• Incrementos de programa (PIs) são realizados em timebox ou sob
demanda, com base na necessidade do negócio.
• Utilizam princípios e abordagens do lean user experience (UX).
• Mentalidade DevOps para planejar, desenvolver, testar,
implantar, liberar e manter uma solução.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Essential SAFe®
Funções de alinhamento da missão do Essential SAFe®
• Arquiteto/engenheiro de sistema (pensamento sistêmico)• Product management (voz do cliente/backlog do programa)
• Release train engineer (SM do ART/kanban/I&A/PI)
• Business owners (partes interessadas pelo return on investment
[ROI] do ART)
• Client (comprador final da solução, participa do
desenvolvimento)
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Essential SAFe®
Atividades principais de coordenação do ART
• Planejamento do PI – planejamento presencial de alinhamento
da missão de todas equipes.
• Demonstração do sistema – visão integrada dos recursos
entregues por todas equipes em um ART.
• Inspecionar e adaptar – evento em que as equipes refletem e
identificam melhorias e acrescentam as soluções em um backlog
de melhorias.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Essential SAFe®
• Portfólio SAFe®
Alinha a execução da estratégia da empresa, organizando tudo em
torno de um ou mais fluxos de valor. Confere agilidade aos negócios
por meio de um portfólio ágil de operações e governança enxuta,
garantindo que os investimentos trarão benefícios.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Essential SAFe®
Destaques do portfólio SAFe®
• Orçamento enxuto – rápida tomada de decisão, controle
financeiro e prestação de contas apropriados.
• Fluxos de valor – financiamento para as pessoas e recursos
necessários agregarão valor ao negócio através de soluções.
• Kanban do portfólio – torna visível o trabalho (WIP) e cria limites
de acordo com as capacidades dos times.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Essential SAFe®
Funções de mais alto nível de responsabilidade e governança SAFe®
• Gerenciamento de portfólio enxuto – indivíduos com mais alto
nível de tomada de decisão e responsabilidade financeira no
portfólio SAFe® (executivos da empresa).
• Proprietários dos épicos – coordenam os épicos do portfólio por
meio do kanban deste.
• Arquiteto corporativo – pessoa ou grupo que fornece direção
técnica estratégica.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Large Solution SAFe®
• Large Solution SAFe®
Apropriado a soluções grandes e complexas que podem envolver
vários ARTs. É comumente encontrado em indústrias como
aeroespacial, defesa, automotiva e governamental.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Large Solution SAFe®
Destaques do Large Solution SAFe®
• Trem de solução – principal elemento, alinha tudo em torno da
solução, missão e lista de pendências.
• Equipe de sistema – interna ou externa, realiza entregas de
produtos ou serviços para o trem de solução.
• Estrutura econômica – limites financeiros para tomada de
decisão.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Large Solution SAFe®
Destaques do Large Solution SAFe®
• Intenção da solução – repositórios de suporte a conformidade,
práticas de qualidade e verificação, por exemplo, engenharia de
sistemas baseados em modelo (MBSE).
• Contexto da solução – descrição das interfaces, empacotamento
e implantação no ambiente operacional.
• Kanban da solução – elemento de facilitação do fluxo de recursos
para a solução.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Large Solution SAFe®
Funções de alinhamento dos ARTs e fornecedores à missão comum
• Arquiteto/engenheiro de solução – indivíduo ou equipe que
define a visão técnica e arquitetônica da solução.
• Gerente de soluções – voz do cliente da solução, define requisitos
e orienta através do kanban da solução.
• Engenheiro do trem de solução (STE) – líder que facilita e orienta
o trabalho de todos ARTs e fornecedores.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Large Solution SAFe®
Atividades de coordenação de vários ARTs e fornecedores
1. Planejamento pré e pós-PI – eventos de preparação e
acompanhamento do incremento do programa.
2. Demonstração da solução – resultado do desenvolvimento de
vários ARTs (internos e externos), integrado e visível para clientes
e partes interessadas.
3. Inspeção e adaptação (I&A) – reunião em que múltiplos ARTs
buscam soluções de problemas e adicionam itens ao backlog de
melhoria.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Full SAFe®
• Full SAFe®
Versão completa da
configuração do framework,
contemplando todos os
níveis de configuração do
SAFe® para empresas que
desenvolvem e mantêm
grandes soluções integradas
com o esforço de centenas
de pessoas.
2.2 Introdução ao Scaled Agile Framework: 
as configurações – Full SAFe®
Destaques do Full SAFe®
• Combinação de todas as configurações do SAFe®, desde o Essential,
que é a base de todas as configurações, até os níveis de portfólio e
Large Solution.
• Robustez para grandes companhias com uma configuração mais
abrangente.
• As empresas podem iniciar pelo nível essencial e crescer de acordo
com suas necessidades.
• Cada uma das configurações é suportada pela paleta de abrangência
(spanning palette) e pelos elementos de fundação (foundation
elements), que veremos a seguir.
Capítulo 3 – Fundamentos do SAFe®
3.1 Fundamentos do SAFe®
3.2 Mapa de implementação do SAFe®
3.3 Princípios do SAFe®
3.1 Fundamentos do SAFe®
As bases ou fundamentos do SAFe® englobam toda a mentalidade,
valores, princípios, orientações e papéis dos líderes para gerar valor
em escala com sucesso ao negócio.
Lean-agile leadership
Core values Lean-agile mindset SAFe® principles
Implementation 
roadmap
SAFe® Program 
Consultant
3.1 Fundamentos do SAFe®:
lean-agile leadership
Os líderes (gerência) têm a
responsabilidade final pelos
resultados do negócio.
Eles devem ser treinados e se tornar
treinadores dessas maneiras de
pensar e operar, mantendo-se
constantemente atualizados, sendo
alunos e professores ao longo da
vida. Eles entendem e adotam os
princípios e práticas da liderança
lean e agile.
3.1 Fundamentos do SAFe®:
lean-agile leadership
Funções da liderança ágil enxuta
1. Lidere a mudança, orientando
comportamentos e hábitos.
2. Conheça o caminho, enfatize a
aprendizagem ao longo da vida,
criando um ambiente que
promova o aprendizado.
3. Desenvolva pessoas:
habilidades e planos de carreira.
3.1 Fundamentos do SAFe®:
lean-agile leadership
Funções da liderança ágil enxuta
4. Inspirar e alinhar com a missão, assim
como minimizar restrições. Elimine a
desmotivação, criando missão e visão
em torno do valor.
5. Descentralize a tomada de decisão,
ensinando-os a resolver problemas.
6. Desbloqueie a motivação intrínseca
dos profissionais de conhecimento –
domínio de novas e crescentes
habilidades.
3.1 Fundamentos do SAFe®:
lean-agile leadership
O papel do gerente de desenvolvimento
Enfatiza o valor de equipes autônomas, auto-organizadas e multifuncionais de alto desempenho e
tem cinco responsabilidades básicas:
1. Desenvolvimento de pessoas e equipes (atrair, recrutar, reter, ouvir, apoiar, aconselhar)
2. Execução do programa (marcos, estrutura, oficinas I&A, proteger, auxiliar STE e RTE, PI,
Demo)
3. Alinhamento (visão, missão, temas estratégicos, treinar e trabalhar com partes interessadas)
4. Transparência (liberdade e segurança no ambiente, comunicação aberta, registro e radiadores
de informações e valorização da produtividade, qualidade e transparência acima das políticas
internas)
5. Qualidade integrada (SW, HW e FW; qualidades técnicas de apoio à qualidade, comunidades
de prática e suporte a UX)
3.1 Fundamentos do SAFe®:
core values
Valores fundamentais
O SAFe® possui quatro valores
fundamentais, considerado suas
crenças:
• Alinhamento
• Qualidade integrada
• Transparência
• Execução do programa
Alinhamento
Qualidade 
integrada
Transparência
Execução do 
programa
3.1 Fundamentos do SAFe®:
core values
Valores fundamentais - Alinhamento
Não se trata apenas do alinhamento entre as opiniões das equipes, mas:
• Decisões estratégicas/financeiras no portfólio, visão e roteiro.
• Objetivos e metas do PI usados para comunicar expectativas e
compromissos.
• Sincronização e cadência aplicadas a todosos times.
• Arquiteturas e orientação para garantir uma solução sólida, robusta e
escalável.
• Priorização econômica com base no contexto atual.
O alinhamento habilita a autonomia e permite alcançar valor com
melhores decisões.
3.1 Fundamentos do SAFe®:
core values
Valores fundamentais – Qualidade integrada
Cada incremento deve refletir padrões de qualidade:
Software – extreme programing (XP), test-driven development
(TDD), integração e implantação contínua, pair work, dentre outros.
Hardware – erros podem custar mais caro aqui, por isso algumas
práticas são recomendadas, como ciclos de design e integração
frequentes, engenharia de sistemas baseada em modelo, design
baseado em conjunto (SBD), entre outras.
3.1 Fundamentos do SAFe®:
core values
Valores fundamentais – Qualidade integrada
Integração de sistemas – integração de diferentes subsistemas e
componentes (HW/FW/SW) utilizando práticas como integração
frequente em nível de sistema e solução, teste de requisitos
funcionais e não funcionais e demonstração de sistemas e solução.
Conformidade – supervisões regulatórias, requisitos rigorosos,
políticas e procedimentos em um sistema de gerenciamento de
qualidade e especificação de requisitos de software (SRS).
3.1 Fundamentos do SAFe®:
core values
Valores fundamentais – Transparência
Encontrar um erro é difícil, ainda mais quando está escondido em
segredos...
Confiança e integridade são palavras-chave para se criar um
ambiente de transparência.
Através do kanban é possível ver atrasos no programa, nas equipes e
nas tarefas. Isso habilita a inspeção e adaptação em oficinas e todos
podem ver as novas iniciativas.
Equipes e ARTs podem ver o portfólio do negócio e épicos
facilitadores.
Todos podem entender a velocidade do trabalho em andamento.
3.1 Fundamentos do SAFe®:
core values
Valores fundamentais – Execução do programa
A execução do programa é concentrada no ART, e a entrega do fluxo
de valor depende da capacidade dos ARTs.
Mesmo os ARTs sendo base da execução do programa, requerem
suporte ativo das lideranças com uma orientação para os resultados,
por fim, criando contexto e significado para as equipes.
3.1 Fundamentos do SAFe®:
lean-agile mindset
Mentalidade lean-agile
Aplicando os pensamentos lean e
agilidade, é possível aprimorar a
cultura da empresa e alcançar
seus objetivos, obtendo maior
valor.
Suposições
Ações de líderes 
e profissionais
Crenças
Fundação: liderança lean-agile
A gerência aplica e ensina o pensamento enxuto, baseando-se em decisões de longo 
prazo. 
3.1 Fundamentos do SAFe®:
lean-agile mindset
Pensamento lean – SAFe® House of Lean
Respeito 
pelas 
pessoas e 
culturas
- Pessoas fazem o 
trabalho
- Construir 
parcerias baseadas 
na verdade
- Para mudar a 
cultura, mude a 
organização 
Fluxo
- Otimização 
contínua
- Construir com 
qualidade garante 
o fluxo
- Evite paradas 
contínuas nos 
projetos
- Feedback rápido
Inovação
- Valide com seus 
clientes
- Mude de direção 
quantas vezes 
forem necessárias
- Explore 
continuamente
Melhoria 
implacável
- Otimize o todo
- Considere com 
cuidado, aja 
rapidamente
- Aplique 
ferramentas lean 
(causa raiz, 
medidas 
preventivas)
O objetivo: valor
Máximo valor em menor tempo. Alta qualidade e valor para as pessoas.
3.1 Fundamentos do SAFe®:
lean-agile mindset
Adoção dos valores do Manifesto Ágil 
Estamos descobrindo melhores maneiras de desenvolver softwares ao fazê-los e ao ajudar outras pessoas a 
fazê-los. Através desse trabalho, chegamos ao valor:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com cliente mais que negociação de contrato
Responder à mudança mais que seguir um plano
Fonte: http://agilemanifesto.org/
http://agilemanifesto.org/
3.1 Fundamentos do SAFe®:
lean-agile mindset
12 princípios do Manifesto Ágil
1. Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso.
2. Mudanças nos requisitos são bem-vindas, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a 
vantagem competitiva do cliente.
3. Forneça software funcionando com frequência, de algumas semanas a alguns meses, de preferência à menor escala de tempo.
4. Pessoas de negócios e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.
5. Crie projetos em torno de indivíduos motivados. Dê a eles o ambiente e o apoio de que precisam e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para dentro de uma equipe de desenvolvimento é a conversa cara a cara.
7. O software em funcionamento é a principal medida de progresso.
8. Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um 
ritmo constante indefinidamente.
9. A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.
10. A simplicidade (arte de maximizar a quantidade de trabalho não realizado) é essencial.
11. As melhores arquiteturas, requisitos e projetos emergem das equipes auto-organizadas.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e depois ajusta seu comportamento de acordo.
Fonte: http://agilemanifesto.org/iso/ptbr/principles.html
http://agilemanifesto.org/iso/ptbr/principles.html
Go SAFe®
Treinar agentes 
de mudança 
lean-agile
Treinar 
executivos, 
gerentes e líderes
Criar centro de 
excelência lean-
agile
Identificar fluxos 
de valor ARTs
Criar o plano de 
implementação
Preparar para o 
lançamento do 
ART
Treine equipes e 
lance o ART
Oriente a 
execução do ART
Lance mais ARTs 
e fluxos de valor
Estenda o 
portfólio
Sustentar e 
melhorar
3.2 Mapa de implementação do SAFe®
O mapa de implementação é um roteiro que descreve uma visão
geral de um conjunto de passos ordenados que provaram ser
eficazes em uma implementação SAFe®.
3.2 Mapa de implementação do SAFe®
Muitas das maiores
empresas ao redor do
mundo já seguiram esse
caminho e obtiveram
resultados bem-
sucedidos e
significativos.
Segundo o SAFe®, são
esses os resultados:
Fonte: https://v46.scaledagileframework.com/safe-for-lean-enterprises/
• 25-75% de 
redução de 
defeitos 
• 20-50% de 
aumento de 
produtividade
• 30-75% mais 
rápido
• 10-50% de 
colaboradores 
mais motivados 
e felizes
Engajamento
Tempo de 
comercialização
QualidadeProdutividade
https://v46.scaledagileframework.com/safe-for-lean-enterprises/
3.3 Princípios do SAFe®
Baseado em nove princípios e conceitos que inspiram e informam os
papéis e práticas do SAFe®:
Fonte: https://v46.scaledagileframework.com/safe-lean-agile-principles/
# 1 - Tenha uma visão econômica.
# 2 - Aplique o pensamento sistêmico.
# 3 - Assuma variabilidade; preserve opções.
# 4 - Crie incrementos com ciclos de aprendizado rápidos e integrados.
# 5 - Basear marcos objetivos na avaliação de sistemas de trabalho.
# 6 - Visualize e limite o WIP, reduza os tamanhos de lotes e gerencie o comprimento da fila.
# 7 - Aplique cadência e sincronize com o planejamento entre domínios.
# 8 - Desbloqueie a motivação intrínseca dos profissionais de conhecimento.
# 9 - Descentralize a tomada de decisão.
https://v46.scaledagileframework.com/safe-lean-agile-principles/
3.3 Princípios do SAFe®
# 1 - Tenha uma visão econômica.
Requisitos Design Implementação Testes Entrega
C
as
ca
ta
En
tr
eg
as
 
in
cr
em
e
n
ta
is
3.3 Princípios do SAFe®
# 2 - Aplique o pensamento sistêmico.
3 - Otimizar o fluxo 
completo de valores.
1 - A solução em si é 
um sistema.
2 - A empresa que 
constrói um sistema 
também é um sistema.
3.3 Princípios do SAFe®
# 3 - Assuma variabilidade; preserve opções.
3.3 Princípios do SAFe®
# 4 - Crie incrementos com ciclos de aprendizado rápidos e integrados.
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
Ciclo constante de aprendizadoAprendizado em cada pequeno ciclo
Aprendizado tradicional
Aprendizado somente ao 
final do projeto
3.3 Princípios do SAFe®
# 5 - Basear marcos objetivos na avaliação de sistemas de trabalho. 
Fonte da imagem: do próprio autor
Demonstração
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
P
D
C
A
Demonstração Demonstração Demonstração
marco 1 marco 2 marco 3 marco n
3.3 Princípios do SAFe®
# 6 - Visualize e limite o WIP, reduza os tamanhos de lotes e gerencie o 
comprimento da fila.
Backlog do 
time Analise Fazendo
Teste Aceito
Em progresso Pronto Em progresso Em progressoPronto Pronto
2 6 2 8 2 6
Fonte da imagem: do próprio autor
3.3 Princípios do SAFe®
# 7 - Aplique cadência e sincronize com o planejamento entre
domínios
Fonte da imagem: do próprio autor
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Iteração
Time 1
Time 2
Time 3
3.3 Princípios do SAFe®
# 8 - Desbloqueie a motivação intrínseca dos profissionais de 
conhecimento
• Fornecer autonomia com finalidade, 
missão e restrições mínimas possíveis.
• Pagar pouco não motiva, mas depois de 
um ponto o dinheiro não é mais 
motivador.
• Liberdade intelectual e autorrealização.
• Comunicação através dos limites 
funcionais.
3.3 Princípios do SAFe®
# 9 - Descentralize a tomada de decisão
• Centralize decisões estratégicas
pouco frequentes, duradouras e que 
proporcionam economias significativas 
em escala.
• Descentralize todo o resto: decisões 
frequentes, críticas em tempo e que 
exigem informações locais.
Capítulo 4 – Estrutura do SAFe® Essencial
4.1 O nível de time do SAFe®
4.2 O nível de programa do SAFe®
4.3 Paleta de abrangência do SAFe®
4.1 O nível de time do SAFe®
O nível de equipe contém as
funções, atividades, eventos e
processos que as equipes ágeis
criam e entregam valor no
contexto do trem de liberação
ágil.
É parte vital do nível do
programa, e todas as equipes
fazem parte de um ART.
4.1 O nível de time do SAFe®
Detalhes das equipes ágeis que criam e agregam valor:
4.1 O nível de time do SAFe®: destaques
• Iterações – comprimento fixo do tempo de desenvolvimento.
• Incrementos de programa – cadência comum entre todas as equipes
(datas compartilhadas de início e fim).
• Desenvolvimento na cadência – usa o tempo do PI para combinar
funcionalidades maiores e abrangentes ao programa.
• ScrumXP – processo leve para equipes multifuncionais (5-9 pessoas).
• Time kanban – método lean de fluxo de trabalho de equipes.
• Qualidade integrada – garantia que incrementos sejam de alta qualidade
e adaptáveis a mudanças.
Fonte: https://v46.scaledagileframework.com/team-level/
https://v46.scaledagileframework.com/team-level/
4.1 O nível de time do SAFe®: funções
• Equipe agile – time multifuncional com autoridade para definir,
criar e testar um elemento em uma iteração.
• Equipe de desenvolvimento – equipe multifuncional de
especialistas que trabalham colaborativamente.
• Dono do produto – responsável do backlog, define histórias e
prioriza a lista de pendências.
• Scrum master – líder servidor e treinador da equipe em agilidade,
ajudando também a remover impedimentos, facilitar os eventos e
promover ambiente para equipes ágeis.
Fonte: https://v46.scaledagileframework.com/team-level/
https://v46.scaledagileframework.com/team-level/
4.1 O nível de time do SAFe®: eventos
• Planejamento da iteração – determina metas e itens do backlog que podem se
comprometer na próxima iteração.
• Execução da iteração – desenvolve o incremento testável, eficaz e de
qualidade. Realiza a reunião diária de 15 minutos para sincronismo do
progresso e identificação de problemas.
• Revisão da iteração – evento de inspeção do incremento.
• Retrospectiva da iteração – evento final da iteração para revisar práticas e
identificar pontos de melhoria.
• Refinamento da lista de pendências – uma ou duas vezes durante a iteração.
• Iteração da inovação e planejamento (IP) – tempo dedicado ao planejamento
e aprendizado, sendo uma oportunidade de exploração e inovação.
Fonte: https://v46.scaledagileframework.com/team-level/
https://v46.scaledagileframework.com/team-level/
4.1 O nível de time do SAFe®: artefatos
• História – são requisitos do cliente que agregarão valor dentro de uma
iteração.
• Histórias do facilitador – critérios de aceitação que esclarecem os
requisitos para suportar os testes.
• Objetivos da iteração – saída do evento planejamento da iteração que
resume seus objetivos comerciais e técnicos.
• Backlog da equipe – histórias de usuários e facilitadores identificadas
durante a reunião de planejamento.
• Objetivos de PI da equipe – objetivos técnicos e comerciais do
incremento do programa que a equipe pretende atingir.
Fonte: https://v46.scaledagileframework.com/team-level/
https://v46.scaledagileframework.com/team-level/
4.2 O nível de programa do SAFe®
O nível de equipe contém as
funções e atividades para
fornecer continuamente
soluções, por meio de um trem
ágil de liberação, que são
responsáveis por criar valor na
frequência necessária à
empresa e atender à demanda
de mercado do cliente.
4.2 O nível de programa do SAFe®
Seguem os detalhes do nível de programa, onde os ARTs entregam um ou
mais sistemas ou, em alguns casos, toda a solução:
4.2 O nível de programa do SAFe®: destaques
• Equipes ágeis – ARTs compostos por 5 a 12 equipes (entre 50 a 125
pessoas) com capacidade de fornecer entregas funcionais e testáveis.
• Incremento de programa – tempo fixo (8 à 12 semanas) em que o ART
fornece valor incremental. Comumente são quatro iterações de
desenvolvimento + uma iteração de planejamento e inovação (PI).
• Duto de entrega contínua (pipeline) – fluxo de valor constante ao
usuário (exploração, integração, implantação e liberação).
• Desenvolvimento e operação (DevOps) – mentalidade, cultura e práticas
de cooperação entre planejar, desenvolver, testar, implantar, liberar e
manter um sistema.
Fonte: https://v46.scaledagileframework.com/program-level/
https://v46.scaledagileframework.com/program-level/
4.2 O nível de programa do SAFe®: funções
• Gerente de produtos – trabalha com o cliente e os donos do produto
(POs) e é responsável pelo backlog do programa.
• Arquiteto/engenheiro de sistema – pessoa ou equipe que aplica o
pensamento sistêmico, definindo a arquitetura geral e ajudando a
definir requisitos não funcionais (NFRs).
• Engenheiro do trem de liberação (RTE) – líder servidor e scrum master
do ART, facilitando o fluxo com workshops do programa, I&A e
planejamento do incremento do programa.
• Dono do negócio – parte interessada com responsabilidade comercial e
técnica e ROI de uma solução. Participa ativamente dos eventos do ART.
Fonte: https://v46.scaledagileframework.com/program-level/
https://v46.scaledagileframework.com/program-level/
4.2 O nível de programa do SAFe®: eventos
• Planejamento do PI – planejamento presencial que mantém a
cadência do ART e alinha todas as equipes à missão.
• Demonstração do sistema – visão integrada dos recursos da última
iteração apresentada por todas as equipes no ART.
• Inspecionar e adaptar – evento que busca identificar melhorias e
solução de problemas da última iteração.
Fonte: https://v46.scaledagileframework.com/program-level/
https://v46.scaledagileframework.com/program-level/
4.2 O nível de programa do SAFe®: artefatos
• Recursos – sistemas ou serviços que atendem à necessidade das partes
interessadas, possuindo benefícios, hipóteses e critérios de aceitação.
• Épicos do programa – são grandes histórias de usuário e sem detalhes
suficientes para serem desenvolvidos individualmente para um único ART.
• Backlog do programa – área de espera priorizadapara os próximos PIs.
• Kanban do programa – gerencia o fluxo através do duto de entrega contínua.
• Objetivos do PI – descrição resumida dos objetivos comerciais e técnicos que
um ART pretende alcançar no próximo PI.
• Pista arquitetônica – códigos, componentes e infraestrutura para dar suporte à
implementação.
Fonte: https://v46.scaledagileframework.com/program-level/
https://v46.scaledagileframework.com/program-level/
4.3 Paleta de abrangência do SAFe®
Resumo
• São funções e artefatos utilizáveis em equipes,
programas ou outros contextos de portfólios dentro
do SAFe®.
• A empresa pode utilizar somente os elementos que
achar necessários, não sendo obrigatória sua
utilização.
Descrição dos elementos
• Métricas – utilizadas para medir o progresso dos
trabalhos de curto e longo prazos de equipes, trens e
portfólios.
• Serviços compartilhados – funções especiais para o
sucesso de um ART, mas não dedicadas a um trem
específico.
• Comunidade de prática – grupo informal de
membros e especialistas que têm conhecimento em
um domínio relevante à solução.
4.3 Paleta de abrangência do SAFe®
Descrição dos elementos
• Marcos – representação das metas, incrementos ou
eventos planejados.
• Roteiro – informações sobre os marcos planejados
sobre a linha do tempo.
• Visão – o que se espera no futuro da solução a ser
desenvolvida (recursos, capacidades, atendimento às
necessidades).
4.3 Paleta de abrangência do SAFe®
Descrição dos elementos
• Equipe de sistema – time responsável pela
assistência à criação e ao uso do ambiente de
desenvolvimento, integração contínua e testes
automatizados.
• Experiência do usuário enxuta – aplicação dos
princípios lean UX com ciclos constantes de
aprendizado (construir-medir-aprender) aplicado em
escala.
4.3 Paleta de abrangência do SAFe®
Capítulo 5 – Estruturas maiores do SAFe®
5.1 O nível de solução ampla do SAFe®
5.2 O nível de portfólio do SAFe®
5.3 O nível completo do SAFe®
5.1 O nível de solução ampla do SAFe®
Esse nível contém as funções,
artefatos e processos para criar
soluções grandes e complexas.
O foco na solução ampla é a
intenção da solução e
coordenação de múltiplos trens
de liberação e fornecedores.
5.1 O nível de solução ampla do SAFe®
Detalhes das equipes ágeis que criam e agregam valor:
5.1 O nível de solução ampla do SAFe®: destaques
• Solução – produtos, serviços ou sistemas criados por fluxos de valor.
• Trem de solução – alinha o trabalho em torno da visão, missão e backlog
da solução.
• Estrutura econômica – tomada de decisão baseada nos limites
financeiros.
• Intenção da solução – suporte para verificação, validação e
conformidade da solução.
• Contexto da solução – descrição da implantação do sistema no
ambiente operacional.
• Kanban da solução – gerenciamento dos recursos e facilitadores da
solução.
Fonte: https://v46.scaledagileframework.com/large-solution-level/
https://v46.scaledagileframework.com/large-solution-level/
5.1 O nível de solução ampla do SAFe®: funções
• Arquiteto/engenheiro de solução – responsável pela visão técnica e
de arquitetura da solução.
• Gerente de soluções – voz do cliente, criando visão de suas
necessidades e definindo os recursos e capacitadores através do
kanban da solução.
• Engenheiro do trem da solução – líder e treinador/facilitador de
todos os ARTs e fornecedores.
• Fornecedor – interno ou externo.
Fonte: https://v46.scaledagileframework.com/large-solution-level/
https://v46.scaledagileframework.com/large-solution-level/
5.1 O nível de solução ampla do SAFe®: eventos
• Planejamento pré e pós-PI – usados para preparar e acompanhar o
PI para ARTs e fornecedores.
• Demonstração da solução – resultados de desenvolvimento de
todos os trens e fornecedores.
• Inspecionar e adaptar (I&A) – evento para demonstração, avaliação
e identificação de pontos de melhoria da solução.
Fonte: https://v46.scaledagileframework.com/large-solution-level/
https://v46.scaledagileframework.com/large-solution-level/
5.1 O nível de solução ampla do SAFe®: artefatos
• Recursos – sistemas ou serviços que atendem à necessidade de vários
ARTs que serão implantados em um único PI.
• Épicos do solução – grandes histórias de usuário e sem detalhes
suficientes para o trem da solução.
• Requisitos não funcionais – atributos como desempenho, segurança,
capacidade e escalabilidade incorporados na intenção da solução.
• Backlog da solução – área de espera priorizada de vários ARTs para os
próximos PIs.
• Kanban da solução – método de visualização e gerenciamento de todo o
fluxo da solução (concepção, análise, implementação e liberação).
Fonte: https://v46.scaledagileframework.com/large-solution-level/
https://v46.scaledagileframework.com/large-solution-level/
5.2 O nível de portfólio do SAFe®
Esse nível tem o objetivo de
alinhar a estratégia corporativa
à execução do portfólio por
meio de um ou mais fluxos de
valor.
Estabelece os limites de
orçamento enxuto. Podem
haver vários portfólios SAFe®
para várias linhas do negócio.
5.2 O nível de portfólio do SAFe®
Detalhes dos processos e pessoas para atingir os objetivos estratégicos:
5.2 O nível de portfólio do SAFe®: destaques
• Orçamentos enxutos – tomada de decisão rápida, com controle
financeiro e prestação de contas fornecido pelos guardrails.
• Fluxos de valor – financiamento de recursos e pessoas para criar
soluções.
• Kanban do portfólio – torna o trabalho visível e cria limites às
capacidades dos ARTs.
• Canvas do portfólio – criado para descrever a finalidade de um
portfólio.
5.2 O nível de portfólio do SAFe®: funções
• Gerente de portfólio enxuto (LPM) – indivíduos com o mais alto
nível de responsabilidade e tomada de decisão (estratégica,
financeira e de investimento).
• Proprietários dos épicos – coordenam as grandes histórias através
do kanban do portfólio.
• Arquiteto corporativo – fornece direção técnica estratégica para
otimizar resultados.
5.2 O nível de portfólio do SAFe®: artefatos
• Épicos do negócio – refletem os recursos que serão fornecidos
através da combinação entre fluxos de valor.
• Épicos do capacitador – refletem a arquitetura e as tecnologias que
serão fornecidas para habilitar recursos e capacidades.
• Temas estratégicos – conexão entre o portfólio e a estratégia de
negócios da empresa.
• Backlog do portfólio – backlog de mais alto nível do SAFe®,
fornecendo competitividade e eficiência operacional para o
sucesso do negócio.
5.3 O nível completo do SAFe®
A configuração mais abrangente
do SAFe®.
Permite a criação de soluções
abrangentes e integradas
(solução ampla e portfólio) que
exigem centenas de pessoas ou
mais para serem mantidas e
desenvolvidas.
5.3 O nível completo do SAFe®
Capítulo 6 – Introdução ao LeSS®
6.1 Introdução ao LeSS®
6.2 Papéis do LeSS®
6.3 Eventos do LeSS®
6.4 Regras do LeSS®
6.5 Princípios do LeSS®
6.1 Introdução ao LeSS®
Onde tudo começou...
Em 2005, Bas e Craig
trabalhavam juntos na Nokia
Siemens Networks. Começaram
a combinar experiências e
criaram o LeSS® Framework.
Desde então o LeSS® vem sendo
aplicado em desenvolvimento
de produtos a partir de 2
equipes e até 2.500 pessoas. Bas Vodde
Craig Larman
6.1 Introdução ao LeSS®: Bas Vodde e Craig Larman
Alguns do livros mais conhecidos e que formam a base do LeSS®: Large-Scale
Scrum: More with LeSS (2016); Practices for Scaling Lean & Agile
Development (2010); Scaling Lean & Agile Development (2008).
.
6.1 Introdução ao LeSS®
Base da equipe de
desenvolvimento do scrum
O LeSS® Framework utiliza os
processos empíricos do scrum
como estrutura de
desenvolvimento de produtos.
No Scrum Guide, a ênfase para o
desenvolvimento do trabalho é
focada apenas com uma equipe de
3 a 11 pessoas.
É aí que nasce o LeSS® em larga
escala.
6.1 Introdução ao LeSS®
LeSS® – Large-Scale Scrum
LeSS® é o scrum aplicado a
muitas equipes trabalhando
juntas em um único produto.
Ou seja, aplica os princípios e o
propósito do scrum em um
contexto de grande escala, da
maneira mais simples possível.
Morewith LeSS
6.1 Introdução ao LeSS®
Experiências, guias, regras e princípios
Os criadores enfatizam que práticas são
situacionais, e não necessariamente
“melhores” em todos os contextos.
O LeSS®, após experimentos e feedback
constante, voltou-se para o modelo Shu-
Ha-Ri (termo de artes marciais):
Shu – Siga as regras.
Ha – Quebre as regras e descubra o
contexto.
Ri – Domine e encontre o seu próprio
caminho.
6.1 Introdução ao LeSS®
Iniciando o LeSS® no nível Shu
• Regras – Formam a base e definem
principais elementos da estrutura
que dão suporte ao controle
empírico e foco ao produto.
• Guias – Conjunto moderado de
elementos para adotar as regras e
um subconjunto de experimentos.
• Experimentos – Muitos
experimentos situacionais.
• Princípios – Conjunto de
experiências extraídas com a
adoção do LeSS®.
6.1 Introdução ao LeSS®
Framework LeSS® (até 8 equipes de 2 a 8 pessoas cada)
6.2 Papéis do LeSS®
Os mesmos papéis do scrum
existem no LeSS®.
• Product owner
• Scrum master
• Time de desenvolvimento
6.2 Papéis do LeSS®
Dono do produto (product owner)
• Conceitualmente, o mesmo do
scrum.
• Foco em uma visão geral e garantir
o ROI.
• É o único dono do produto de
todas as equipes.
• Prioriza e esclarece os itens do
backlog do produto.
• Incentiva as equipes a entrar em
contato com usuários e clientes.
6.2 Papéis do LeSS®
Scrum master
• Ajuda pessoas a enxergarem o
sistema de forma ampla.
• Mantém todos com foco no
produto.
• Guardião da transparência.
• Função dedicada, tempo integral.
• Responsável pela estrutura.
• Foco na equipe, dono do produto,
organização e práticas de
desenvolvimento.
6.2 Papéis do LeSS®
Time de desenvolvimento
Um time de desenvolvimento do LeSS® é
igual ao do scrum.
• Adiciona itens do backlog durante a
sprint.
• Trabalha em estreita colaboração com
o cliente/usuário.
• Coordena e integra o próprio
trabalho.
• Produz um incremento do produto.
• É multifuncional e autogerenciado.
• Compartilha responsabilidades.
• Compartilha metas.
6.2 Papéis do LeSS®
Além dos papéis, precisamos entender os tipos de relacionamentos no
LeSS®.
Dono do produto <-> Equipes
Dono do produto <-> Clientes
Equipes <-> Clientes
Dono do produto <-> Gestão
Dono do produto <-> Scrum masters
Scrum master <-> Equipes
6.3 Eventos do LeSS®
O LeSS® é uma versão ampliada de
uma equipe scrum.
• Um único backlog do produto
• Uma definição de pronto
• Um incremento potencialmente
utilizável ao final de cada sprint
• Equipes multifuncionais
• Uma sprint
6.3 Eventos do LeSS® - Diferenças
Planejamento da sprint - Parte 1
• Inclui PO e membros de todas as
equipes.
• Permite que membros se
autogerenciem e decidam a
divisão dos itens do backlog do
produto.
• Discutem oportunidades de
trabalho compartilhado e
cooperação em itens
relacionados.
6.3 Eventos do LeSS® - Diferenças
Planejamento da sprint - Parte 2
• Cada equipe realiza a sua (em
paralelo).
• Caso tenha relacionamentos
entre os itens do backlog, as
equipes podem realizar o
planejamento juntas na mesma
sala, mas em áreas diferentes.
6.3 Eventos do LeSS® - Diferenças
Reunião diária (daily scrum)
• Cada equipe realiza a sua de
forma independente.
• Membros de outras equipes
podem observar as reuniões
para aumentar o
compartilhamento de
informações.
• As questões são as mesmas de
uma reunião diária do scrum.
6.3 Eventos do LeSS® - Diferenças
PBR geral (refinamento do backlog
do produto geral)
• Reunião opcional e curta que
inclui o dono do produto e
pessoas de todas as equipes.
• Seu objetivo é decidir quais
equipes implementarão certos
itens e selecioná-los mais tarde
em uma reunião PBR de uma ou
mais equipes, caso hajam itens
relacionados.
6.3 Eventos do LeSS® - Diferenças
Refinamento do backlog do produto
• Reunião de equipe onde serão
refinados os itens selecionados
na PBR geral, agora em maior
detalhamento, para aumentar o
aprendizado e a coordenação da
equipe.
• Pode ser realizado o PBR com
outras equipes na mesma sala,
desde que existam itens
relacionados.
6.3 Eventos do LeSS® - Diferenças
Revisão da sprint
• Inclui o dono do produto,
pessoas de todas as equipes,
clientes, usuários e outras partes
interessadas.
• Realizado no estilo “bazar” ou
“feira de ciências”, em uma sala
grande com diversas áreas.
• Cada área é composta por
membros da equipe, onde os
itens desenvolvidos são
mostrados e discutidos.
6.3 Eventos do LeSS® - Diferenças
Retrospectiva geral
• Reunião exclusiva do LeSS®,
onde o objetivo é explorar a
melhoria do sistema como um
todo, em vez de se concentrar
em uma única equipe.
• A duração máxima é de 45
minutos por semana de sprint.
• Inclui o PO, SM e representantes
rotativos de cada equipe.
6.4 Regras do LeSS® - Equipes de 2 a 8 pessoas
Framework LeSS®
• “Estruture a organização usando equipes reais como blocos de construção organizacionais básicos.
• Cada equipe é (1) autogerenciada, (2) multifuncional, (3) colocalizada e (4) de longa duração.
• A maioria das equipes são equipes de recursos focadas no cliente.
• Os scrum masters são responsáveis por uma boa adoção do LeSS®. Seu foco é direcionado às equipes, 
dono do produto, organização e práticas de desenvolvimento. Um scrum master não se concentra em 
apenas uma equipe, mas no sistema organizacional geral.
• Scrum master é um papel com dedicação em tempo integral.
• Um scrum master pode servir a 1-3 equipes.
• No LeSS®, os gerentes são opcionais, mas, se existirem, é provável que a função deles mude. Seu foco 
muda do gerenciamento do trabalho diário do produto para o melhoramento do sistema de 
desenvolvimento de produtos em sua capacidade de entrega de valor.
• O papel dos gerentes é melhorar o sistema de desenvolvimento de produtos, praticando o Go See, 
incentivando o Stop & Fix e ‘experimento acima da conformidade’.
• Para o grupo de produtos, estabeleça a estrutura completa do LeSS® ‘no início’; isso é vital para a 
adoção do LeSS®.
• Para uma organização maior, além do grupo de produtos, adote o LeSS® evolutivamente usando o Go 
and See para criar uma organização onde a experimentação e a melhoria sejam a norma.”
Fonte : https://less.works/less/rules/index.html#LeSSFrameworkRules (tradução nossa).
https://less.works/less/rules/index.html#LeSSFrameworkRules
6.4 Regras do LeSS® - Equipes de 2 a 8 pessoas
Produto LeSS®
• “Há um dono do produto e um backlog do produto para o produto completo para 
entrega.
• O dono do produto não deve trabalhar sozinho no refinamento do backlog do 
produto; ele é apoiado por múltiplas equipes que trabalham diretamente com 
clientes/usuários e outras partes interessadas.
• Toda priorização passa pelo dono do produto, mas o esclarecimento ocorre o máximo 
possível diretamente entre as equipes e os clientes/usuários e outras partes 
interessadas.
• A definição de produto deve ser tão ampla e centrada no usuário final/cliente quanto 
possível. Com o tempo, a definição de produto pode se expandir. Definições mais 
amplas são preferidas.
• Uma definição de concluído para todo o produto comum a todas as equipes.
• Cada equipe pode ter sua própria definição de pronto expandindo a definição 
comum. 
• O objetivo da perfeição é melhorar a definição de concluído para que ela resulte em 
um produto expedível a cada sprint (ou ainda mais frequentemente).”
Fonte : https://less.works/less/rules/index.html#LeSSFrameworkRules (tradução nossa).
https://less.works/less/rules/index.html#LeSSFrameworkRules
6.4 Regras do LeSS® - Equipes de 2 a 8 pessoas
Sprint LeSS®
• “Há uma sprint no nível do produto, não uma sprint diferente para cada equipe. Cada 
equipe inicia e termina a sprint ao mesmo tempo. Cada sprint resulta em um produto 
inteiro integrado.
• O planejamento da sprint consiste em duas partes: o planejamento da sprint 1 é 
comum a todas as equipes, enquanto o planejamento da sprint 2 geralmente é feito 
separadamente para cada equipe. Faça planejamento da sprint 2 com várias equipes 
em um espaço compartilhado paraitens intimamente relacionados.
• O planejamento da sprint 1 é acompanhado pelo dono do produto e representantes 
da equipe ou equipes. Eles juntos, provisoriamente, selecionam os itens que cada 
equipe trabalhará na sprint. As equipes identificam oportunidades para trabalhar em 
conjunto e as questões finais são esclarecidas.
• Cada equipe tem sua própria sprint backlog.
• O planejamento da sprint 2 é para as equipes decidirem como farão os itens 
selecionados. Isso geralmente envolve o design e a criação de seus backlogs da sprint.
• Cada equipe tem seu próprio daily scrum.”
Fonte : https://less.works/less/rules/index.html#LeSSFrameworkRules (tradução nossa).
https://less.works/less/rules/index.html#LeSSFrameworkRules
6.4 Regras do LeSS® - Equipes de 2 a 8 pessoas
Sprint LeSS®
• “A coordenação entre equipes é decidida pelas equipes. Prefira a coordenação 
descentralizada e informal à coordenação centralizada. Enfatize o just talk (apenas 
fale) e redes informais via comunicação em código, reuniões entre equipes, 
mentores, observadores e espaços seguros.
• O refinamento do backlog do produto (PBR) é preferencialmente feito com várias 
equipes, para aumentar o aprendizado compartilhado e explorar as oportunidades de 
coordenação.
• Existe uma revisão do produto da sprint, comum a todas as equipes. Garanta que as 
partes interessadas adequadas se juntem para contribuir com as informações 
necessárias a uma inspeção e adaptação eficazes.
• Cada equipe tem sua própria retrospectiva da sprint.
• Uma retrospectiva geral é realizada após as retrospectivas da equipe para discutir 
questões entre equipes e em todo o sistema e criar experimentos de melhoria. Aqui 
participam o dono do produto, scrum masters, representantes da equipe e gerentes 
(se houver).”
Fonte : https://less.works/less/rules/index.html#LeSSFrameworkRules (tradução nossa).
https://less.works/less/rules/index.html#LeSSFrameworkRules
6.5 Princípios do LeSS®
Os 10 princípios do LeSS®
6.5 Princípios do LeSS®
1. Scrum em larga escala é scrum
Não é um scrum novo e
aprimorado. Em vez disso, o LeSS®
trata de descobrir como aplicar os
princípios, regras, elementos e
objetivo do scrum em um contexto
de grande escala, da maneira mais
simples possível.
Fonte: https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
2. Transparência
Enfatiza itens tangíveis
“concluídos”, ciclos curtos,
trabalho em conjunto, definições
comuns e na expulsão do medo no
local de trabalho.
Fonte: https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
3. Mais com menos
Não queremos mais papéis,
artefatos ou processos. Em vez
disso, queremos equipes mais
responsáveis por terem menos
(menos) funções; que equipes
mais focadas no cliente criem
produtos úteis com menos
artefatos; mais propriedade do
processo pela equipe e um
trabalho mais significativo por
haver processos menos definidos.
Fonte: https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
4. Foco em todo o produto
Um backlog do produto, um dono
do produto, um produto que pode
ser entregue, uma sprint –
independentemente de termos 3
ou 33 equipes. Os clientes
desejam funcionalidade relevante
em um produto coeso, e não
componentes técnicos em peças
separadas.
Fonte: https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
5. Centrar-se no cliente
Concentre-se em aprender sobre os
problemas reais dos clientes e em
resolvê-los. Identifique o que é valor
e o que é desperdício aos olhos dos
clientes pagantes. Reduza o tempo
de espera da perspectiva
deles. Aumente e fortaleça loops de
feedback com clientes reais. Todos
devem compreender como seu
trabalho hoje está diretamente
relacionado aos clientes pagantes e
como eles são beneficiados.
Fonte : https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
6. Melhoria contínua em direção à
perfeição
Aqui está um objetivo de
perfeição: criar e entregar um
produto quase o tempo todo,
quase sem custo, sem defeitos,
que encanta os clientes, melhora o
ambiente e melhora a vida. Faça
inúmeras experiências humildes e
radicais de melhoria em direção a
esse objetivo.
Fonte : https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
7. Pensamento enxuto
Crie um sistema organizacional em
os gerentes sejam a base, como
professores que aplicam e
ensinam o pensamento enxuto,
conseguindo melhorar, promover
interrupções e reparos e praticar o
Go See. Adicione os dois pilares do
respeito pelas pessoas e a
mentalidade de melhoria contínua
do desafio do status quo, tudo em
direção ao objetivo da perfeição.
Fonte : https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
8. Pensamento sistêmico
Veja, entenda e otimize todo o
sistema – não partes – e use a
modelagem de sistemas para
explorar a dinâmica do sistema.
Evite as subotimizações locais,
concentrando-se na eficiência ou
produtividade de indivíduos e
equipes individuais. Os clientes se
preocupam com o tempo e o fluxo
gerais do ciclo, e não com as etapas
individuais, e a otimização local de
uma peça quase sempre subotimiza
o todo.
Fonte : https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
9. Controle empírico do processo
Inspecione e adapte continuamente
o produto, processos,
comportamentos, design
organizacional e práticas para evoluir
de maneiras apropriadas à
situação. Faça isso, em vez de seguir
um conjunto prescrito das chamadas
melhores práticas que ignoram o
contexto, criam seguidores
ritualísticos, impedem o aprendizado
e as mudanças e esmagam o senso
de envolvimento e propriedade das
pessoas.
Fonte : https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
6.5 Princípios do LeSS®
9. Teoria das filas
Entenda como os sistemas com
filas se comportam no domínio de
pesquisa e desenvolvimento e
aplique essas ideias ao
gerenciamento de tamanhos de
filas, limites de trabalho em
andamento, multitarefa, pacotes
de trabalho e variabilidade.
Fonte : https://less.works/less/framework/introduction#One-TeamScrum
https://less.works/less/framework/introduction#One-TeamScrum
Capítulo 7 – Estrutura do framework LeSS®
7.1 Estrutura 
7.2 LeSS Huge®
7.3 Gerenciamento
7.4 Excelência técnica
7.5 Adoção
7.1 Estrutura
Estrutura
Organização 
pelo valor do 
cliente
Equipes de 
funcionalidades
Estrutura 
organizacional
Comunidades
Scrum 
master
Equipes
Como poderia ser uma
estrutura organizacional
adequada ao LeSS®?
A cultura segue a
estrutura, então, enquanto
não houver alterações na
estrutura organizacional,
nenhuma mudança de
comportamentos e de
mentalidade vai ocorrer.
7.1 Estrutura: organização pelo valor do cliente
Como escalar e manter o foco no
cliente?
• Equipes multifuncionais
• Equipes de funcionalidades
• Especialização na dimensão do
cliente
7.1 Estrutura: equipes de funcionalidades
Diferentemente das equipes de
componentes, as equipes de
funcionalidades têm as seguintes
características:
• Longa duração.
• Multifuncionais e
multicomponentes.
• Trabalham em funcionalidades
completas.
• Compostas por especialistas
generalistas.
• Tipicamente têm entre 5 a 9
pessoas.
7.1 Estrutura: estrutura organizacional
Chefe do grupo de produto
Time #1 Time #2 Time #N Dono do produto
Departamento de 
trabalho não feito
*Perceba que não possui nenhuma organização, departamento,PMO, área 
especializada (testes, QA, arquitetura).
7.1 Estrutura: comunidades
Comunidades de prática (CoP)
são grupos de pessoas que
compartilham uma preocupação,
um conjunto de problemas ou
uma paixão por um tópico e que
aprofundam seus
conhecimentos e habilidades
nessa área, interagindo de forma
contínua.
7.1 Estrutura: scrum master
Responsável por ensinar o scrum
para a organização, ajudando e
guiando todos a descobrir como
podem contribuir para a criação de
um produto melhor e mais valioso.
Ele pode lidar com 1 a 3 equipes.
Seus focos são:
• Equipe
• PO
• Organização
• Práticas de desenvolvimento
7.1 Estrutura: equipes
É o elemento básico para
desenvolver grandes produtos.
São atributos das equipes:
• Produto de trabalho
compartilhado
• Trabalho interdependente
• Uma responsabilidade
compartilhada
• Um conjunto de acordos de
trabalho
• Responsabilidade pela gestão
dos relacionamentos externos
• Liderança distribuída
7.2 LeSS Huge®
Framework LeSS Huge® (8 equipes até alguns milhares de pessoas em um
produto)
7.2.1 Papel adicional do LeSS Huge®
Dono do produto da área (APO)
*Somente na estrutura do LeSS Huge®.
• Especializado em uma área
centrada no cliente.
• Perspectiva limitada às equipes da
área.
• Faz parte da equipe de dono do
produto.
• Geralmente é responsável por no
mínimo 4 e no máximo 10 equipes.
• Auxilia em tirar a sobrecarga do
dono do produto.
7.2.2 Regras do LeSS Huge® - Produtos de 8 ou mais times
Framework LeSS Huge®
• “Os requisitos do cliente que estão fortemente relacionados à 
perspectiva do cliente são agrupados em áreas de requisitos.
• Cada equipe é especializada em uma área de requisitos. As equipes 
permanecem em uma área por um longo tempo. Quando houver 
mais valor em outras áreas, as equipes poderão mudar de área de 
requisitos.
• Cada área de requisitos possui um dono do produto da área.
• Cada área de requisitos tem entre 4 e 8 equipes. Evite violar esse 
intervalo.
• Adoções LeSS Huge®, incluindo as mudanças estruturais, são feitas 
com uma abordagem incremental evolutiva.
• Lembre-se todos os dias: adopções LeSS Huge® levam meses ou anos, 
paciência infinita e senso de humor.”
Fonte: https://less.works/less/rules/index.html#LeSSFrameworkRules (tradução nossa). 
https://less.works/less/rules/index.html#LeSSFrameworkRules
7.2.3 Regras do LeSS Huge® - Produtos de 8 ou mais times
Produto LeSS Huge®
• O dono do produto é responsável pela priorização de todo o produto e por 
decidir quais equipes trabalham em qual área. Ele trabalha em estreita 
colaboração com donos do produto da área.
• Os donos do produto da área atuam como donos do produto em relação a 
suas equipes.
• Há um backlog do produto; todos os itens pertencem a exatamente uma 
área de requisitos.
• Há um backlog do produto da área por área de requisitos. Esse backlog é 
conceitualmente uma visão mais granular do único backlog do produto.
Fonte: https://less.works/less/rules/index.html#LeSSFrameworkRules (tradução nossa). 
https://less.works/less/rules/index.html#LeSSFrameworkRules
7.2.4 Regras do LeSS Huge® - Produtos de 8 ou mais times
Sprint LeSS Huge®
• Há uma sprint no nível do produto, não uma sprint diferente 
para cada área de requisitos, resultando em um produto inteiro 
integrado.
• O dono do produto (PO) e os donos do produto da área (APOs) 
sincronizam seus trabalhos com frequência. Antes do 
planejamento da sprint, eles garantem que as equipes trabalhem 
nos itens mais valiosos. Após a revisão da sprint, eles ainda 
permitem adaptações no nível do produto.
Fonte: https://less.works/less/rules/index.html#LeSSFrameworkRules (tradução nossa). 
https://less.works/less/rules/index.html#LeSSFrameworkRules
7.3 Gerenciamento
O LeSS® tem grande impacto no
estilo de gestão das organizações
(comando e controle).
Com a mudança, ocorrem dois
impactos:
• Equipes auto-organizadas e
delegação de responsabilidades.
• Donos de produtos decidem “o
que” deve feito, não “como”.
Auto gerenciamento:
A equipe monitora e 
gerencia o progresso e o 
processo. 
Gerente como Scrum 
Master?
Prós e contras, o melhor é 
o gerente ser scrum master 
de equipes que não 
possuam subordinados.
7.3 Gerenciamento Vá ver:
Entenda o que está 
acontecendo por si 
mesmo, compreendendo a 
situação real.
Ensinando a resolução de 
problemas:
5 porquês
Pensamento sistêmico
Pensamento A3 - PDCA
Serviço de melhoria:
Melhorias através de 
retrospectivas, discussões, 
workshops, todos através de 
itens inseridos no backlog.
Papel do gerente:
Gerentes como construtores de 
capacidade (removendo 
obstáculos e implementado 
melhorias, decisões estratégicas 
da empresa e produtos).
7.3 Gerenciamento
Teoria X 
• As pessoas não gostam de trabalho
e vão tentar evitar o trabalho.
• Por causa disto, as pessoas 
precisarão ser coagidas, 
controladas, direcionadas e 
ameaçadas para que a máxima 
quantidade de esforço possa ser 
extraída delas.
• As pessoas querem ser dirigidas, 
uma vez que possuem pouca 
ambição e evitam assumir a 
responsabilidade.
Fonte: McGregor (2006). 
Teoria Y
• As pessoas se esforçam naturalmente para 
trabalhar, assim como fazem para brincar e 
descansar.
• As pessoas usarão autodireção e 
autocontrole para os objetivos com os quais 
elas se comprometeram. O compromisso 
vem mais fortemente a partir das 
recompensas intrínsecas relacionadas com a 
realização em si. Esse é o desafio, o 
aprendizado e o sentido de propósito.
• Fornecendo o ambiente certo, os seres 
humanos procuram a responsabilidade, ao 
invés de evitá-la.
O LeSS® requer estilos de gerenciamento que estão mais no lado da Teoria Y.
7.4 Excelência técnica
Fonte: https://less.works/pt/less/technical-excellence/index
A agilidade organizacional é restringida pela agilidade técnica
Excelência 
técnica, 
invista 
nessas 
práticas!
Especificação por exemplo (A-TDD)
Integração contínua
Entrega contínua
Teste de aceitação
Código limpo
Teste unitário
Arquitetura e design
Desenvolvimento orientado a teste (TDD)
Pensando sobre testes
Automação de testes
https://less.works/pt/less/technical-excellence/index
7.5 Adoção
Fonte: https://less.works/pt/less/adoption/index
Começando:
• Treine todos.
• Defina o ‘produto’.
• Defina o ‘pronto’.
• Tenha equipes 
adequadamente 
estruturadas.
• Somente o dono do 
produto dá trabalho 
para a equipe.
• Mantenha gerentes de 
projeto afastados das 
equipes.
Três princípios:
• Profundo e estreito sobre amplo e 
raso.
• De cima para baixo e de baixo para 
cima.
• Use o voluntariado.
Mapa de adoção da equipe de recursos:
Potencial escopo de trabalho tecnológico 
dentro da equipe
Vs.
Grau de funcionalidade cruzada dentro 
da equipe
Melhoria Contínua:
• Capacidade de mudança de direção 
com o mínimo de esforço e sem 
custo.
• Fazer experimentos.
• Concentre-se em problemas, não em 
ferramentas.
Treinamento:
Três níveis de treinamento:
• Coaching organizacional
• Coaching de equipe
• Coaching técnico
https://less.works/pt/less/adoption/index
Capítulo 8 – Introdução ao Nexus®
8.1 Introdução ao Nexus®
8.2 Propósito do Nexus®
8.3 Pano de fundo do Nexus®
8.4 Framework Nexus®
8.5 Fluxo do processo do Nexus® 
8.1 Introdução ao Nexus®
Framework lançado em 2015 por
Ken Schwaber, cocriador do Guia
Scrum e também um dos criadores
da Scrum Alliance e Scrum.org,
além de ser um dos signatários do
Manifesto Ágil.
O Guia Nexus é definido como “O
exoesqueleto de desenvolvimento
do Scrum escalado.” (SCHWABER,
2018, p.13).
8.1 Introdução ao Nexus®: Ken Schwaber
Entre suas obras, as mais conhecidas são: Agile Project
Management with Scrum (2004), Software in 30 Days (2012) e
The Enterprise and Scrum (2007).
8.2 Propósito do Nexus®
Usando as bases do scrum, é um
framework para desenvolvimento e
sustentação de produtos e
softwares em escala.
No guia estão definidos papéis,
artefatos e regras do Nexus®.
O Guia Nexus é desenvolvido,
escrito e fornecido pela Scrum.org.
https://www.scrum.org/resources/nexus-guide8.3 O pano de fundo do Nexus®
Surgiu da necessidade de organização
e dependências de dois ou mais times.
1. Requisitos
2. Domínio de conhecimento
3. Software e artefatos de teste
À medida que os times conseguem
mapear as dependências acima, a
produtividade é otimizada.
8.4 O framework Nexus® 
8.5 O fluxo do processo Nexus®
Múltiplos times multifuncionais
trabalhando juntos.
• Refinar o backlog do produto:
Decomposição em pequenas
funcionalidades para identificar
dependências e elencar o time
adequado.
Fonte da imagem: do Autor.
Incremento
Ação
Limitação
Incremento
Incremento
Limitação
Funcionalidade
Funcionalidade
Dependência
Oportunidade
Intenção, ideias 
desejos
Intenção, ideias 
desejos
En
tr
eg
áv
el
R
ef
in
ad
o
Fu
tu
ro
Te
m
p
o
G
ra
n
u
la
ri
d
ad
e 
/ 
R
ef
in
am
e
n
to
8.5 O fluxo do processo Nexus®
• Planejamento da sprint Nexus®
Reunião de revisão do refinamento
e seleção de itens do backlog para
cada time. Posteriormente, cada
time planeja sua própria sprint
interagindo com outros times,
quando necessário, e alinhando
suas metas com a meta global da
sprint Nexus®.
8.5 O fluxo do processo Nexus®
• Trabalho de desenvolvimento
Times integrando frequentemente
seu trabalho em um ambiente
comum que pode ser testado para
assegurar que a integração foi
realizada.
8.5 O fluxo do processo Nexus®
• Reunião diária do Nexus®
Reunião de representantes de cada
time para verificar questões de
integração.
Se identificadas as questões, elas
são levadas à reunião diária do
time.
8.5 O fluxo do processo Nexus®
• Revisão da sprint do Nexus®
Realizada ao final da sprint para
promover comentários e opiniões
sobre o incremento integrado.
Todos times scrum se encontram
com as partes interessadas e
revisam o incremento que pode ser
ajustado no backlog do produto.
8.5 O fluxo do processo Nexus®
• Retrospectiva da sprint do
Nexus®
Representantes de cada time scrum
se encontram para identificar os
desafios e depois realizar a reunião
de retrospectiva scrum com seus
times individualmente.
Após a segunda rodada de
reuniões, os representantes se
encontram novamente para
compartilhar as ações que serão
realizadas.
Capítulo 9 – Estrutura do Nexus®
9.1 Papéis do Nexus®
9.2 Eventos do Nexus®
9.3 Artefatos do Nexus®
9.4 Transparência do artefato 
9.1 Papéis do Nexus®
• Consiste em um time de integração do Nexus® e aproximadamente 
3 a 9 times scrum
• Time de integração do Nexus®
Responsável por garantir que um
complemento integrado seja
produzido a cada sprint.
Os times scrum são responsáveis
por entregar os incrementos
“prontos” potencialmente
utilizáveis.
9.1 Papéis do Nexus®
• Time de integração do Nexus®
- O time de integração pode mudar
ao longo do tempo e seu trabalho
inclui mentoria, consultoria,
resolução de problemas e
dependências técnicas/não
técnicas, além de ser responsável
pelo backlog do produto.
- Membros de um time scrum
priorizam o trabalho no time de
integração.
9.1 Papéis do Nexus®
Product owner
Membro(s) da 
equipe
Scrum master
• O product owner no time de integração
Nexus®
No Nexus® existe apenas um backlog do
produto e, consecutivamente, apenas um dono
do produto que possui decisão final sobre o
backlog e é responsável por maximizar o valor
do produto.
9.1 Papéis do Nexus®
Product owner
• O scrum master no time de integração
Nexus®
Possui a responsabilidade geral de garantir que
o framework seja entendido e adotado por
todas as equipes.
Ele também pode exercer o papel de scrum
master em outros times scrum dentro daquele
Nexus®.
9.1 Papéis do Nexus®
Scrum master
• Os membros do time de integração Nexus®
Profissionais capacitados em ferramentas e
práticas da área de atuação de engenharia de
sistemas que realizam treinamentos e
garantem que os times scrum utilizem práticas
e ferramentas necessárias para integrar todos
os artefatos e a definição de “pronto” com a
qualidade adequada.
9.1 Papéis do Nexus®
Membro(s) da 
equipe
A duração dos eventos
do Nexus® é guiada pelos
tamanhos dos seus
eventos do guia scrum
(timeboxes).
9.2 Eventos do Nexus®
Sprint 1 mês ou menos
Planejamento da 
sprint
8 h – Sprint 30 dias
4 h – Sprint 15 dias
2 h – Sprint 7 dias
Reunião diária 15 min/dia
Revisão da sprint
4 h – Sprint 30 dias
2 h – Sprint 15 dias
1 h – Sprint 7 dias
Retrospectiva da 
sprint
3 h – Sprint 30 dias
1,5 h – Sprint 15 dias
45 min – Sprint 7 dias
Refinamento do 
backlog do produto
Usualmente menos de 10% da 
sprint
Refinar o backlog do produto:
• Elencar dependências e distribuir
os itens entre times.
• O refinamento continua até todos
os itens serem suficientemente
decompostos.
• Número, frequência, duração e
participantes do refinamento são
baseados em dependências e
incertezas herdadas do backlog.
• Usualmente não consome mais de
10% da capacidade do time.
Incremento
Ação
Limitação
Incremento
Incremento
Limitação
Funcionalidade
Funcionalidade
Dependência
Oportunidade
Intenção, ideias 
desejos
Intenção, ideias 
desejos
En
tr
eg
áv
el
R
ef
in
ad
o
Fu
tu
ro
Te
m
p
o
G
ra
n
u
la
ri
d
ad
e 
/ 
R
ef
in
am
e
n
to
9.2 Eventos do Nexus®
Planejamento da sprint Nexus®
• Planejamento das atividades de
todos os times no Nexus® para
uma única sprint.
• PO discute a meta (propósito) da
sprint do Nexus®.
• Novas dependências podem
surgir e devem ser transparentes
e minimizadas.
9.2 Eventos do Nexus®
A meta da sprint do Nexus®
• É o objetivo definido para aquela
sprint (soma de todo trabalho e
metas das sprints dos times
scrum).
• As funcionalidades “prontas”
que alcançarem a meta da sprint
do Nexus® receberão
comentários e observações do
stakeholder.
9.2 Eventos do Nexus®
Reunião diária do Nexus®
Tem como foco inspecionar a situação
atual, questões e impactos entre
times.
Três questões são levantadas:
• O trabalho do dia anterior foi
integrado com sucesso? Se não,
por que não?
• Que novas dependências ou
impactos foram identificados?
• Que informações precisam ser
compartilhadas entre as equipes
no Nexus®?
9.2 Eventos do Nexus®
Revisão da sprint do Nexus®
• Realizada ao final da sprint entre
todos times scrum do Nexus®
com as partes interessadas.
• Substitui as reuniões individuais
de revisão do scrum, pois o foco
é no incremento integrado.
• O resultado dessa reunião é o
backlog do produto revisado.
9.2 Eventos do Nexus®
Retrospectiva da sprint do Nexus®
• Oportunidade do Nexus® inspecionar
e adaptar e, se necessário, criar um
plano para melhorias que serão
adicionadas na próxima sprint.
• Realizada em três partes (time
Nexus®/time scrum/time Nexus®)
Assuntos de pauta:
Faltou algum trabalho? Códigos foram
integrados? Houve acúmulo de
dependências? Por que isso aconteceu?
Como pode ser resolvido? Como
evitaremos recorrência?
9.2 Eventos do Nexus®
Artefatos representam o trabalho e ajudam a fornecer transparência e
oportunidade para inspeção e adaptação.
9.3 Artefatos do Nexus®
Backlog do produto
• Único para todo 
Nexus®.
• PO é responsável.
• Itens frequentemente 
decompostos em 
funcionalidades.
Backlog da sprint Nexus®
• Composto pelos 
backlogs individuais do 
times scrum.
• Destaca dependências 
e fluxos de trabalho.
• É atualizado 1x por dia 
(reunião diária).
Incremento integrado
• Soma de todos os 
trabalhos integrados 
completados.
• É inspecionado na 
revisão da sprint 
Nexus®.
• Deve atender à 
definição de “pronto”.
O Nexus® é baseado na
transparência e trabalha com os
times scrum e a organização para
garantir que artefatos e a
integração dos incrementos sejam
amplamente compreendidos.
Informações incompletas e parciais
levam a decisões incorretas ou
defeituosas, e o Nexus® surge para
evitar isso em múltiplos times
scrum.
9.4 Transparência do artefato
Definição de “pronto”
Todos os times scrum aderem à
mesma definição de “pronto”.
O incremento é “pronto” somente
quando está integrado, utilizável e
possível de ser entregue pelo PO.
Times scrum podem ter uma
definição de “pronto” mais
rigorosa,nunca menos.
9.4 Transparência do artefato
Capítulo 10 – Revisão, comparativo e referências
10.1 Revisão dos frameworks
10.2 Comparativos entre os frameworks 
10.3 Algumas referências de aplicação
10.1 Revisão dos frameworks – SAFe® 
Scaled Agile Framework, desenvolvido por Dean Leaffingwell, é uma estrutura de escalonamento ágil 
voltada a criar sistemas melhores através de uma base de conhecimento de princípios, práticas e 
competências comprovadas e integradas para obter agilidade nos negócios usando lean, agile e DevOps. A 
principal missão do SAFe® é “permitir a agilidade comercial para as empresas competirem e prosperarem 
na era digital”, envolvendo diversas áreas da organização, desde o C-Level até operações.
10.1 Revisão dos frameworks - SAFe®
10.1 Revisão dos frameworks - LeSS® 
O large-scale scrum foi desenvolvido por Craig Larman e Bas Vodde. É um framework ágil em escala com 
regras, baseado em princípios, transparência, regras e experimentos. Seu uso é fortemente voltado ao 
desenvolvimento de software em larga escala e atualmente possui dois níveis, LeSS® e LeSS Huge®. 
Fonte: https://less.works/less/less-
huge/index
Fonte: https://less.works/less/less-huge/index
https://less.works/less/less-huge/index
https://less.works/less/less-huge/index
10.1 Revisão dos frameworks - LeSS®
Framework LeSS® (até 8 equipes de 2 a 8 pessoas)
10.1 Revisão dos frameworks - LeSS Huge®
Framework LeSS Huge® (8 equipes até alguns milhares de pessoas em um
produto)
10.1 Revisão dos frameworks - Nexus® 
É uma estrutura de desenvolvimento de software ou produto com três a nove equipes do scrum, em 
sprints de até trinta dias. Foi criado por Ken Schwaber, um dos fundadores do scrum, com a finalidade 
de diferentes equipes scrum trabalharem juntas e entregarem um produto integrado. Suas bases e 
regras possuem altíssimo alinhamento com o ScrumGuide. 
10.1 Revisão dos frameworks - Nexus® 
10.2 Comparativo entre os frameworks
SAFe® LeSS® Nexus®
Maturidade formal no mercado 2011 2014 Oficial (2005 Experimental) 2015
Aderência ao Scrum Guide Média/Alta Alta Alta
Agilidade em escala Scrum / XP / Kanban / DevOps (equipe) Scrum Scrum
Nível Equipe / Programa / Portfólio Equipe / Programa Equipe / Programa
Proximidade do C-Level Alta Média / Baixa Média / Baixa
Quantidade de estruturas
4 (Essencial / Large solution / Portfólio / Full) 2 (LeSS® / LeSS Huge®) 1 (Nexus®)
Quantidade de equipes
5-12 equipes em cada trem de liberação ágil LeSS® (até 8 times) / LeSS Huge® (a partir de 8) 3-9 times
Tamanho das equipes de 
desenvolvimento
5-9 pessoas 2-8 pessoas 3-9 pessoas
Quantidade de papéis
7 Essencial / 10 Large solution / 9 Portfólio / 12 
Full
3 LeSS® / 4 LeSS Huge® 3
Artefatos
11 Essencial / 16 Large solution / 15 Portfólio / 
20 Full
5 4
Eventos 9 Essencial / 12 Large solution / 8 6
Documentação disponível Sim (muito abrangente) Sim (Abrangente) Sim (Abrangente)
Custo de implantação Alto Médio Baixo
Possui roteiro de implantação Sim Sim Não
Cases de sucesso Sim Sim Sim
Possui certificação profissional. 
Quais?
13 (SA / SPC / SP / SSM / SASM / RTE / POPM / 
SDP / SGP / ARCH / ASE / APM / LPM )
6 (Basics CLB / Practioner CLP / Trainer CLT / 
Executives CLE / Coaching Companies CLCom / 
Coaches CLC)
SPS - scaled professional scrum
10.3 Algumas referências de aplicação SAFe® 
10.3 Algumas referências de aplicação LeSS® 
10.3 Algumas referências de aplicação Nexus® 
Referências bibliográficas
Bibliografia básica: 
• LARMAN, C.; VODDE, B. Large-scale scrum: more with less. Boston: Addison-Wesley, 2016.
• LEFFINGWELL, D. SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises. 2. 
ed. Boston: Addison-Wesley Professional, 2018.
• SCHWABER, K. Guia do Nexus. 2018. Disponível em: https://scrumorg-website-
prod.s3.amazonaws.com/drupal/2018-01/2018-Nexus-Guide-Portuguese-
Brazillian.pdf?nexus-file=https%3A%2F%2Fscrumorg-website-
prod.s3.amazonaws.com%2Fdrupal%2F2018-01%2F2018-Nexus-Guide-Portuguese-
Brazillian.pdf. Acesso em: 26 out. 2020.
Bibliografia complementar:
• SCHWABER, K.; SUTHERLAND, J. How agile managers beat the odds, delight their 
customers, and leave competitors in the dust. New Jersey: John Wiley & Sons, 2012.
• SCHWABER, K.; SUTHERLAND, J. The Scrum Guide. 2017. Disponível em: 
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. Acesso 
em: 26 out. 2020.
• MCGREGOR, D. The human side of enterprise: Annotated Edition. New York: McGraw-Hill, 
2006.
https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-01/2018-Nexus-Guide-Portuguese-Brazillian.pdf?nexus-file=https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-01/2018-Nexus-Guide-Portuguese-Brazillian.pdf
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
Crédito das imagens
slide 1 sasint/pixabay.com
slide 4 
https://agilemanifesto.org/iso/ptbr/manifesto.ht
ml
slide 5 Criado pelo autor
slide 6 geralt/pixabay.com
slide 7 mohamed_hassan/pixabay.com
slide 8 OpenClipart-Vectors/pixabay.com
slide 9 Clker-Free-Vector-Images/pixabay.com
slide 10 Criado pelo autor
slide 11 geralt/pixabay.com
slide 12 ar130405/pixabay.com
slide 13 Criado pelo autor; OpenClipart-
Vectors/pixabay.com
slide 14 Criado pelo autor; OpenClipart-
Vectors/pixabay.com
slide 15 
https://www.scaledagileframework.com/; 
https://less.works/; 
https://www.scrum.org/scaled-professional-
scrum-certification
slide 17 
https://www.scaledagileframework.com/about/
slide 18 https://www.amazon.com/Dean-
Leffingwell/e/B001ILHHS8%3Fref=dbs_a_mng_r
wt_scns_share
slide 19 mohamed_hassan/pixabay.com
slide 20 
https://www.scaledagileframework.com/
slide 21 Memed_Nurrohmad/pixabay.com
slide 22 nadisna/pixabay.com; Clker-Free-Vector-
Images/pixabay.com
slide 23 https://v46.scaledagileframework.com/#
slide 24 Free-Photos/pixabay.com
slide 25 https://v46.scaledagileframework.com/#
slide 26 https://v46.scaledagileframework.com/#
slide 30 https://v46.scaledagileframework.com/#
slide 33 https://v46.scaledagileframework.com/#
slide 38 https://v46.scaledagileframework.com/#
slide 41 Criado pelo autor
slide 42 KeithJJ /pixabay.com
slide 43 geralt/pixabay.com
slide 44 geralt/pixabay.com
slide 46 Criado pelo autor
slide 52 Criado pelo autor
slide 53 Criado pelo autor
slide 56 Criado pelo autor
slide 57 Criado pelo autor
slide 59 Criado pelo autor com: OpenClipart-
Vectors/pixabay.com; Memed_Nurrohmad; 
opemicons/pixabay.com
slide 60 OpenClipart-Vectors/pixabay.com; 
https://pixabay.com/illustrations/bank-money-
finance-save-account-2010880/; 
kmicican/pixabay.com
slide 61 NASA-Imagery/pixabay.com; 
WikimediaImages/pixabay.com; 
Emslichter/pixabay.com;
slide 62 Criado pelo autor
slide 63 Criado pelo autor
slide 64 Criado pelo autor
slide 65 Criado pelo autor com: OpenClipart-
Vectors/pixabay.com
slide 66 StartupStockPhotos/pixabay.com
slide 67 Free-Photos/pixabay.com
slide 69 lavanderiadesign/pixabay.com
slide 70 
https://v46.scaledagileframework.com/team-
level
slide 75 Shutterbug75/pixabay.com
slide 81 https://v46.scaledagileframework.com/#
slide 82 https://v46.scaledagileframework.com/#
slide 83 https://v46.scaledagileframework.com/#
slide 84 https://v46.scaledagileframework.com/#
slide 86 dozemode/pixabay.com
slide 92 Bru-nO/pixabay.com
slide 93 
https://v46.scaledagileframework.com/portfolio-
level
slide 97 Free-Photos/pixabay.com
slide 98 https://v46.scaledagileframework.com/#
slide 100 https://less.works/profiles/bas-vodde; 
https://less.works/profiles/craig-larman
slide 101 
"https://www.amazon.com/s?i=stripbooks&rh=p
_27%3ACraig+Larman+%2F+Bas+Vodde+Larman
+%2F+Vodde&s=relevancerank&text=Craig+Larm
an+%2F+Bas+Vodde+Larman+%2F+Vodde&ref=d
p_byline_sr_book_1"
slide 102 
https://www.scrum.org/resources/what-is-
scrum
slide 103 https://less.works/
slide 104 patrickbrassard0/pixabay.com
slide 105 
https://less.works/less/framework/introduction#
One-TeamScrum
slide 106 
https://less.works/less/framework/index