Scrum vs Kanban vs Lean

Em 2009 Henrik Kniberg ao escrever um artigo no seu blog sobre Scrum e Kanban nunca pensou que iria cunhar um conceito (na minha opinião) completamente errado e que após 4 anos continua para durar.

Acho interessante como ele começa por escrever o seu post a dizer que havia muito “buzz” sobre Kanban (em 2009) e se olharmos para Portugal a verdade é que (infelizmente) ainda pouco se fala. Em Portugal, temos realmente uma comunidade bastante forte de Scrum. Temos também uma comunidade crescente de Agile (a tentar de certa forma abraçar a comunidade de Scrum). Agora comunidade de Kanban ainda não sei de nenhuma.

Voltando ao Henrik e ao titulo deste post… o que o Henrik escreveu no post dele (e que depois deu origem a um livro) com o titulo “Scrum vs Kanban” era que o Scrum e o Kanban poderiam ser usados em conjunto (suprimindo as suas lacunas / best of both worlds). Ora se olharmos para o titulo do post dele, o que é sugerido (à primeira vista) é que o Scrum esta contra o Kanban (e vice-versa) e que apenas poderíamos usar um ou o outro.

Como o ser humano é preguiçoso, muitas pessoas na comunidade Agile olhando apenas para o titulo trataram logo de separar as aguas e dar origem a uma certa rivalidade entre os “seguidores” de Scrum e os “crentes” em Kanban e Lean. A rivalidade cresceu de tal forma que inclusivamente o autor sentiu-se na “obrigação” de vir a terreiro dizer que o titulo tinha sido mal interpretado e que ambos os “métodos” podiam (e em alguns casos deviam) ser usados em conjunto.

A verdade é que depois do Scrum, do Kanban e do Lean se darem a conhecer ao mundo e de já terem sido bastante explorados, a rivalidade mantém-se e pelo que percebo está para durar.

Inclusivamente, Ron Jeffries, co-autor do eXtreme programming, manifestou este mês a sua desilusão por ter testemunhado que no maior evento Agile do mundo, #Agile2013 em Nashville (EUA), organizado pela Agile Alliance, os participantes estavam mais preocupados em demonstrar que a sua metodologia fetiche (Scrum, Kanban, Lean, etc.) era melhor do que as outras do que propriamente trabalhar em conjunto para tirar proveito do melhor de cada uma delas.

Tal como Henrik teve oportunidade de dizer em 2009 e agora Ron em 2013, o Scrum, o eXtreme Programming, o Kanban e o Lean não são incompatíveis. Inclusivamente existe a forte convicção de que combinando um pouco de cada uma destas “ideologias” podemos atingir um alto nível de eficiência.

O que eu penso sobre este assunto (e apesar de simpatizar mais com Scrum e eXtreme Programming do que com o Kanban e o Lean) é que a comunidade Agile é pequena de mais para este tipo de rivalidades e clivagens. Tal como qualquer grupo, separados pouco valemos mas juntos valemos muito.

Não entendo o interesse que existe por de trás destas separações ou se é apenas um fenómeno humano ficarmos “cegos” com algo que (realmente) apreciamos ignorando tudo o que está à nossa volta.

Sinceramente não sei… agora que é uma pena a malta de Scrum não se dar com a de Kanban (e vice-versa) e passarem mais tempo a discutirem uns com os outros em vez de trabalhar em conjunto… lá isso é.

Pode ser que isto mude no futuro mas já nisto há tempo suficiente para saber que é pouco provável. 😦

Até para a semana.

retro games

Existem muitas formas de conduzir uma retrospectiva.

Apesar de não ser dos temas mais discutidos na comunidade Agile existe muito material disponível na internet e existe um livro muito bom que se chama: “Agile Retrospectives:​ Making Good Teams Great” da Esther Derby e da Diana Larsen.

Alguns Scrum Masters fazem sempre as retrospectivas by the book: “O que devemos continuar a fazer”, “O que devemos parar de fazer” e “O que devemos começar a fazer”.

Eu pessoalmente gosto de garantir que não faço duas retrospectivas iguais de forma a garantir entusiasmo e puxar pela participação da equipa.

Deixo-vos aqui alguns três exemplos de retrospectivas que correram particularmente bem:

1. Sailboat

pedro torres no placo

A ideia do Sailboat é por a equipa a pensar em: objectivos (ilha), impedimentos (ancoras), riscos (rochedos) e coisas que nos favorecem (vento).

2. Radar

pedro torres no placo

O radar pode ter quantos eixos vocês quiserem. Aconselho a não terem muitos para não dispersarem a atenção da equipa. Para jogarmos o radar apenas temos de ter os eixos, que devem ter os temas que queremos discutir / reflectir, e uma escala, que por exemplo pode ser de 1 (Mau) a 5 (Excelente). Pedimos a cada membro da equipa para indicarem, em cada eixo, onde acham que a equipa está. No final pedimos para todos escreverem em post-its o que acham que seria preciso para melhorarmos um nível em cada um dos eixos.

3. Happiness metric

pedro torres no placo

O objectivo do Happiness metric é “avaliarmos” o estado de felicidade de cada membro da equipa. Para isso pedimos a cada membro da equipa que numa escala de 1 (Infeliz) a 5 (Felicíssimo) indique a sua felicidade. No fim perguntamos o que seria preciso para que a felicidade subisse um ponto na escala.

Lembrem-se que a retrospectiva serve essencialmente para:

1. descontracção da equipa no final da sprint;

2. gerar action points para a próxima sprint (continuous improvement / Kaizen).

Não tem como objectivos:

1. finger pointing / blaming poker / troca de acusações;

2. fragilizar a equipa.

Boas retrospectivas. 🙂

Até para a semana.