Reunião não precisa ter agenda, precisa ter propósito.
O que vamos decidir? Qual o entregável desta reunião?

Líder da Reunião

• É quem convoca a reunião
• Precisa garantir a eficiência, get things done.
• É ele quem fecha as atividades como feita
• Tem que ter claro o que quer resolver com a reunião
• Ele é quem encerra a reunião também.

Tipos

• Comunicação / visibilidade / Alinhamento
• Decisão (não mais q 5. pessoas)
• Accountability
• Ideação / Brainstorm
• Produzir (onde as pessoas construem juntos algo)
• SCRUM (Cada cerimônia tem um objetivo)

Outros

• É normal dispersar durante a reunião. Cabe ao lider identificar se tal dispersão vai ajudar a resolver o problema. O objetivo da reunião. Se não ajudar, chame atenção e retome para o foco.

Desafios

• Mexer no produto que é vaca leiteira
• Risco alto por errar

Como resolver

• Criar ambientes seguros!
  • hackaton
  • 20% rule
  • incubadora – ao lançar, time dispersa
  • laboratório de inovação
• Mude cultura
  • fuckup nights – compartilhe fracassos e acabe com o taboo! valorize!

Referências

• https://www.ted.com/talks/linda_hill_how_to_manage_for_collective_creativity
• http://www.romanpichler.com/blog/leveraging-failure-in-product-management/

Para ter autonomia precisa

• Estar alinhado com a empresa
• Dar visibilidade das atividades/responsabilidades/entregas
• Track record
• Sua autonomia deve ser conquistada!

Como ter autonomia?

• Objetivos e Resultados claros
  • OKR
  • Quadro de Objetivo
• Visibilidade
  • Indicadores a monitorar
  • Report (plano trimestre)
• Autonomia
  • Quadro meta/autoridade
  • Papéis e Responsabilidades
  • SLA Qualidade
  • Framework priorização (como priorizar)
• Colaboração
  • Mgmt 3.0
  • Agile

Referências:

• https://blog.intercom.com/building-autonomously/

Hackaton ajuda a moldar o comportamento da TI!

Pilares do hackaton

1. A pressão do prazo alimenta a inovação
2. Auto-Organização é escalável
3. Confiança e empatia criam velocidade
4. Arrisquem tudo!
5. Código vence argumentos

Como funciona?

1. Abre um board Trello para que todos possam colocar suas idéias. Eu disse todos…. qualquer um da empresa pode dar idéia! =) Importante também descrever a idéia!
2. Um dia antes do hackaton, todos se encontram para apresentar suas idéias
3. Participantes dão join nas idéias que curtiram.
4. Hackaton deve durar de 24 a 48hr, escolher o modelo.
5. Sem PPT! Só pode mostrar o sistema no dia, nada de PPT. Este deve ser desqualificado na hora.
6. Apresentar os projetos e público vota nos vencedores
7. Importante liberar comida e ambiente propício para virar a noite. =)

Regras

• Uma pessoa não pode participar em mais de um time;
• Times devem ser formados com >= 2 && <= 5 pessoas;
• Não necessariamente você precisa se associar a um projeto sugerido por você. Se interessou por algum projeto e quer trabalhar nele, basta se associar ao projeto, respeitando o limite máximo de pessoas permitidas;
• Caso > 5 pessoas, as últimas cadastradas não farão parte do projeto 😦
• Código só pode ser escrito durante o hackaton

Critérios de Avaliação

• Viabilidade: O projeto tem uma chance de ser continuado pela empresa? A idéia é escalável e aplicável ao nosso contexto? É realista a chance de desenvolver o projeto?
• Originalidade: Seu projeto é criativo, novo e inovador? É algo que nós já conhecemos, ou é uma idéia disruptiva?
• Impacto para empresa: A idéia tem potencial de criar novos negócios? O projeto tem chance de reduzir custos e evitar desperdícios? A idéia resolve um problema real que vivemos no nosso dia-a-dia?

Pesquisa

[3]

Referências

1. https://www.fastcompany.com/3002845/secrets-facebooks-legendary-hackathons-revealed
2. http://vidadestartup.org/como-realizar-hackathons-em-sua-empresa-pode-mudar-completamente-o-ambiente-de-trabalho/
3. https://insights.stackoverflow.com/survey/2018

Desafios

• Mexer no produto que é vaca leiteira
• Risco alto por errar
• Time não consegue sair da operação

Como resolver

• Crie ambiente seguro para ter e validar a idéia
  • hackaton
  • 20% rule
  • incubadora – após lançar o produto, dispersar o time
• Uma vez validada a ideia
  • Inicie um time independente
  • Funding separado
  • Reportando temporariamente para o CEO (pelo menos no começo)

Referências

• http://www.romanpichler.com/blog/leveraging-failure-in-product-management/

 

Manifesto Ágil

[2]

Fluxo

• Release planning (previsibilidade)
• Gestão Backlog (planejamento)
• Planning (alinhamento)
• Daily (comunicação)
• Review (responsabilidade)
• Retrospectiva (melhoria contínua)

Release Planning / Roadmapping

• Considerar dias úteis
• Desdobrar hipóteses a partir dos OKRs
• Validar com principais stakeholders a priorização
• Quebrar em P, M e G
• Considerar 50% da capacidade do time (deixar restante para operação, mudanças e etc)
• http://www.romanpichler.com/blog/product-roadmap-vs-release-plan/
• https://app.roadmunk.com
• https://www.productplan.com/roadmap-timelines/

Gestão do Backlog

• Responsabilidade do Gerente de Produto, especificar e manter sempre priorizado
• Time faz backlog grooming
  • Todo planning, time entende um pouco das estórias seguintes, estima, tira dúvidas e etc

Planning

• Pega as hipóteses que estão priorizadas no backlog
• Quebra em atividades menores (ideal 1 ticket/postit por dia por pessoa)
• Tira dúvidas com Gerente de Produto/stakeholders
• Estima tudo

Especificação / Requisitos

• Deve focar na experiência completa, não apenas nos requisitos
• Representa o comportamento da aplicação
• Deve ser legível por: QA, DEV, MKT, SAC, Operação
• Especificação muda logo após começar!
• É importante ter requisitos priorizados, wireframes e mocks

Sprint

• Separe uma parte para refatorações. Qualidade de código é lei.
• Composição do sprint
  • Bugs reportados pelo cliente
  • Features
  • Bugs internos
  • Refactors
  • Performance (reportado por ferramenta como new relic)
  • Erros de log (tipo sentry)
  • Discoverys
  • Melhorias
  • Otimizações

Daily

• Todos de pé, em frente ao quadro, mesmo horário, todo dia
• Cada um fala: o que fez, o que está fazendo e impedimentos
• Passar pelos pontos “a melhorar”, que veio da retrospectiva
• Cabe ao SM/PO remover impedimentos toda reunião

Review?

• Se fizer deploy grande
  • Hora de apresentar tudo em homologação
  • Sempre um dev apresenta (importante alternar, pois ninguém quer apresentar algo com bug. Dessa forma todos ficam com “skin in the game”)
  • PO pode abortar uma tarefa e pedir pra não subir se julgar não estar bom o suficiente (importante levar este ponto pra retrospectiva pra aprender pq desenvolveu e não subiu, onde erramos?)
• Se for microdeploy (minha preferência)
  • A medida que o sprint anda, no daily o dev ja informa ter acabado
  • PO/QA valida a micro tarefa e libera
  • No final do sprint, está tudo em produção

Retrospectiva

Definição: “Uma reunião especial que o time se reune após completar um incremento do trabalho para inspecionar e adaptar seus métodos e forma de trabalhar” Daiana Larsen & Esther Derby

• Time avalia como foi o sprint. Etapa crucial para melhorar sempre.
• Quebrar em: continuar, começar, melhorar e parar
• Ao final, todos votam nos top 3 postits (cada um tem 3 pontos pra votar)
• Pegam-se os mais votados, atribuem-se donos (Importante ter as pessoas fazendo parte da solução e não só do problema) e coloca no quadro do time. A idéia é acompanhar diariamente os pontos a se melhorar.
• Deve-se colocar as pessoas certas na reunião. Stakeholders ou envolvidos no sprint
  • No entanto, a lavação de roupa suja é somente com o time. Ou seja, primeiro os stakeholders passam a visão deles do que melhorar, depois o time segue. [1]
• O que não deve acontecer
  • esta tudo ótimo e não temos nada pra melhorar
  • debater backlog
  • não ter hora pra acabar
• https://labs.spotify.com/2017/12/15/spotify-retro-kit/
• https://www.infoq.com/br/presentations/o-invisivel-das-retrospectivas-ageis

Design Sprint

• http://www.gv.com/sprint/
• https://www.youtube.com/watch?v=K2vSQPh6MCE

 

[1] http://www.romanpichler.com/blog/sprint-review-tips-for-product-owners/?doing_wp_cron=1511890677.9049379825592041015625

[2] https://www.linkedin.com/pulse/5-organisational-agility-messages-land-1-hour-executive-chris-webb/