Mudando as regras do jogo
Quantos daily meetings deve haver por sprint? Este trecho retirado do livro Agile Project Management with Scrum sugere que deve haver um daily meeting por dia de sprint.
The Team members have two administrative responsibilities during the Sprint: they are to attend the Daily Scrum meeting, and they are to keep the Sprint Backlog up-to-date and available in a public folder on a public server, visible to all.
Além do mais, o diagrama abaixo indica que deve haver daily meeting apenas em dias de sprint:
O que acontece é que no último dia do sprint podem ainda existir estórias não finalizadas. Para que todas elas sejam colocadas no status done, alguns times costumam fazer um daily meeting extra no dia seguinte ao fim do sprint.
O ideal no Scrum é não iniciar uma estória enquanto outra ainda está em andamento - fazer item por item. Por outro lado, cada membro do time tem sua especialidade e pode escolher que tarefa irá fazer. Talvez um determinado membro queira assumir uma tarefa de uma outra estória que não a que está sendo trabalhada no momento, pulando tarefas da estória atual e quebrando assim essa regra. Qual é a coisa certa a fazer neste caso?
O que essas duas questões têm em comum? Ambas exploram as caracterÃsticas empÃricas e adaptivas do Scrum. Mas até que ponto as regras podem ser mudadas?
If someone wants to change the rules, use the Sprint retrospective meeting as a forum for discussion. Rule changes should originate from the Team, not management. Rule changes should be entertained if and only if the ScrumMaster is convinced that the Team and everyone involved understands how Scrum works in enough depth that they will be skillful and mindful in changing the rules. No rules can be changed until the ScrumMaster has determined that this state has been reached.
Eu acredito muito no que diz este trecho desse mesmo livro. Ele sugere que as regras podem ser livremente mudadas, desde que o desejo parta do time e que o time já entenda bem o processo. Isso serve para garantir, entre outras coisas, que mudanças nas regras não engessem o processo. Além disso, ao meu ver, quando o time já tem no sangue os princÃpios ágeis, dificilmente uma mudança representará um retrocesso. Somente quando o time atinge esse grau de maturidade, adaptações à s regras podem e devem ser feitas.
August 4th, 2008 at 2:19 pm
Belo post, Anselmo!
Eu concordo bastante com a idéia que você apresentou, entretanto, acho que o processo para um determinado time poderia ser perfeitamente “construÃdo de forma incremental”, ou seja, ainda que o time erre na decisão sobre alguma mudança, este mesmo time poderia, perfeitamente, voltar atrás e levar esta experiência como uma “lição aprendida”.
August 4th, 2008 at 7:18 pm
Mas o SCRUM é um RUP meio HIPPIE, dessa galera do Software & AMOR Livre
August 6th, 2008 at 12:27 pm
Em um _time_ todos trabalham juntos para atingir o mesmo objetivo. Fazer isso é ruim pois mascara um problema - as pessoas não querem trabalhar em equipe. Apesar de resolver alguns problemas, como você falou, acaba criando vários outros…
August 6th, 2008 at 2:25 pm
@ Guilherme Chapiewski
Acho que você está se referindo ao segundo exemplo que eu citei para chegar onde eu queria. Caso esteja, pessoalmente também acho que é melhor que todos se esforcem a fazer item por item. Mas o ponto onde eu quis chegar é: para que se decida fazer o contrário disso e, generalizando, para que se mude qualquer outra regra, essa iniciativa de mudar tem que vir do time, desde que o time discuta a respeito e que o SM considere que o time já está maduro o suficiente para discutir e definir adaptações.
August 6th, 2008 at 3:56 pm
Anselmo, o que eu quero dizer é que o mais importante disso tudo não é o “como fazer a mudança”, mas sim o “porque fazer a mudança”.
As regras não podem ser modificadas assim tão livremente como vc falou. Sempre que se muda uma regra, é necesário ter um porque. É preciso ter plena consciência dos motivos da mudança e de quais problemas serão resolvidos, e também tomar cuidado para não quebrar os pilares básicos das metodologias ágeis.
[ ]s, gc
August 6th, 2008 at 4:03 pm
Olá Anselmo,
eu tendo a concordar com o GC, ao escolhermos deixar de lado algumas regras temos que saber, porque estamos fazendo isso. Nas metodologias ágeis a maioria das regras é extremamente solta, justamente para deixar margens para adaptação e deixar a burocracia de lado.
Mas neste exemplo, eu realmente nao vejo um bom motivo para não ter um bate-papo de NO MÃXIMO 15 minutos todos os dias. O que se ganha em troca de não ter os daily meetings? 15 minutos? Poder acordar mais tarde e chegar mais tarde? Esta segunda é simplesmente uma decisão do time de que horas eles preferem ter o Daily Scrum.
August 6th, 2008 at 9:28 pm
Concordo com ambos. Ao citar esses exemplos de mudanças minha intensão não foi condenar ou aprovar tais exemplos. Quis apenas ilustrar com exemplos reais mudanças que já ocorreram em times por aà a fora. []’s.
August 18th, 2008 at 6:41 pm
Your blog is interesting!
Keep up the good work!