Quando comecei a estudar Scrum em 2010 havia pouco tempo que a primeira versão do Scrum Guide havia sido lançado e o professor que me treinou era o segundo da América Latina autorizado pela Scrum.org. Ainda guardo o material do treinamento e nele tem a fábula do Porco e da Galinha, que mais tarde em 2011 seria removida dos materiais oficiais do Scrum (ao que parece isso estava criando algumas disfunções).
Se você não conhece a fábula, dê uma olhada na tirinha abaixo.
Nela, a galinha convida o porco para abrir um restaurante, que se chamaria “Pernil com Ovos” (eu prefiro usar bacon no lugar). O porco recusa pois neste caso ele estaria comprometido com o projeto enquanto a galinha estaria apenas envolvida (afinal o porco se sacrifica, enquanto a galinha põe o ovo e sai fora).
Esta fábula era muito usada para designar não apenas comprometimento literal, mas responsabilidade sobre determinado assunto ou aspecto do processo de desenvolvimento de software com Scrum. Claro que todos os envolvidos no projeto são responsáveis em maior ou menor grau pelo sucesso do mesmo e justamente por isso em Inglês não se usava nessas situações a palavra responsible mas sim accountable. Você sabe a diferença?
Basicamente a responsibility (responsabilidade) pode ser compartilhada, enquanto que a accountability (responsabilidade também, mas em um sentido de prestar contas) não. Logo, se você é accountable em algum aspecto do projeto, você está commited (comprometido) com o mesmo em altíssimo grau e seu bacon está em jogo!
No Scrum, em diversos momentos ou sob diversos aspectos temos diferentes porcos e galinhas. Como vejo que muitas vezes os times se atrapalham com isso e são questões que caem em prova de certificação, resolvi montar uma espécie de matriz RACI com diversos elementos presentes no Scrum Guide.
Como eu considero o conceito de porcos e galinhas muito mais lúdico e divertido do que o conceito oficial pra matriz de responsabilidades, vou usar apenas as letras P e G ao invés das quatro originais (R, A, C e I).
Note que a matriz foi construída usando única e exclusivamente o conteúdo presente no Scrum Guide. Interpretações à parte, cada time acaba encontrando a sua maneira de trabalhar, mas como queria uma representação fiel ao Scrum Guide, construí ela dessa maneira. Caso busque uma abordagem mais emergente e colaborativa com seu time, você pode usar a dinâmica do “É/Não É/Faz/Não Faz” do Rafael Sabbagh, que explico no artigo sobre Lean Inception ou a variante do Andy Barbosa: “É/Não É/Faz/Não Faz/Pode/Não Pode”.
Como o primeiro pilar do Scrum é a transparência, nada mais justo de que o papel, os direitos e os deveres de cada membro do time esteja explícitos e que, cada um fazendo a sua parte como esperado, todos chegaremos no sucesso desejado.
Logo mais abaixo, as matrizes e suas interpretações.
Ah, mas se você ainda não domina os papéis do Scrum, recomendo dar uma olhada no vídeo abaixo primeiro.
Cerimônias
A matriz PG (Porcos e Galinhas) das cerimônias do Scrum fica assim.
Eu dividi a planning em duas partes, assim como citado no guide, uma vez que na primeira parte o PO é o elemento central, trazendo os inputs que são os itens do Product Backlog priorizados. Na segunda parte, o porco vira o Dev Team, que tem de definir o que cabe na sprint e como pretende desenvolver cada um dos itens. É citado no guide que stakeholders ou consultores podem aparecer, caso necessário, para serem ouvidos (ou seja, galinhas).
A Daily Scrum, ao contrário da crença popular é uma cerimônia para o time de desenvolvimento se sincronizar, comparando sempre com o Sprint Goal. Outros participantes, se aparecerem, não devem bagunçar a cerimônia e esse é um conceito que muitas vezes cai na prova de certificação. O SM deve garantir que ela aconteça e que não exceda os 15 minutos, uma vez que isso esteja ok, ele é dispensável.
A Review é o Dev Team apresentando o Incremento para o Product Owner e stakeholders (idealmente). Eu adoraria colocar os stakeholders como porcos aqui, para lhes dar mais responsabilidades, mas entende-se no Scrum que somente membros do time Scrum são porcos.
E por fim, a Retrospectiva é de responsabilidade do time Scrum como um todo. Se eu tivesse que elencar um responsável eu colocaria na conta do Scrum Master, mas o guide sugere diferente, dizendo que ele deve ser tratado como um “peer member” nesta cerimônia.
Note que, ao contrário do que muitos acham, o Scrum Master não é o porco das cerimônias, ele é apenas o facilitador, devendo garantir que as mesmas aconteçam e sejam produtivas, para o bem do próprio time e não para benefício próprio.
Artefatos
A matriz PG dos artefatos do Scrum fica assim.
Aqui temos um assunto bem menos polêmico e menos complicado também. O PO é dono do Product Backlog e somente ele mete a mão lá (inclusive os stakeholders ficam de fora dessa gestão, embora opinem). Já quando pegamos uma fatia do PB, o Dev Team constrói e mantém o Sprint Backlog durante toda a vida da sprint, gerando na sequência o Incremento, DONE conforme a Definition of Done, também de sua autoria.
O Scrum Master “apenas” garante que tudo isso seja seguido e ensina boas práticas e técnicas, especialmente para o P.O. conseguir lidar com o backlog de forma eficiente.
Outros Aspectos
Como as duas matrizes anteriores não lidam com todos os pormenores do Scrum no que tange responsabilidades, fiz mais uma envolvendo outros aspectos do framework que devem ajudar no dia a dia de quem é novato no assunto.
Aqui temos o reforço de alguns conceitos como o P.O. sendo o porco das prioridades e do ROI do produto que está sendo desenvolvido, mas traz aspectos menos conhecidos como o fato dele ser a única pessoa que pode cancelar uma sprint, no caso do Sprint Goal se tornar obsoleto. Goal esse definido pelo Time Scrum durante a Sprint Planning.
Para o Scrum Master vêm as responsabilidades clássicas como facilitar cerimônias, ensinar e melhorar continuamente o processo e remover impedimentos que possam estar atrapalhando a performance do time. Este último, um tanto polêmico em alguns times, envolve a fina arte de equilibrar o aspecto “facilitador” do aspecto “babá” que alguns times acabam se acostumando. E sim, o Scrum Master é o “servant leader” do time Scrum e ele é o único papel mencionado como líder (não confundir com gestor).
E por fim, o Dev Team se auto organiza (dividindo e distribuindo suas atividades) bem como decide como transformará os itens do backlog em um incremento de software através de técnicas de UX e Engenharia de Software disponíveis no mercado e que um bom time multifuncional deve ter entre seus membros.
Espero ter ajudado!
* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.