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

Times Scrum: Caindo na Real - Palestra 10o. Rio Agile

Embed Size (px)

Citation preview

www.scrumhalf.com.br

Team ScrumHalf no 10º Agile Beer

Times Scrum - Caindo na Real

www.scrumhalf.com.br

Sumário

• Introdução

• Tipos de Times

• Realidade das Trincheiras

• Debate

www.scrumhalf.com.br

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.

www.scrumhalf.com.br

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.

www.scrumhalf.com.br

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.

www.scrumhalf.com.br

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

www.scrumhalf.com.br

www.scrumhalf.com.br

www.scrumhalf.com.br

• 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

www.scrumhalf.com.br

Alguns Papos

www.scrumhalf.com.br

QUALIDADEOlhando as características de trabalho do time

www.scrumhalf.com.br

Times – Uma Taxonomia

• Times de Backlog

• Times de Componentes

• Times de Features

www.scrumhalf.com.br

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…

www.scrumhalf.com.br

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

www.scrumhalf.com.br

Time de Features

• Preocupação do time é com as característicasdo produto

• Visão do Produto e Planejamento Estratégicode Releases orientam o Backlog

• Todos os membros do time colaboram –motivados

• O foco é sempre adicionar valor às features

www.scrumhalf.com.br

Sugestões

• Retrospectivas são uma oportunidade para entender o seu time

• Pense em usar ferramentas visuais para osplanejamentos de nível mais alto

• Busque sempre a melhoria continua. Evite a estabilidade

• Crie a cultura de Features. Assim deve serorientado o pensamento do time.

www.scrumhalf.com.br

www.scrumhalf.com.br

QUANTIDADEOlhando o tamanho do time

www.scrumhalf.com.br

• Estudantes

universitários

• Equipes completando

tarefas diversas

• Melhor aceitação 4-5

ASA Study

www.scrumhalf.com.br

• 35K-90K SLOC

• Projetos agrupados portamanho das equipes

• Distribuição uniforme de tamanho equipe x tamanho de projetos

• Em media, gruposmenores gastaram menostempo (12 meses x 17 meses)

Small is Beatiful

www.scrumhalf.com.br

• Estudo de Larry

Macherone

• Dados de softwares de

gestão ágil

Agile Performance

www.scrumhalf.com.br

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

www.scrumhalf.com.br

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

www.scrumhalf.com.br

www.scrumhalf.com.br

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/choosing-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

www.scrumhalf.com.br

Muito Obrigado!FIM

José Rodrigues

[email protected]

@zerneto

27