Por que os papéis de Scrum devem ser valorizados?

Quando Ken Schwaber e Jeff Sutherland desenvolveram o Scrum nos anos 90, eles procuravam ajudar empresas de médio e grande porte com problemas de legado e escala – problemas que as companhias, de modo geral, ainda enfrentam hoje, diga-se de passagem. Ao ler o Guia Scrum, é possível notar algumas coisas. Não há gerentes de projeto, pois o Scrum trabalha com desenvolvimento de produtos em um modelo diferente. Nota-se também que os stakeholders são mencionados, mas não possuem um papel relevante desenvolvendo o produto, e têm como responsabilidade passar as especificações para os Product Owner e depois um feedback na Review.

Não existem estruturas complicadas de gestão fora da equipe, mas os stakeholders podem ser internos ou externos à organização. Não há gerentes de produto ou business owners no Scrum. O Product Owner é aquele que faz tudo o que essas posições desempenham em outros contextos não-Scrum. O Guia Scrum diz claramente: “Para que o Product Owner tenha sucesso, toda a organização deve respeitar suas decisões.” É de fato um papel muito sênior e muito influente. Eles são os principais responsáveis pelas decisões relacionadas ao produto, e a principal forma para garantir o sucesso financeiro do produto é possuir o Backlog de produtos. É preciso ter em mente que cada produto tem apenas um product owner, que é mais orientado a negócios do que a parte técnica.

O Scrum Master também deve ser igualmente empoderado e habilitado. Fazendo um paralelo com abordagens não-Scrum, o scrum master precisa ser percebido pela organização como sendo pelo menos um equivalente de um gerente de projeto. No entanto, esta senioridade é expressa de forma muito diferente quando comparada com os gestores tradicionais. Eles aderem fortemente a uma noção conhecida como servant leadership, uma liderança onde, para tornar-se “líder”, primeiro deve-se “servir”. O scrum master precisa servir, ou seja, atender a três partes diferentes: o Time de Desenvolvimento, o product owner e a organização. A fim de fornecer esses serviços, eles precisam ser capacitados pela organização para fazer isso. Eles precisam ser vistos como a principal pessoa de contato em uma posição de gerenciamento relacionado na equipe. Em se tratando de questões relacionadas à tomada de decisões de processos ou o sistema no qual a equipe trabalha, não pode haver ninguém “acima” do Scrum Master. Estas decisões só podem ser tomadas pelo Scrum Team com o apoio do Scrum Master. Essencialmente, o Scrum Master deve estar envolvido em todas as atividades que não são explicitamente do Product Owner ou da Equipe de Desenvolvimento.

Assim como trabalho do Product Owner é dificultado caso haja alguma distância ou algum tipo de barreira entre ele e os verdadeiros stakeholders (neste caso nos referimos aos usuários finais reais, ao invés de um grupo de gerenciamento de produtos, por exemplo), o Scrum Master depende ainda mais dos contatos e relacionamentos que desenvolve com outras pessoas da organização, em diferentes departamentos e diferentes níveis. Se houver reuniões relacionadas ao processo ou ao sistema de desenvolvimento que afetem a equipe, o Scrum Master precisa estar lá. Isto inclui discussões relacionadas ao orçamento (uma boa abordagem é fazer com que o PO seja responsável pela entrada de dinheiro, pois ele é responsável ​​por maximizar o ROI, já o Scrum Master é responsável pelo monitoramento de custos), contratos, estratégias de preços, contratação e Políticas de RH em geral, o que é prioritário no portfólio geral (que também pode envolver o PO) e qualquer coisa relacionada à cultura da organização. Tudo isso é feito de forma diferente quando uma organização decide adotar o desenvolvimento Agile, por isso o Scrum Master fica ‘incapacitado’ quando ele não está envolvido nesses níveis. A equipe não desenvolverá uma ‘auto-organização’ ou até mesmo a capacidade de melhorar fica comprometida. Se o Scrum Master for impedido de executar as tarefas mencionadas acima dentro da organização, então esta não verá as vantagens esperadas do Agile.

Um colega me perguntou recentemente se eu poderia descrever o papel do PO. Ele tinha feito o curso CSPO e passado no teste, mas não tinha tido muita experiência em projetos Agile. Normalmente, seria de se esperar que a definição do Guia de Scrum fosse mais ou menos o que ele poderia esperar, e penso que, na maioria das vezes, é. No entanto, realmente existe muitas variações em como os papéis do Scrum realmente são desempenhados. Alguns são legítimos, outros não. Porém, é preciso considerar e comparar o contexto imaginado pelos autores do Guia Scrum com o contexto encontrado na empresa usando Scrum.

Algumas empresas afirmam ser diferentes ou especiais, e por isso acham necessário tomar medidas que, deliberadamente ou inadvertidamente, enfraquecem os papéis de PO ou SM. Por exemplo, eu expliquei ao colega mencionado acima que, no cliente no qual ele iria trabalhar, muito provavelmente seu papel seria bem diferente da descrição encontrada no Guia Scrum. Na maioria das vezes, um Produto Owner irá se juntar a um “projeto” já iniciado e descobre que seu papel já está sendo desempenhado. Outra pessoa, possivelmente um product manager ou business owner, já desenvolveu uma visão de produto, e quantidades significativas de documentação já podem existir, incluindo screen shots. A única coisa que resta a ser feita é escrever o produto como código-fonte pelos programadores. Mas como a empresa escolheu Scrum, eles precisam de um PO, e sua principal tarefa será a de converter essa documentação em “User Stories” e colocá-los em alguma ferramenta como o Jira. Mesmo a prioridade das funcionalidades provavelmente já está decidida. E isto é completo desperdício.

Neste contexto, é tarde demais para o Product Owner, User Stories e até o próprio Scrum. Scrum seria relevante para aqueles que escreveram a documentação do projeto; o grupo que realmente desenvolveu o produto. Na verdade, eles deveriam ter economizado esse esforço e colocado essas pessoas na mesma equipe multifuncional que os desenvolvedores, como previsto pelo Scrum e Agile, para transformar diretamente em software sem a necessidade de escrever toda essa documentação de projeto! Também é tarde demais para User Stories. As User Stories teriam sido relevantes na visão e na criação desta documentação de projeto. Transformar esta documentação em user stories, em última análise, é praticamente jogar fora informações ou retroceder alguns passos. Os desenvolvedores devem trabalhar diretamente em cima desta documentação, se ela já existir; convertê-las em user stories não traz nenhum valor extra. Mesmo Scrum em si é muito tarde neste contexto. O produto já está desenvolvido. Os desenvolvedores devem apenas escrevê-lo, funcionalidade após funcionalidade.

E são essas organizações as mais susceptíveis a criar funções como gerente de projeto ou “IT-PO” na equipe, para lidar com, por exemplo: processo de ponta a ponta, conformidade e governança ou controle de custos. Esses papéis serão vistos como os principais papéis de gestão, com o qual as pessoas de fora da equipe irão interagir, deixando o Scrum Master de lado e relegando seu papel a uma espécie de assistente de equipe, conhecido por basicamente organizar as reuniões.

O Scrum é projetado para esforços de desenvolvimento de produtos complexos e altamente criativos, envolvendo pessoas técnicas e business-oriented. É por isso que você precisa de Product Owners e Scrum Masters altamente capacitados e empoderados. Mas se você não estiver empregando o Scrum tal qual pretendido e descrito nos parágrafos anteriores, então você não precisa realmente dos papeis, nem do Scrum. Todas as etapas complicadas e criativas já foram feitas!

Para ser justo, acho que a comunidade Scrum pode ter subestimado as habilidades que os Scrum Masters realmente precisam para realizar seus trabalhos adequadamente. Percebo que muitos deles se intimidam diante das discussões financeiras, ou sentem-se desconfortáveis ao lidar com pessoas que não são de TI, especialmente gerentes. Às vezes, os próprios Scrum Masters estão muito concentrados nas diretrizes básicas do Scrum Guide e/ou pensam que seu papel não vai muito além do que planejar reuniões, e ter discussões sem fim com os programadores sobre valores e princípios utilizando post-its, ou fazer dinâmicas com Lego. Não me interpretem mal, todas essas tarefas são do Scrum Master e são sim, muito importantes.

Com certeza há o momento certo para essas tarefas de coaching ‘team-oriented’, mas acho que os Scrum Masters devem, em geral, gerenciar melhor quando tais atividades e o quanto dela, são apropriadas. Acho que essa é uma das razões pelas quais as empresas podem perder a confiança nos Scrum Masters e achar que é necessário inventar estruturas estranhas e papéis extras para executar as tarefas que os Scrum Masters tendem a evitar. Essa tentação tem de ser combatida, já que a organização não verá muitos benefícios do Agile ou Scrum, caso esses dois papéis críticos continuem sem poder – e a equipe nunca irá alcançar a auto-organização.