Times Scrum - Entendendo melhor os desafios

www.scrumhalf.com.br
Team ScrumHalf no 10º Agile Beer
Times Scrum - Caindo na Real

Sumário
• Introdução
• Tipos de Times
• Realidade das Trincheiras
• Debate

Times Scrum – Scrum Guide
O Time Scrum é composto pelo Product Owner,
o Time de Desenvolvimento e o Scrum Master.
Times Scrum são auto-organizáveis e
multifuncionais.

Papéis – By the Book
• P.O.
– Responsável por maximizar o valor do produto e do trabalho do Time de
Desenvolvimento. Como isso é feito pode variar amplamente através das
organizações, Times Scrum e indivíduos.
• Scrum Master
– O Scrum Master é responsável por garantir que o Scrum seja entendido e
aplicado. O Scrum Master faz isso para garantir que o Time Scrum adere à
teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o
Time Scrum.
• Dev Team
– Consiste de profissionais que realizam o trabalho de entregar uma versão
usável que potencialmente incrementa o produto “Pronto” ao final de cada
Sprint. Somente integrantes do Time de Desenvolvimento criam
incrementos.

Times – Uma Visão Qualitativa
• Times auto-organizáveis escolhem qual a melhor
forma para completarem seu trabalho, em vez de
serem dirigidos por outros de fora do Time.
• Times multifuncionais possuem todas as
competências necessárias para completar o
trabalho sem depender de outros que não fazem
parte da equipe.
• O modelo de time no Scrum é projetado para
aperfeiçoar a flexibilidade, criatividade e
produtividade.

Times – Uma Visão Quantitativa
• “O tamanho ideal do Time de
Desenvolvimento é pequeno o suficiente para
se manter ágil e grande o suficiente para
completar uma parcela significativa do
trabalho dentro dos limites da Sprint. “
• Número Mágico

• Dono do Produto ( P.O. –
Product Owner)
– Define o que deve ser feito
• Scrum Master
– Garante o funcionamento
do SCRUM
• Equipe (Dev Team)
– Multidisciplinar
– Trabalha no
desenvolvimento do produto
SCRUM – Participantes

Alguns Papos

QUALIDADE
Olhando as características de trabalho do time

Times – Uma Taxonomia
• Times de Backlog
• Times de Componentes
• Times de Features

Times de Backlog
• Principal foco é “matar”o Sprint Backlog
• Processo fica mecânico, automatizado
• Sprint planning é um resultado da última Sprint
somente
• Falta visão do produto e um plano estratégico de
entregas
• Atingem rapidamente um teto de velocidade e
estabilizam
• Not fun…

Time de Componente
• Times muito direcionados para o lado técnico
• Operam sob a influência de líderes técnicos
• Foco é em um componente da solução
• Tudo fica orientado ao conhecimento e a expertise
sobre o componente e a tecnologia
• Sprint Planning dominado por um membro “senior”
ou expert da equipe
• Velocidade do time cai e o entusiasmo acaba
• Membros do time aguardam definições ao invés de
colaborarem – falta empoderamento

Time de Features
• Preocupação do time é com as características
do produto
• Visão do Produto e Planejamento Estratégico
de Releases orientam o Backlog
• Todos os membros do time colaboram –
motivados
• O foco é sempre adicionar valor às features

Sugestões
• Retrospectivas são uma oportunidade para
entender o seu time
• Pense em usar ferramentas visuais para os
planejamentos de nível mais alto
• Busque sempre a melhoria continua. Evite a
estabilidade
• Crie a cultura de Features. Assim deve ser
orientado o pensamento do time.

QUANTIDADE
Olhando o tamanho do time

• Estudantes
universitários
• Equipes completando
tarefas diversas
• Melhor aceitação 4-5
ASA Study

• 35K-90K SLOC
• Projetos agrupados por
tamanho das equipes
• Distribuição uniforme de
tamanho equipe x
tamanho de projetos
• Em media, grupos
menores gastaram menos
tempo (12 meses x 17
meses)
Small is Beatiful

• Estudo de Larry
Macherone
• Dados de softwares de
gestão ágil
Agile Performance

Sugestões
• Realmente Small is Beatiful… Mas não muito small…
• Número mágico ainda vale
• Maior, mais problemas de comunicação e
coordenação
• Menor, sujeito a intempéries. Melhor sempre mais de
um cobrindo algo.
• Invista na formação do time – atividades extra
também são importantes
• Estabeleça metas claras

Caindo na Real…
• Nossos times costumam ser pequenos
• Multifuncional nem sempre é real
• Domínio do Scrum não é absoluto
• Complexidade da coordenação diminui a
agilidade
• Leva tempo formar time de alta performance
– mínimo 6 meses

Referências
• What Type of Scrum Teams Do You Have? - Greg Tutunjian -
https://www.linkedin.com/pulse/what-type-scrum-teams-do-
you-have-greg em 13/09/2016
• Choosing the Team Size in Scrum – Mark Levison –
https://agilepainrelief.com/notesfromatooluser/2016/10/choosin
g-the-team-size-in-scrum.html - 10/10/2016
• Familiar Metric Management - Small is Beautiful-Once Again –
Lawrence H. Putnam and Ware Myers -
http://www.qsm.com/fmm_28.pdf
• Five Steps for Creating High Performance Teams – Ben Waber -
https://agilepainrelief.com/high-performance-teams
• ScrumHalf Agile Manager – http://www.scrumhalf.com.br

Muito Obrigado!
FIM
José Rodrigues
rneto@myscrumhalf.com
@zerneto
27

Times Scrum - Entendendo melhor os desafios

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Times Scrum - Entendendo melhor os desafios

Similar to Times Scrum - Entendendo melhor os desafios (20)

More from José A. Rodrigues Nt.

More from José A. Rodrigues Nt. (11)

Times Scrum - Entendendo melhor os desafios