Esta semana dei duas aulas sobre Scrum no MBA de Engenharia de Software da Escola Politécnica da UFRJ. Na segunda aula, formamos grupos que realizaram um projeto em sala de aula. Observando esses grupos pude perceber em pequena escala alguns erros e dúvidas comuns na execução do Scrum, que vou discutir aqui. 

Um erro que detectei rapidamente foi a falta de foco. É impossível ser ágil sem ter foco no produto que está sendo entregue. Tudo que não agrega valor ao produto está consumindo esforços em outra direção, logo está em desacordo com a agilidade. Isso se repete continuamente em vários projetos, quando a equipe tem que atender demandas que não são do projeto em que está. Praticamente todo método ágil exige que a equipe seja dedicada porque participar de mais de um projeto implica na perda do foco e do compromisso, dois dos valores básicos do Scrum.

Aliás, a dedicação do time e do ScrumMaster foi uma pergunta comum: quantos projetos um time pode fazer e quantos projetos um ScrumMaster pode “gerenciar”? Bem, sendo bem direto, se você quiser ser ágil, a resposta é um. No Scrum, o primeiro valor é compromisso. Como você pode ter compromisso com um projeto se tem que atender outro? 

Outro problema que detectei: o relacionamento ProductOwner-Time. Vamos deixar claro que  o ProductOwner é parte do projeto, é "porco" e não "galinha". Por isso ele deve também ser treinado e estimulado a participar ativamente. Se o ProductOwner diz no final de uma Sprint “Vocês não me entenderam” ele está se colocando  no papel do cliente tradicional, sem compromisso com o resultado. Eu espero que, havendo um erro, um ProductOwner fale “Nós não entendemos isso direito”. Mais ainda, eu espero que ele esteja todo o dia no projeto vendo o que está acontecendo e detectando os desvios antes da Reunião de Revisão. E também espero que o time não tome decisões que são do ProductOwner sem antes conversar com ele. Lembro que no Scrum não estamos falando de “sair fazendo”, mas sim de fazer em um ciclo curto tudo que é necessário para atender o ProductOwner, o que inclui atividades típicas de análise e validação. O ProductOwner é parte integrante do projeto e tem que estar disponível para o time. Ele tem que ser pró-ativo na defesa de seus interesses e não encontrar o time, jogar tudo na mão dele e vir cobrar duas semanas depois. Se isso não estiver acontecendo, quem deve buscar a correção é o ScrumMaster.

Falando no ScrumMaster, observando todos os grupos e analisando minhas experiências com Scrum também pude perceber como é difícil esse trabalho. Primeiro, é difícil de executar durante as cerimônias do Scrum. Servir de facilitador das reuniões, tornando elas mais produtivas, e evitar cair nas várias "funções de gerente", como designar tarefas e apontar culpados, é bastante difícil. No caso específico dos grupos em aula, era mais comum ver o ScrumMaster agindo como feitor do que ajudando a reunião a funcionar melhor. Se você é ScrumMaster, lembre-se que você trabalha para o time e não o inverso. 

Também era comum ver o ScrumMaster ajudar nas tarefas e não estar removendo impedimentos. O erro, nesse caso, é que o ScrumMaster não é um membro do time e tem uma função diferenciada, como o ProductOwner também tem. Se ele não tiver foco no seu trabalho, resolvendo impedimentos e melhorando a agilidade do time, está fazendo a coisa errada.  Enquanto a equipe está comprometida com entregar o produto combinado, o ScrumMaster está comprometido em tornar possível que a equipe cumpra seu objetivo.

Continuando com o ScrumMaster, termino o texto respondendo uma pergunta feita em sala de aula: o que o ScrumMaster faz quando não tiver nada para fazer, ele pode ajudar o time na programação?

A primeira parte da resposta é “e quando o ScrumMaster não tem nada para fazer?” O trabalho do ScrumMaster é ininterrupto, se as coisas estão indo mal, ele terá o que fazer, e quando as coisas estão indo bem, cabe a ele melhorar ainda mais. Em muitos projetos os ScrumMaster nem tem a capacidade técnica de ajudar a equipe. Tem gente, inclusive, que diz que não deve ter essa capacidade, e sim ser uma pessoa de outra área, mas afeita aos tipos de problemas que tem que cuidar, como as relações pessoais. Pessoalmente, eu entendo como o ScrumMaster pode, eventualmente, ajudar a resolver um problema técnico ou encontrar um bug, mas ele nunca deve se comprometer com uma tarefa, já que seu comprometimento é outro. Se ele “não tiver nada para fazer”, deve então sentar e tentar descobrir como melhorar a agilidade da equipe. Temos testes e checklists que nos ajudam a detectar problemas e indicar melhorias no Scrum, mas isso já é tema para outro post.

Lendo o que escrevi, percebi que todos os problemas citados e respostas tem relação com dois valores do Scrum: foco e compromisso. Proponho que a cada dúvida do Scrum nós devemos antes de tudo tentar respondê-las usando os valores. Comprometimento, foco, abertura, respeito e coragem trazem uma filosofia que nos permite entender porque algumas soluções nos levam ao "Great Scrum" e outras ao "Scrum Butt". Se você quiser saber mais sobre esse assunto, fique ligado no blog.