A estrutura tradicional para equipes de desenvolvimento de software é composta por um Gerente e um Grupo de Desenvolvedores. O Gerente têm três papeis principais:

1) Mediar com os stakeholders (diretores, clientes , outros gerentes) o que implica em definir prazos e custos e fazer com que se cumpram

2) Organizar o trabalho da equipa. Atribuir tarefas, etc…

3)Decidir quais features entram no projeto ou não com base nos dois itens anteriores.

Em Scrum não existem gerentes porque não existe ninguem com estas três responsabilidades. A razão para isso é que estas três responsabilidades competem entre si, ou seja, o Gerente não é capaz de atender todo o tempo a todas. Alguma será sacrificada e essa será a ferida que sangrará o projeto e o levará à morte. Scrum estabelece que o Foco é mais importante , portanto, uma pessoa só pode ter um foco por vez.  A organização da equipa Scrum é então um pouco diferente já que as três atribuições são divididas por três. A pessoa responsável por decidir as features que entram ou não no projeto – e em que ordem entram –  é chamada Dono do Produto (Product Owner).  O dono do produto também vigia o orçamento e o andamento do projeto já que ele detém a responsabilidade perante os stakeholders primários. Ou seja, as pessoas que estão pagando pelo projeto ou que pretender tirar dividendos do projeto. O grupo de desenvolvedores é responsável pela sua própria organização.  Porque no Scrum ha um foco muito claro sobre o que tem que ser feito e alcançado é mais simples e rápido que a equipe de desenvolvedores organize quem vai fazer o quê e como porque eles mais que ninguem conhecem os seus pontos fracos e fortes. Até aqui, apenas retirámos a responsabilidade de organizar a equipe do antigo gerente e o renomeámos Dono do Produto. Mas nem todos os stakeholers são primários. Muitas vezes é preciso o suporte de outras equipes , de outras areas da empresa (infraestrutura, limpeza, RH, etc…) para que o projeto chegue a bom porto. Então, embora o Dono do Produto controle tudo o que diz respeito ao produto, é preciso alguém que controle tudo o que diz respeito ao projeto. Esta pesssoa é chamada de Scrum Master. Podemos pensar no Scrum Master como um facilitador ou um mediador entre o Dono do Produto, a equipa de desenvolvedores e destes com o ambiente onde eles trabalham. Além disso o Scrum Master é responsável pelo cumprimento dos valores Scrum e de cobrar o comprometimento que foi feito tanto pelo Dono do Produto, como pelos membros da equipe , como por outras pessoas que participem direta ou indiretamente para o sucesso do projeto. Não é saudável pensar no Scrum Master como dono do projeto porque ele não toma decisões. Ele apenas ouve os problemas do Dono do Produto e da Equipa e os resolve.

Vejamos agora estes papeis de uma outra prespetiva.

No processo tradicional existem dois grupos de pessoas que o gerente administra delegando a elas algumas das suas funções mantendo-se ele apenas como organizador e mediador com os stakeholders. Estes dois grupos são normalmente chamados de “Funcional” e “Desenvolvimento”. A ideia é que o funcional irá mediar com clientes e peritos para modelar e especificar que features são necessárias serem incluidas no software. O desenvolvimento irá pegar essas especificações e produzir o software baseado nelas. O problema é que isto cria um triângulo amoroso e a parte que perde é normalmente o desenvolvimento.

O gerente delega ao funcional a comunicação com o cliente e os peritos, mas reserva para si uma espécie de voto de veto para ser aplicado sempre que os desejos dos clientes / peritos não forem computáveis no orçamento do projeto. Este mesmo veto é usado quando a equpe funcional, ou a de desenvolvimento ,sugerem uma melhoria. A melhoria é apenas avaliada em custo-tempo e descartada se exceder o orçamento ou o prazo. Isto cria três fontes de divida. 1) os desenvolvedores são forçados a introduzir débito tecnico e até alguma gambiarra para conseguir executar a demanda funcional no prazo e no custo. 2) o funcional não pode especificar um modelo melhor introduzindo um débito funcional sendo obrigado a demandar a implementação de um modelo que ele sabe não atender a todas as necessidades. 3) o gerente gera um débito de valor não entregando ao cliente aquilo que ele deseja. Dependendo do nivel de espectativa do cliente isso pode simplesmente fazer abortar o projeto. Se não por isso, quando o cliente descobrir que o modelo não o atende ou que para corrigi-lo é preciso mais tento que foi necessário para criar o sistema em primeiro lugar.

O scrum evita estes problemas dando ao dono do projeto a capacidade de representar e defender os interesses do cliente e do produto. Isto significa que o modelo poderá ser melhorado e até ser mais abrangente do que o cliente precisa, porque o Dono do Produto estará pensando que o Produto pode ser depois vendido para outro cliente que pagará por esse valor adicional. A equipa funcional tradicional se torna a equipe de produto que auxilia o Dono do Produto a desenhar as funcionaldiades e extrair delas o maior valor possivel para o cliente atual e para os outros que virão de forma a maximizar o retorno do investimento da empresa naquele produto. Coisas como análise de mercado, analise de concorrencia, analise de ROI, marketing e  especialista de dominio podem ser adicionadas à Equipe de Produto. A equipe não produz artefactos para os desenvolvedores mas para a empresa e clientes para que esteja documentado não apena as funcionalidades, mas o seu uso e o seu valor para o cliente ou potenciais clientes. As necessidades levantadas são organizadas e traduzidas para features do software. Estas features são então adicionadas em uma lista chamada Backlog. Com a ajuda dos desenvolvedores e o do Scrum Master são levantadas estimativas e riscos para cada uma das features e com base nessa informação o Dono do Produto decidirá a ordem em que elas serão implementadas. Isto vira um ciclo. A equipa de produto alimenta o Backlog, a equipa de desenvolvimento estima e avalia, o Dono do Produto prioriza,  a equipa de desenvolvimento implementa.

Durante a implementação é natural e necessário que todos se comuniquem para esclarecer duvidas e pontos ambiguos. Sempre que for encontrado um impedimento que está além das responsabilidades ou do comprometimento da equipa de produto, de desenvolvimento e do Dono do Produto, cabe ao Scrum Master intervir e resolver esse impedimento apelando e negociando com quem tiver que ser. O mais comum é ter que negociar com outras áreas como o Comercial e Infra.

Os diagramas acima mostram as interações entre os intervenientes no projeto e entre eles e o software. Note como na relação tradicional tudo depende de uma única pessoa:  o Gerente enquanto na realação Scrum, existem vários triangulos e as coisas não dependem de uma pessoa só, mas sim da colaboração de uma equipa.