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/

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.

BDD Scenarios should be automated

Last February, I had this conversation with an agile coach (AC) at an organization in an agile transformation:

AC: – “We started up on BDD today!”

Me: – “Really? That’s awesome! Automating scenarios?”

AC: – “No, just writing scenarios.”

Me: -“So it’s not BDD… It’s specification by Example.”

AC: -“Why not? BDD doesn’t need test automation.”

Me: -“We can say that’s half way to BDD. Scenarios shall be automated after writing it.”

After few minutes, no agreement.