O Product Owner prioriza constantemente esse Backlog do Produto, que é uma lista frequentemente revisada com as coisas que devem ser implementadas no produto. O PO deve ser apenas uma pessoa, e não um grupo. Além disso, ele precisa ter a autoridade exclusiva de mexer no Backlog, em especial a prioridade das coisas. Diretores, gerentes e até sócios devem negociar com esse papel se quiserem incluir novos itens ou alterar os existentes.
O Time de Desenvolvimento é um grupo pequeno (de 3 a 9 integrantes, segundo o Guia do Scrum) que contém (em essência) todas as competências e condições necessárias para criar e manter o produto sendo desenvolvido (leia sobre equipes multidisciplinares). Além disso, o Time de Desenvolvimento é auto-organizado: não existe um chefe responsável por gerenciar o trabalho (o Scrum Master também NÃO faz isso!).
Neste ponto vale ressaltar a diferença entre auto-organizado (self-organized), autodirecionado (self-directed) e autogerido (self-managed). No Scrum estamos falando de auto-organização, ou seja, autonomia completa para funcionar respeitando os acordos estabelecidos na organização e também às diretrizes do framework Scrum. Já a direção é definida pelo PO (considerando as perspectivas do time, naturalmente), e a gestão depende do modelo aplicado na organização.
No exemplo do nosso aplicativo de assinatura de receitas, provavelmente precisaríamos de pessoas com capacidade de desenvolver software, criar protótipos de interface, testar software, fazer pesquisas com usuário, etc. Todas essas competências devem estar presentes no Time de Desenvolvimento, em uma ou mais pessoas. Ou seja, provavelmente precisaríamos de um desenvolvedor, um designer e um testador. Obviamente, o time ser multidisciplinar não significa que todos devem saber tudo.
E aqui encontramos uma das maiores belezas que o movimento ágil e o Scrum trouxeram para as organizações que aplicam verdadeiramente seus princípios. Buscando atender a essa condição necessária para a entrega contínua de valor (conter todas as competências e condições necessárias para criar e manter o produto), os times e as organizações se colocam em uma situação verdadeira de melhoria contínua. Nesse contexto, é muito comum que os times descubram deficiências em suas capacidades e estruturas, e essas descobertas levem a sua evolução.
O Scrum Master suporta os demais (Time de Desenvolvimento e Product Owner) no entendimento e aplicação do Scrum. Ele facilita as cerimônias e ajuda o grupo como um todo a se auto-organizar. Ninguém nasce sabendo usar o Scrum, muito menos trabalhar de forma autogerida. É por isso que esse papel é tão importante, especialmente durante as etapas iniciais de adoção do framework.
O Scrum Master não é um chefe. Ele não “cobra as entregas” dos membros do time ou é responsável pelo sucesso do produto. O Scrum Master atua mais como um coach, que oferece o espelho nos momentos adequados e encoraja os membros do time a tratarem as suas próprias tensões entre eles e a dependerem menos do SM ou do PO.
O SM também atua expandindo o Scrum dentro da organização em que atua, ensinando outros times e departamentos a trabalharem com o framework. É comum também o SM auxiliar o Product Owner a melhor expressar os itens do Backlog do Produto (normalmente na forma de histórias de usuário).
Costuma-se dizer que existe um equilíbrio saudável das forças produzidas por esses 3 papéis neste grupo. Por um lado, o PO está constantemente procurando entregar “a coisa certa” (eficácia), ou seja, aquilo que os stakeholders, principalmente os usuários e clientes esperam do produto para considerá-lo valioso. Já o Time de Desenvolvimento tem a tendência em buscar a realização do trabalho “do jeito certo” (eficiência), preocupado com a qualidade do produto, dada a entropia natural de sistemas complexos. O Scrum Master, por sua vez, persegue a “rapidez”, nem tanto pela busca por produtividade e sim da redução do ciclo de feedback (validação da entrega de valor) junto aos stakeholders.