O que eu e a @nataliarsand vimos no #AgileBrazil de Junho de 2010 e apresentamos para nossos colegas da Dell.

1. O que aprendemos no
#AgileBrazil
Rafael Bandeira <@rafb3 >
Natalia Arsand < @nataliarsand >

2. #AgileBrazil
Conferência Brasileira sobre Métodos
Ágeis de Desenvolvimento de Software
22/06 à 25/06
Treinos/Cursos, Palestras, Cases,
Workshops, Keynotes, WBMA

3. @nataliarsand
Estudante de Design Gráfico
e de Produto
Desenvolvedora front-end do Dell.com

4. @rafb3
Interessado em aplicação de práticas e
teorias de gerenciamento na vida
Gerente de Produto
do front-end do Dell.com

5. Certified Scrum Product Owner Training
#CSPO

6. “Product Owner vai
além de user stories”
Visão do produto
Conhecimento do negócio
Interação com stakeholders
Responde pelo produto para a
organização
Liderança para guiar o time

7. “Paulo Otávio”
“Powerless Observator”

8. Gerente de produto
Gerente de equipe
Expert do cliente
Dono da empresa
“É UM PAPEL E NÃO UMA
FUNÇÃO”

9. “Visão do produto
é essencial para manter
o foco do time
e do produto”
Auto-organização
Elevator Pitch
Product Vision Box
Remember the Future

10. Formato canônico do Mike Cohn (Como % quero % para %)
Use cases, “formato invertido”...
Três C’s do XP: Cartão, Conversa, Confirmação
O que retorna de valor? Quem é beneficiado? Como?
“REQUERIMENTOS NÃO
PRECISAM SER NO FORMATO
DE USER STORIES”

11. Técnicas de Priorização
“Buy a Feature” KANO

12. #AGILEBRAZIL

13. Planejamento de Release?
• Processo através do qual
decidimos o que fazer em
seguida num projeto de
software
• Embora uma determinada
estratégia pareça mais
significante e fácil de se
entregar valor, deve-se
considerar as dependências,
valores e custos, além das
diversas opiniões dos
stakeholders a satisfazer ==
NÃO DECIDA simplesmente
por parecer certo/melhor

14. Oportunidade, time-to-market
Juros e estimativa de prejuízo
@pbpk tentando mudar o conceito
DÉBITO TÉCNICO EM
TROCA DE VELOCIDADE

15. “If it hurts,
do it more oftenly”

16. Coaching em equipes ágeis?
• O coach: Trabalha JUNTO com o time, ajudando o mesmo a se
movimentar, atingir os objetivos e não estagnar
• Qualquer pessoa pode ser coach
• Fazer perguntas, motivar, facilitar, olhar além e mostrar como fazer a
coisa certa
• O coach não sabe tudo, ele indaga sobre tudo
• Descobrir o problema real das coisas – e resolver pela raíz

17. Features relevantes apenas se têm como ser anunciadas para
venda do produto
MMF –
MINIMUM MARKETABLE
FEATURE

18. • PO não deve se focar
somente nas necessidades do
business, deve se entender
do software que o time está
entregando
• Entender as necessidades do
cliente e ter a visão do
software, com isso,
satisfazer o cliente e
entregar melhor valor ao
produto
• Foco: Entregar valor,
entregar valor, entregar valor
--- repete comigo
• O time DEVE dar input para
o PO, e expor os
pensamentos a respeito dos
requerimentos e projetos

19. Value = Why / How
Se não tem porque, não tem valor
“Be a dude!!”
DUDE’S LAW

20. Não fique olhando para o
Wallpaper
• O que vocês está
entregando?

21. Não fique fuçando no
Twitter a cada 5 minutos
• Por que você está
fazendo isso?

22. Os seus emails podem
esperar
• Qual o valor que
isto está agregando?

23. Café Kaizen

24. WIP é disperdício
Atraso na entrega de retorno do investimento
“STOP STARTING ,
START FINISHING”

25. Perguntas e Respostas.
Fala, que eu te escuto.

26. Obrigado.