Jogue toda a documentação para o alto e comece a programar! Já é mais que fato que metodologias de desenvolvimento ágil funcionam. Se aplicadas corretamente e com comprometimento dos envolvidos, uma migração para tais metodologias trazem ganho de organização e desempenho inestimáveis (com o perdão do trocadilho) para os times. Ok, mas ainda mantenha sua documentação, ela ainda pode ser útil.

Agile Rules

Partindo de uma inviável waterfall ou de uma metodologia pastelaria, em que quem grita mais alto é atendido primeiro, o Scrum é a escolha óbvia para ingressar no mundo ágil. Principalmente pelo fato dele ser um framework relativamente simples. Os papeis e funções são bem definidos, assim como todas as cerimonias que ele propõe.

Abrindo um parêntese aqui. Apesar dos papeis e cerimonias bem definidos, nada impede de evolui-los de forma que seu time melhor os aproveite. A possibilidade de evoluir e se adaptar é um dos grandes benefícios da metodologia. Fecha parêntese.

Porém, não é simplesmente o desejo de utilizar a metodologia que faz com que sua aplicação seja realizada com sucesso. A mentalidade dos envolvidos deve mudar. E para isso, cada um deve estar completamente ciente do seu papel e do papel dos demais integrantes da equipe.

Muitas vezes os papeis se confundem e podem colocar o uso do Scrum por água abaixo. A sincronia deve existir. Um integrante que não faz o seu papel (e se ninguém mais do time se manifesta), pode colocar tudo a perder. Esse post é justamente uma coleção de exemplos de papeis que podem ser interpretados de forma equivocada. Se o seu time de Scrum não está indo muito bem, talvez se identifique com alguns pontos aqui levantados. A ideia é ter uma série de posts sobre tais papeis. Aqui trataremos apenas do PO. Então brace yourself. A long text is coming.

O PO é o responsável pelo backlog do produto. É ele que deve direcionar os rumos do produto e quem vai priorizar as atividades do time. Deve sempre ter em mente atividades que agregam valor e muitas vezes é um profissional sem skill técnico.

#O PO não é seu chefe

Um ponto chave é que o PO não é o chefe do time desenvolvimento. Muitas vezes, ele não está na hierarquia do time e vem de outras áreas. O PO deve gerenciar o produto, não o time. Ele não deve tentar impor soluções técnicas para o time. Ele define o que deve ser feito, enquanto o time deve definir toda a arquitetura do sistema. É saudável um PO com skill técnico discutir soluções com o time, mas a decisão técnica final cabe aos desenvolvedores, que mais do que nunca devem ser reconhecidos por sua capacidade de pensar e não de apenas codificar.

#O PO é o principal responsável pelo backlog

O PO deve ter total autonomia para definir o backlog e prioridades do time. Se o PO tem dificuldade em aplicar suas ideias, é facilmente influenciável ou não consegue aplicar suas convicções por interferência externa, ele dificilmente conseguirá levar o produto a um rumo esperado e terá muita dificuldade em alinhar as expectativas de todos os envolvidos com o produto. Não que o backlog é intocável pelos outros membros do time. Pelo contrário, estes devem ser propor melhorias no backlog e devem conhecê-lo tão bem quanto o PO. Mas a palavra final deve, sim, ficar com o PO.

#O PO não é o responsável por resolver impedimentos

Outro ponto é o time achar que impedimentos e empecilhos para que uma história seja desenvolvida devam ser resolvidos pelo PO. Gerenciando o backlog, o PO tem uma série de itens que ele quer que seja feito em determinada ordem. Ele vai falar para o time o que precisa ser feito. Se há pendencias de infraestrutura, layout, banco de dados ou qualquer outro item, não é o PO quem deve resolver os impedimentos. Tal responsabilidade é do Scrum Master, junto com o time de desenvolvimento.

Muitas vezes isso ocorre pelo fato de um Scrum Master não dar suporte suficiente ao PO, que acaba assumindo um papel mais ativo dentro do time e ambos os papeis acabam se confundindo.

Obviamente que um PO pró-ativo pode auxiliar o time nesses itens. Ele pode verificar com o time o que precisar ser feito para remover os impedimentos e auxiliá-los no que for possível. Mas tornar isso uma prática acaba sendo muito confortável para o Scrum Master, que é quem deve focar em resolver tais problemas. A questão aqui é separar bem os papeis. Ter um Scrum Master experiente e ciente do seu papel evita que tais situações ocorram.

#O Proxy PO nada mais é alguém que faz o trabalho que o PO não consegue fazer

Outro ponto importante a ser destacado é o papel do Proxy PO. Tal função normalmente é utilizada para suprir a ausência de POs distantes ou sobrecarregados. Sou contra a função. Acho que se trata de uma tentativa de resolver superficialmente um problema maior, que é o do PO não conseguir se dedicar integralmente ao time.

É aceitável ter um consultor técnico, desenvolvedor sênior, gerente de desenvolvimento ou analista de negócios para auxiliá-lo em dúvidas ou sugerir pontos de melhorias técnicas (embora todo o time deva fazer isso). Mas tal profissional deve ser tratado como alguém para auxiliar no processo. Utilizá-lo como Proxy PO fará com que o PO se distancie mais do time e do backlog. Se há necessidade de alguém para realizar tal papel, acredito que haja duas solução: (i) trocar o PO de função e deixar o Proxy como PO efetivo ou (ii) colocar o PO como um analista de negócios para auxiliar o PO oferendo mais detalhes das histórias. Mas ainda sim, o PO deve tomar todas as decisões e conhecer as histórias como a palma de sua mão.

#Clientes externos são péssimos POs

Há também muitas empresas que possuem clientes externos e utilizam o próprio cliente como PO. Sou a favor de tratar clientes externos como stakeholders, afinal, direta ou indiretamente, eles são os financiadores do projeto, mas minha opinião é que tratá-los como POs do time é uma péssima ideia.

O primeiro motivo é a falta de familiaridade com o processo. Ter que capacitar alguém externo para o papel é um investimento na pessoa errada. A pessoa não compartilhará as experiências que a função propõe e outros integrantes do time podem absorver pouco o que o PO tem a oferecer. Sem contar que você dependeria da disponibilidade e interesse do cliente. Muitas vezes ele não vai dar a mínima para qual processo o seu time utiliza, ele só quer ter o sistema pronto. O ideal é que o PO participe do dia a dia do time, estando sempre disponível para tirar dúvidas e auxiliar o time caso elas surjam.

O segundo motivo é que você pode acabar engessando o processo utilizando alguém externo como PO. Uma eventual mudança no processo poderia se tornar tortuosa caso o PO não tenha uma relação diária com o time, o que dificultaria bastante essa alteração. Ele pode não ver os problemas do dia a dia da forma que o restante do time vê e pode ter dificuldade de absorver novos processos adotados pelo time. Sem contar que uma troca de profissional, caso o PO não faça um bom trabalho, é impossível.

Sumarizando, o PO possui papel crucial no Scrum, especialmente no que diz respeito a entregar valor ao produto. É importante que ele seja alguém focado no produto e tenha suas funções claras para todos os membros do time de desenvolvimento. A função pode ser um grande aprendizado para quem a ocupa e errar faz parte desse aprendizado. Mas é importante que tais erros sejam corrigidos assim que percebidos para que o time explore todo o seu potencial.