Por que foram criados papéis nos frameworks de Agilidade?
Quando as organizações decidem adotar um framework ágil de desenvolvimento de software, é comum saltarem logo para o tópico “Papéis e Responsabilidades”. Esta é uma seção quase onipresente na maioria dos frameworks — e hoje em dia temos visto até mesmo vagas de emprego citando abertamente qual é o papel a ser assumido.
“Valores, Princípios e Teorias? Hmm, não sei… Talvez outro dia! Agora, conte-me mais sobre esse tal de Scrum Master.”
Mas será que entendemos primeiramente o porquê desses papéis terem sido criados? Estamos fazendo escolhas conscientes sobre quais problemas estamos atacando?
Gestão de Projetos x Papéis
Vamos pegar como exemplo aquele framework que está mais na boca do povo, o queridinho das Transformações Digitais. Sim… ele mesmo: o Scrum.
No Guia do Scrum, um time é composto pelo Scrum Master, Product Owner e Development Team.
Todos esses papéis compartilham responsabilidades sobre a gestão dos projetos do time. De forma bem rasa e simplista: o Scrum Master lidando com o processo de entrega e evangelizando o time em como adotar as práticas do Scrum; o Product Owner centralizando os aspectos do negócio, seus objetivos e expectativas; e o Dev Team planejando e viabilizando os objetivos de negócios através do seu trabalho.
Mas… e o Gerente de Projetos?!?! Por que redesignar suas atribuições em papéis separados? Tenho algumas hipóteses.
Minha visão sobre o assunto
Limite do Potencial Cognitivo
Existe uma sobrecarga no papel tradicional do Gerente de Projetos, ou seja, precisamos dividir para conquistar. Se quisermos mais foco das pessoas, precisamos redistribuir essas responsabilidades em mais de um papel.
Colaboração (ou 1 + 1 > 2)
“ O todo é maior que a soma das partes” — Aristóteles, em sua obra “Metafísica”. Ou pode ter sido Clarice Lispector que escreveu isso, ou Arnaldo Jabor… não sei!
Este é outro ponto muito válido. Ao colocar diferentes pessoas, teremos diferentes insights sobre o projeto em si. E este fato por si só já agrega um valor que não seria alcançado com uma pessoa centralizando as responsabilidades pelo projeto. Os papéis interagem de forma a refletir sobre o produto do seu trabalho, seu processo de trabalho, e aprendem sobre como podem melhorá-los.
A forma com que interagem faz com que o time funcione como um sistema que possui em si a capacidade de Gestão de Projetos. Mas segura essa ideia, porque vou falar sobre isso logo!
Comprometimento
Com as responsabilidades sobre a Gestão de Projetos distribuídas, damos uma perspectiva mais objetiva — e concisa — sobre como cada um pode (e deve) contribuir para o seu sucesso. Isso reduz o efeito de apenas se ver envolvido e não comprometido com o Projeto, mas não garante a colaboração. O Scrum traz o aspecto Colaborativo, ao responsabilizar o time todo por suas entregas. Ou seja, se o projeto for um sucesso ou uma catástrofe, a responsabilidade é do time todo. Sim, do time TODO.
Paradigma Prescritivo vs. Auto-organização
Tem um ponto mais sutil na descrição dos papéis especificamente do Scrum: as responsabilidades estão descritas em alto nível — e são bastante sucintas. Isso dá uma grande liberdade para as pessoas encontrarem seu próprio modus operandi e, ao mesmo tempo, dá um norte muito claro a cada papel.
Autonomia + Alinhamento = Auto-organização
É uma mudança grande de paradigma: do altamente prescritivo, para o interpretativo.
De: “Vou fazer o planejamento do cronograma do projeto porque esta responsabilidade está declarada em um documento.”
Para: “Vamos realizar o planejamento da sprint conforme os aprendizados do time, porque acreditamos (e entendemos) como esta prática nos auxilia a cumprir os objetivos do projeto e do produto.”
Desdobramentos
De “responsabilidades” para “accountabilities”
Na minha experiência, quando tentamos trazer mais clareza sobre esses papéis, existe a tentação de descrevê-los detalhadamente e isso é um problema. É utilizar uma abordagem Reducionista para tentar resolver um problema Complexo.
Quando encontramos descrições extensas dos papéis, com 5W2H, SIPOC, matriz RACI, ou qualquer outra ferramenta que tente abarcar todo tipo de situação e responsabilidade eventual dos papéis do framework ágil sendo adotado, é um sinal desse problema.
Minha recomendação: fuja dessa abordagem!
É impossível prever e prescrever o trabalho de todas as pessoas nesses papéis. Seja numa organização grande ou pequena.
É danoso também para as pessoas que assumirão esses papéis continuar nesse paradigma Reducionista, pois inibe a auto-organização dos times. Frequentemente, vão questionar se o que estão fazendo está “dentro da lei”. E até descobrirem, já se passou tempo demais! E aí: “Adeus, agilidade!” :’-(
Melhor é dar um passo em direção a um paradigma mais interpretativo, como chamo, através de accountabilities.
Coloquei o termo em inglês mesmo, porque não encontrei uma tradução apropriada. Se refere à responsabilidade por qual alguém presta contas. Podemos delegar atividades, porém a accountability não pode ser delegada.
No paradigma prescritivo, uma responsabilidade é de um papel que é desempenhada pela pessoa, e fim de conversa. A abordagem de accountabilities dá margem maior para a auto-organização.
A forma dessa accountability deve se aproximar da forma com que o Scrum guide descreve seus papéis. Veja o exemplo de trechos da descrição do papel de Product Owner, do Scrum Guide:
“ The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team”.
(…)
“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.” — Scrum Guide
Em tradução livre: “O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Dev Team.”
(…)
“O Product Owner pode fazer o trabalho acima, ou ter o Dev Team para fazê-lo. Entretanto, o Product Owner permanece accountable.”
Capacidades Sistêmicas
Entendo que os papéis são uma base inicial para criar um sistema adaptativo e evolutivo que tenha as capacidades necessárias para cumprir seu propósito: gestão de projetos; aprendizado contínuo; entrega contínua; colaboração; qualidade nas implantações; previsibilidade; venda de soluções etc.
Isto posto, abrimos precedentes para criar times que futuramente não tenham descrição alguma de papéis ou vestígios de frameworks ágeis, pois mantiveram suas capacidades instaladas por outras formas mais apropriadas pelo contexto do time.
Quais cores o seu quadro precisa? Que capacidades seu time vai precisar?
Recapitulando…
Gestão de Projetos: garantida pela interação entre os papéis.
Hipóteses sobre motivadores para papéis:
- Potencial Cognitivo: dividir responsabilidades com mais pessoas para não sobrecarregar a cabeça de ninguém.
- Colaboração: a interação entre as pessoas que seguem os frameworks faz com que o resultado de seus projetos seja melhor.
- Comprometimento: todos compreendem como podem contribuir com seu papel no time e se motivam mais com isso.
- Paradigma Prescritivo vs. Auto-organização: não mate a auto-organização, por favor!
Desdobramentos
- De “Responsabilidades” para “Accountabilities”: um passo para menos prescrição e mais auto-organização.
- Capacidades Sistêmicas: os frameworks somem conforme o sistema evolui e se adapta.
P.S.: Leia este artigo como um convite para a discussão. Essas ideias partem da minha experiência e perspectiva, e portanto, são falíveis e incompletas. A resposta certa pouco importa. Mais vale é elevar o nível da discussão. ;-)
O que você pensa a respeito? Deixe seus comentários, que serão apreciados!
