http://www.youtube.com/watch?v=_NRWtd_SiU8

Fiquei feliz com o resultado, e resolvi divulga-lo aqui no blog, liberando o mesmo sob a licença creative commons.

Sem mais delongas, estou disponibilizando o trabalho aqui.

Como o volume de emails é gigantesco, é meio impossível acompanhar sempre todas as threads. Vez ou outra, escolho uma thread que me interesse para acompanhar. A última, que me interessou muito, foi a seguinte: “Are burndown charts required?” (em português, “Os gráficos de burndown são requeridos?”).

Enquanto a maioria das pessoas davam respostas gigantescas, explicando as mil e uma razões do porquê da importância de ter bilhões de gráficos de burndown, a resposta que o Tim Walker deu me chamou muita atenção. O Tim respondeu, em uma única linha, o seguinte:

No. Burndown charts are not required. Delivering software is.

Thanks,
Tim

Imediamente encaminhei esta mensagem para o Marcos Pereira, que deu a resposta que me motivou a escrever esse post, e me forneceu, muito oportunamente, o título desse post:

Engraçado como a galera começa a perder o foco.  Eu percebia muito isso quando criamos a mds: entregar software não era o foco. Era apenas algo no meio do processo todo. Quem não tem foco em entregar software, vai continuar sem ter, usando Scrum ou não, eles não entendem que o gráfico é uma ferramenta como qualquer outra e que é preciso alguma inteligência para decidir usar ou não.

Um idiota com uma ferramenta continua sendo um idiota, só que mais perigoso.

–
Marcos Silva Pereira
http://marcospereira.wordpress.com
“People who are crazy enough to think they can change the world, are the ones who do.”

Realmente. Precisamos ter inteligência para discernir o que é necessário ou não na nossa implantação do Scrum. A única coisa que eu acredito é o seguinte: antes de tentar mudar, faça o Scrum “by the book” por algumas Sprints. Conheça o processo inteiro, os valores e tudo mais, e depois tome uma decisão sensata sobre usar ou não usar certas ferramentas.

Na minha experiência com Scrum, a um primeiro momento nós meio que “desprezamos” o gráfico de Product Burndown. Agora, esse gráfico está sendo necessário para preencher uma lacuna na hora de montar o plano de releases. Resultado? Estamos voltando ao “by the book” e voltando à fazer o Product Burndown!

Trava língua: tente falar “Blog do Boris” rapida e repetidamente. Duvido você não enrolar a sua língua!

Alguns dias depois do início da conversa, me deparo com este post no blog do Boris Gloger e tenho aquela velha sensação de deja-vu. Para dar mais acesso às pessoas, resolvi traduzir este post muito valioso. A razão pela qual não traduzi o termo “Under-performers” é porque não há uma maneira muito clara de se referir à isso em português. Em suma, significa uma pessoa que não está comprometida, que não se esforça, e termina atrasando a velocidade do time como um todo, pois a velocidade do time é sempre determinada pelo seu membro mais lento. Vamos à tradução:

Despeça alguém hoje! é um ótimo livro escrito por Bob Pritchett sobre empreendedorismo. Eu gostei dele, por ter tem um título muito provocativo, e algumas idéias muito contra-intuitivas. Despedir alguém quando ele não têm atingido a produtividade desejada, ou não quer trabalhar da maneira que eu quero foi uma lição que tive que aprender durante os últimos anos. Aprender que demitir alguém era ok, aceitável, foi importante para mim. A coisa boa é – as pessoas que eu despedi sempre terminaram em novos cargos/posições muito bons. Eles terminaram sendo mais felizes do que nunca.

Essa lição também me ensinou a ser um Scrum Master melhor. Porque?! Eu entendi que às vezes, a melhor maneira de aumentar a produtividade de um time é se livrar de alguém que bloqueia o time. Não me levem à mal – despedir alguém não é a minha primeira estratégia para agir quando alguém não se aplica. Mas é uma opção.

Veja o original, em inglês, aqui.