Guia Oficial Kanban Método em Português

A Kanban University lançou o Guia Oficial Kanban Método em Português!

Faça download gratuito em https://resources.kanban.university/kanban-guide/#1614210664834-29216f47-3032

Ou diretamente pelo link https://resources.kanban.university/wp-content/uploads/2021/04/The-Official-Kanban-Guide_Portuguese_A4.pdf

Ou por esse backup:

Mentoria em Método Kanban?

Conheça mais em https://dionatanmoura.com/mentoria-para-agilistas/

Publicidade

Scrum Master é Membro do Time: Não Existe Sub-Time Dev

Ontem entrevistando um Scrum Master candidato para uma vaga de Agilista, questionei como ele vem dando mentoria para uma pessoa que recém se tornou Scrum Master na empresa. Pedi exemplos dele ajudando a melhorar o curso/comportamento da nova SM, e ele me contou um ocorrido excelente.

A pessoa Scrum Master deve evitar falar “o time” como se não fizesse parte dele. O Scrum Master É parte do time. Então toda vez que o Scrum Master falar “eu e o time”, na verdade deve falar “nós do time”. Assim também cria mais proximidade e conexão com os membros do time Dev.

Esse é um dos problemas históricos criados pelo Scrum: ter dividido o Time Scrum e o Dev Team. Time Scrum é composto pelo Product Owner, Scrum Master e Dev Team. Eis minha crítica: um time dentro de outro time? Então evite falar “time” se referindo ao DevTeam. Time é todo mundo: PO + SM+ Devs. Não chame mais de DevTeam.

O Guia do Scrum de 2020 removeu o termo “Dev Team”, referindo-se ao Time Scrum apenas. Todos são parte de um time apenas. E indo além, o cliente faz parte do time também no eXtreme Programming. Veja mais sobre no meu livro publicado eXtreme Programming pela Casa do Código.

Referências:

Scrum Guide 2020 (um time apenas): https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-PortugueseBR-2.0.pdf

Scrum Guide 2017 (Time Scrum e sub-time DevTeam): https://scrumguides.org/scrum-guide-2017.html

Precisa de ajuda para mudar isso?

Saiba mais sobre Mentoria para Agilistas em https://dionatanmoura.com/mentoria-para-agilistas/

RICE: Prioritizing Roadmap/Backlog by (Reach + Impact + Confidence) / Effort

Reach: how many people will this impact? (Estimate within a defined time period.)

Impact: how much will this impact each person? (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.)

Confidence: how confident are you in your estimates? (High = 100%, Medium = 80%, Low = 50%.)

Effort: how many “person-months” will this take? (Use whole numbers and minimum of half a month – don’t get into the weeds of estimation.)

https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/

Não Existem Rituais ou Cerimônias Ágeis

Um pedido que tenho: parem de utilizar os termos “rituais” ou “cerimônias” ágeis.

Parem. Por favor, parem.

Por quê? Rituais e cerimônias trazem o significado que é um culto, algo religioso, algo que deve ser feito sem questionar. Ágil não é uma religião, não somos “xiitas” em seguir diariamente os mesmos processos.

Lembre-se do primeiro valor do Manifesto Ágil: “Indivíduos e interações mais que processos e ferramentas”. O processo sim é importante, mas é um meio para indivíduos trocarem conhecimento e alinharem seu trabalho através de interações. Não são ritos, nem cerimônias a serem repetidas sem questionar.

Lembre-se do primeiro princípio do Manifesto Ágil “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.” Nossa maior prioridade não é, absolutamente não é, seguir o processo.

Utilize os termos reuniões ágeis, workshops, encontros, open spaces.

Busque melhoria contínua sobre reuniões. Reflita e adapte frequentemente o próprio processo.

Em nenhum lugar do Guia do Scrum se fala em cerimônias ou rituais. Apenas reuniões. XP, mesma coisa. Método Kanban? Idem.

Scrum não é para Gestão Ágil de Projetos

Faz tempo que ouço esse termo “Scrum para Gestão Ágil de Projetos”. O que é uma contradição. Scrum é para Desenvolvimento de Produtos.

Mas qual a diferença? O que você realmente pretende com Scrum? Gerir um projeto de uma forma ágil? Leia o PMBOK, tem lá uma parte ágil. 🙂

Em Desenvolvimento Ágil de Software, fala-se de Desenvolvimento de Produtos, porque sabe-se que Software não é algo que se constrói, coloca em produção e ninguém mais precisa cuidar. Um antipadrão é construir o software num time de projeto, e depois fazer uma KT (knowledge transfer – como se conhecimento se transferisse facilmente) para um time menos preparado de suporte ou manutenção. Um time de produto, um time ágil efetivo, trabalha tanto no desenvolvimento de novas funcionalidades quanto em melhorias, dívidas técnicas (dívidas, não débito, pois possui juros) e bugs.

Scrum fala muito de Empirismo. Ou seja, muito de descoberta existe durante o desenvolvimento do produto, e isso serve como feedback para desenvolver um melhor produto, de acordo com as expectativas do cliente, do negócio, do usuário. Como se planejaria isso no início de um projeto? Dificilmente.

Ok, mas preciso gerir um projeto, o que eu faço? Tudo bem utilizar Scrum, é um método que vai ajudar sim a ser um projeto mais ágil, com menos riscos, maior engajamento das pessoas, clientes e usuários. Mas entenda, não é o propósito real do Scrum. Tente buscar a troca de projetos para produtos. Mesmo que se fale em projeto, pense em produto.