No último dia 20 de junho, realizamos no Rio de Janeiro o 2º Scrum Masters on Beer e, dessa vez, falamos sobre os papéis, ritos e boas práticas do Scrum. Foi um bate-papo bem descontraído com cerveja, pizza, dinâmica e muito debate.

Durante todo o evento, estimulamos que dúvidas, pontos de observação etc. poderiam ser levantados a qualquer momento. Com isso, percebemos que muito do que foi ressaltado são informações/ideias passadas de forma errada para as pessoas sobre o Scrum. Neste artigo, o objetivo é explicar algumas delas.

Refinamento

A reunião de Refinamento não faz parte dos ritos oficiais do framework Scrum. Ela existe para que o Product Owner e o time de desenvolvimento entendam mais cedo sobre as próximas histórias, otimizando o tempo da Planning. Sendo assim, ela não precisa necessariamente ter um dia certo para acontecer e nem horário.

A Planning é um rito que tem um time-box de 8 horas para um mês de Sprint. Esse time-box se dá pela necessidade de entender e detalhar os itens de backlog. O refinamento faz com que esse rito seja mais produtivo e leve menos tempo, pois já haverá um entendimento sobre os próximos itens.

Quem diz que uma discussão não está sendo produtiva?

Apesar de existir a ideia de que o Scrum Master é o responsável pelos ritos por ser o guardião do Scrum, ele não é o único que deve se preocupar com isso. Todo o Time Scrum é responsável pelos eventos.

Pode existir, por exemplo, uma Daily na qual o time de desenvolvimento não deseja a presença do Scrum Master e, nesse caso, o próprio time é responsável por deixar o rito fluir, manter o time-box e o foco.

É o cliente quem prioriza o Product Backlog?

Não. Independente de quem seja, o stakeholder (investidor, usuário) expressa a sua necessidade, que um produto ou serviço ajudam a resolver. O Product Owner pode ser influenciado por outras pessoas, mas somente ele tem gerência sobre o Product Backlog, que pode ser priorizado por outra pessoa, caso o PO permita.

Os itens levados ao time podem resultar em um protótipo que será levado aos stakeholders afetados diretamente pelo problema para receber feedbacks ou podem ser desenvolvidos diretamente.

É comum ter pessoas ociosas durante alguma sprint?

É difícil ter pessoas que não tenham alguma tarefa para fazer durante uma sprint. Porém, se isso acontecer, há diversas coisas que as pessoas ociosas podem fazer para ajudar ao time: estudar as próximas features, fazer pair programming, estudar para melhorar suas habilidades, começar a fazer a próxima história, ou até mesmo pegar café. O importante é a colaboração no time.

O time pode mudar durante as sprints?

Esse caso não é impossível; às vezes uma pessoa não se sente bem, pode ter alguém saindo da empresa etc. Porém, não é recomendado. Um time é formado para atender a necessidade do produto e mudanças de pessoas podem causar a redução da velocidade pela curva de aprendizado e dar um passo atrás na formação do time.

Quando um Product Owner acha que pode tudo, o que fazer?

Qualquer coisa que alguém do time, independente de papel, cargo, idade ou posição diga que cause um desconforto, ou seja agressivo, precisa ser endereçado, de preferência no momento. Caso não seja possível, deverá ser tratado na retrospectiva. As pessoas podem cometer erros dentro do Time Scrum, inclusive o Scrum Master e, nesse caso, em que o Product Owner “se acha”, o membro do time pode falar diretamente com ele ou pedir ajuda ao Scrum Master.

Alguém pode acumular papéis?

Não. Acumular papéis é como ter um dragão de duas cabeças: uma vai engolir a outra em algum momento.

O papel de Scrum Master é totalmente oposto ao de Product Owner, assim como do time de desenvolvimento. Cada um deve desempenhar apenas um papel dentro do Time Scrum.

O Product Owner pode ser o cliente?

Não é o ideal, se o cliente for externo ao Time Scrum. Em algum momento, ele deve conhecer as técnicas de priorização e negócio. O Product Owner em algum momento deve conhecer mais sobre o negócio que o próprio cliente. O Product Owner vai traduzir a necessidade do stakeholder em histórias para o produto.

O Scrum Master precisa ser um líder?

A premissa do papel de Scrum Master é ser um líder servidor.

“O Scrum Master é um líder servidor para o Time Scrum. O Scrum Master ajuda quem está de fora do Time Scrum a entender quais interações com o Time ajudam e as que não são” – Scrum Guide, 2016.

Como lidar com itens de backlog não entregues?

Em casos nos quais itens que o time previu que ia entregar, mas não foram realizados, voltam ao Product Backlog para serem priorizados novamente pelo Product Owner, podendo entrar, ou não, na próxima Sprint.

Esses itens não são estimados novamente, apenas podem receber uma nova ordem de prioridade.

Palestras e cursos sobre ágil e Scrum podem envolver o cliente?

Elas devem. Muitas vezes o Stakeholder não tem o mindset ágil e, sabendo que isso é difícil de mudar, motivá-los a participar e aprender pode ajudar muito ao time no futuro.

Tem alguma outra dúvida ou discorda de algum ponto? Use o campo abaixo para comentar. Até a próxima.

***

Artigo originalmente publicado em: https://www.concrete.com.br/2017/07/12/o-que-nao-devemos-fazer-scrum/