E ai, você conhece todos os papéis da agilidade e suas responsabilidades, ou pelo menos sabe da existência da maioria deles e suas principais diferenças? Atualmente os mais conhecidos do mercado são o Scrum Master, Product Owner e o Developer, porém temos também o Agile Master, Kanban Master, Product Manager, Business Owner, e em alguns casos o Head de Produto e o Head de Agilidade, sem falar é claro em papéis herdados do tradicional como o Tech Leader, Analista de Negócio e o Gerente Ágil de Projetos, e respirando um pouquinho, ufa, temos o famoso Agile Coach, que pode ser derivado em Agile Coach Operacional, Estratégico ou Enterprise, e por fim o Agile Expert.
É muito papel não acha? Eu acho também, por isso resolvi escrever este artigo para explicar um pouco quais cenários você pode encontrar estes papéis, quando faz sentido tê-los em um mesmo ambiente, quais são as responsabilidades de cada um, e principalmente os cuidados para não ter over head e muito menos um conflito de papéis e responsabilidades na sua organização.
Mundo Ideal versus Mundo Real
Bom, para começar quero dizer que não concordo com a existência e necessidade de ter todos estes papéis em ambientes ágeis ou híbridos, porém, o ponto nada tem a ver com concordar ou discordar, tem muito mais a ver com o que o próprio mercado de forma orgânica foi criando e institucionalizando, e nós profissionais, consultores e especialistas precisamos minimamente conhecer, entender as diferenças que o próprio mercado e as empresas estão colocando para os papéis e contribuir para o melhor funcionamento possível para estas engrenagens, por mais malucas e confusas que estas engrenagens possam parecer, ok?
Eu também não gosto muito da frase mundo real versus mundo ideal, ou no mundo real é diferente, esta é uma frase usada muitas vezes por acomodados e resistentes a mudança que não querem mudar a realidade péssima em que vivem, jogando a culpa nos outros e em uma suposta realidade que não o deixa fazer diferente, mas que na maioria dos casos é a própria pessoa resistente que não quer mudar e usa estas frases prontas de autoajuda barata.
Neste caso, ocorreu sim um ajuste entre o que alguns métodos ou frameworks trouxeram como ideal e as empresas têm conseguido aplicar devido a suas culturas, burocracias e problemas ainda não resolvidos em suas estruturas organizacionais. No entanto, ainda prefiro afirmar o que eu acredito, não era, e não são necessários todos estes papéis para que uma empresa tenha resultados positivos e saudáveis, e que busque e atinja uma Agilidade de Negócios satisfatória, ok? Com isso vamos falar de cada um deles e ver quais faz sentido ter na sua organização ou até se você tem algum papel sobrando na sua estrutura.
Papéis do Scrum
Decidi começar pelos papéis do Scrum que acredito serem os mais conhecidos pela maioria das pessoas, e porque a partir destes papéis podemos ir conectando os demais. Até porque na minha opinião vários outros papéis foram derivados dos papéis do Scrum devido a restrições organizacionais ou problemas que foram intitulados de difíceis de resolver.
Bom temos o Scrum Master, também conhecido como SM, que é o papel responsável por gerenciar os processos do Scrum e por garantir que o fluxo, regras, papéis, cerimônias e artefatos do Scrum sejam aplicados de forma correta e por ser o principal responsável pela performance do time, pelo incentivo e promoção de melhorias no time.
O Scrum foi o framework que introduziu o papel do Product Owner no mercado, também conhecido informalmente como Dono do Produto ou simplesmente PO. O PO é o principal responsável pelo entendimento das necessidades do cliente e do produto que gerencia, isso mesmo, o PO deveria gerenciar o seu produto no que diz respeito a backlog de construção, lançamentos, evoluções, correções e especialmente os investimentos e retornos que o Produto traz para a sua empresa e para seus clientes, priorizando, selecionando e descartando itens de backlog para o seu produto.
O PO pode escrever histórias ou delegar a escrita para outros papéis de apoio, assim como conversas com os clientes e usuários finais, além da execução de testes e validação do funcionamento do produto. Um ponto fundamental para o sucesso de um PO, é que a pessoa que exerce este papel deveria ficar junto aos desenvolvedores e não estar em uma área de negócio, e muito menos ser um gestor que tem outras responsabilidades e outros focos e não tem tempo para se dedicar ao seu produto.
Muitos me perguntam: Fábio, o PO deveria ser da área de negócio ou da TI? Eu sempre digo, de verdade? De nenhum dos dois! O PO deve ser do produto e estar no time de produto, se você tem um time de negócio e um time de TI para um mesmo produto, você tem problemas de estrutura e não trabalha nem de perto de forma produtizada e terá problemas. Veja meu artigo e vídeo sobre Produtização, vou deixar o link no final deste artigo para você conferir.
Por fim temos os desenvolvedores, que são os especialistas técnicos responsáveis por construir o produto físico, virtual ou digital. São os profissionais que tem conhecimento e capacidade de entender e transformar o backlog do produto em um produto que possa ser utilizado pelo cliente e usuários finais. Para o Scrum não existe diferenciação de funções, responsabilidades e nem mesmo sub-papéis no grupo de desenvolvedores, esta é uma forma de fazer com que todos se sintam parte de uma equipe única e para contribuir e gerar um certo sentimento de dono entre todos os especialistas técnicos.
Então, se você encontrar sub-papéis em um time Scrum ou SQUAD por ai, tais como: Engenheiros, arquitetos, analistas, estagiários, entre outros, são denominações herdadas de modelos tradicionais que visam identificar as diferenças entre os profissionais, e não é algo trazido ou sugerido pelo Scrum.
Papéis de Negócio ou Produto
Aqui começam as variações, os problemas e as dúvidas. Além do Product Owner podemos ter o Product Manager e o Business Owner.
O Product Manager, também conhecido como PM, surgiu para tentar resolver uma restrição de muitas empresas, que é a restrição de não dar poderes absolutos ao PO para decidir tudo que for necessário para o seu produto, criando assim um papel adicional de gestão para a tomada de decisão estratégica e corporativa em relação ao produto, e deixando o PO apenas com decisões operacionais e táticas.
Em muitos casos optar por ter o papel do PM pode ser uma boa estratégia, principalmente quando a empresa tem um grande produto, daquele tipo que podemos dizer que é um conjunto de produtos menores que forma um grande produto maior, tipo um sistema de CRM ou ERP, onde cada módulo pode ser um produto e ter o seu próprio PO, exemplo, o módulo financeiro pode ser um produto e ter o seu PO financeiro, e o módulo contábil a mesma coisa, e assim por diante. Neste caso é interessante ter um Product Manager para olhar para o produto como um todo e junto com a estratégia corporativa tomar decisões na esfera estratégica, antes de chegar nos POs, e que podem, inclusive, decidir sobre continuidade ou descontinuidade de partes do produto, de acordo com olhares externos ligados a concorrência, tecnologia, mercado e feedbacks de clientes.
Então, neste cenário podemos ter duas situações em que pode ser interessante, e ao mesmo tempo não ser considerado um erro ter um Product Manager e vários POs cuidando de produtos menores que formam um grande produto “guarda-chuva”.
- Situação 1: Quando o produto é muito grande, conforme mencionado anteriormente e um PO sozinho não iria conseguir cuidar de todo o produto e saber de tudo no detalhe necessário para cada parte do produto, neste caso justifica termos um PO para cada produto menor e um PM para o todo.
- Situação 2: Quando além do produto ser grande, este tem muitas evoluções, alterações e manutenções que demandam demais o PO e este não consegue se conectar aos clientes finais, ao mercado, as concorrências de uma forma satisfatória de modo a decidir tudo em relação ao seu produto e ainda estar disponível para o time de desenvolvimento. Neste caso faz sentido ter um PM focado mais em trazer estas decisões externas que vão nortear e guiar os desenvolvimentos futuros do produto.
Ainda ligado ao PO não conseguir fazer todo o seu trabalho em um produto devido ao fato deste produto demandar muito, ter muitas evoluções e muito trabalho de manutenção e sustentação, pode aparecer a figura de um analista de requisito ou analista de negócio, que muitas vezes recebe a responsabilidade de escrever histórias para o PO. O PO ter o apoio de um papel que o ajuda na escrita de histórias não é um problema, pelo contrário, é previsto inclusive pelo próprio Scrum. Porém, cuidados devem ser tomados neste cenário, tais como:
- A – Não é proibido que o PO escreva histórias, pelo contrário, a responsabilidade continua sendo do PO mesmo que haja outros papéis ajudando o PO nisso. A parte técnica das histórias deveriam ser escritos pelos Developers e não pelo PO ou por um papel adicional, cuidado com isso.
- B – O PO ter um ou mais papéis de apoio, não faz com que ele/ela possa desaparecer. Não estar disponível para o time ou ter vários produtos e vários times para cuidar, além de ser uma péssima estratégia vai gerar várias outras distorções na sua organização, como por exemplo gerar POs tiradores de pedido e sem conhecimento dos produtos que deveriam ser donos. Então muito cuidado também com este ponto.
- C – Eu particularmente gosto de sugerir as empresas que utilizem os próprios Developers para ajudar na escrita das histórias, contribuindo para o conceito de “Vamos parar de começar e começar a terminar”, e também ter o papel de QA (Quality Assurance) e utilizá-lo como apoio na escrita das histórias. De modo que o PO e o QA escrevam a parte de negócio, onde o QA ainda pode escrever a parte relacionada a testes, e os Developers a parte técnica.
Por fim, nos papéis relacionados ao negócio temos o Business Owner, ou BO, que um papel que surgiu para cuidar do negócio da empresa, e para empresas que tem várias linhas de negócio é até possível ter mais de um BO, um para cada negócio da empresa. E o que seria um negócio, e o que este negócio se diferencia de um produto?
Bom, entenda o negócio como o que move uma empresa, ou parte dela, e é maior que um ou mais produtos. Exemplo, uma empresa de treinamentos corporativos na área de gestão empresarial tem como negócio montar, comercializar e rodar treinamentos corporativos, e para isso ela provavelmente possui vários treinamentos, que são os produtos. Então um Business Owner é o responsável por olhar para todo o negócio, decidir junto com a estratégia da empresa, que treinamentos novos serão incorporados, qual o planejamento estratégico da empresa, que treinamentos faz sentido investir mais ou menos, e os POs vão cuidar de cada produto individualmente, seguindo o direcionamento do seu BO.
Podemos ter ainda um Business Owner, que olha para o negócio como um todo, abaixo deste Business Owner, podemos ter Product Managers que vão olhar para grandes produtos como um todo, e os Product Owners olhando para o seu produto menor, ou sub-produto dentro destes grandes produtos, ou até para produtos menores isolados e sem a necessidade de ter PMs.
Finalizando este bloco, podemos ter o Head de Produto, que nada mais é do que um papel de gestão de área, como se fosse um diretor ou gestor de departamento, que neste caso é o responsável pelos produtos ou por uma área de negócio específica, e por coordenar, orientar e coletar os resultados de todos os produtos construídos, evoluídos e mantidos em uma empresa. É um stakeholder importante, e que assume uma cadeira de Sponsor, ou patrocinador dos produtos dentro das empresas, e também um cliente interno importante que precisa ser ouvido e ter suas expectativas atendidas em relação aos resultados de negócio gerados ou não pelos seus produtos.
Só não esqueça de uma coisa. Nem todas as estruturas ou cenários precisam de todos estes papéis, preste bem atenção que fui descrevendo os contextos que fazem sentido ter um ou outro papel adicional para apoio, não saia criando e replicando estruturas como esta como se fosse um padrão para todos os seus produtos ou times ágeis, porque te garanto que vai dar errado.
Papéis de Liderança, Performance de Time e Gestão de Fluxos e Processos
Aqui temos o segundo bloco de variações, problemas e dúvidas, porque além do famoso Scrum Master, podem aparecer também: Agile Master, Kanban Master, Tech Leader.
É importante falarmos mais um pouco sobre o Scrum Master antes de entrar nos outros papéis, que na minha humilde opinião derivaram do SM. Segundo o Scrum o SM deveria ser o papel responsável por promover o ágil na empresa toda a partir do Scrum e de outras práticas ágeis e abordagens complementares, além de ter poderes e autonomia para promover mudanças na empresa como um todo. Porém na prática isso acabou não acontecendo nas organizações pelos mesmos motivos que o PO também não conseguiu poderes plenos em seu produto, e com isso novos papéis foram criados.
Um exemplo disso é o Agile Master, que para mim é a maior bizarrice que as empresas criaram, mas o que eu posso dizer além de te explicar as diferenças inventadas sobre este papel e o Scrum Master é: Aceita é segue em frente kkk
As empresas têm definido que o Scrum Master é o especialista apenas no Scrum, e o Agile Master é o especialista em mais práticas além do Scrum, podendo incluir Kanban, e outras como Lean Inception, Design Thinking, Lean e qualquer outra coisa que a empresa entender que é importante para um Agile Master saber. Para mim é bizarro porque nunca foi dito que o Scrum Master deve ser especialista apenas no Scrum, eu mesmo fui Scrum Master por alguns anos e eu sabia aplicar, ensinar e aprimorar muitas práticas além do Scrum, e para mim sempre foi esta a responsabilidade do Scrum Master.
Bom, independente de mim, e outros especialistas concordarem ou não, é assim que está no momento. Temos inclusive vários clientes trabalhando assim e temos nos adaptado ao mercado, onde o Scrum Master só trabalha com Scrum e o Agile Master trabalha com Scrum e mais outras práticas ágeis definidas pela empresa como pré-requisitos para este papel.
Já o Kanban Master aperece em alguns cenários onde a empresa quer um especialista apenas de Kanban, e em alguns casos pode aparecer o SDM, que é o Service Delivery Manager, que é um papel dedicado a implementar processos Kanban e gerenciar o fluxo Kanban, que também pode ser encontrado por ai como Flow Manager, ou Gestor de Fluxo. Então não se assuste se ver estes papéis por ai ligados ao Kanban, ok?
Antes de encerrar vamos falar dos cenários onde aparece o Tech Leader, que papel é este e o que ele deveria fazer? Bom o Tech Leader é um papel criado para ser o responsável por decisões técnicas em um time de desenvolvimento de produto. Precisamos lembrar que times ágeis, como um time Scrum por exemplo, os Developers ou especialistas técnicos deveriam tomar as decisões técnicas, além de criar especificações ou definições técnicas sem a necessidade de haver um Líder Técnico para isso, porém, de novo, devido a problemas de cultura e até de maturidade dos times, esta figura aparece para tentar solucionar este problema. É conhecido e sabido que papéis como o Scrum Master, Agile Master, Kanban Master e até o Agile Coach, não precisam obrigatoriamente ter conhecimento técnico para exercerem seus respectivos papéis, porém o Tech Leader já tem esta necessidade explícita e obrigatória, e por isso geralmente é um especialista técnico sênior que consegue orientar os demais integrantes do time e até tomar decisões técnicas por eles.
Papéis de Gestão, Estratégia e Condução de Transformações Ágeis e Organizacionais
Por fim temos o último bloco de variações que também geram problemas e dúvidas, e este bloco envolve os trabalhos do Agile Coach, que podem variar entre operacional ou de time, estratégico e enterprise, além do gerente de projetos, gerente ágil de projetos e outros papéis como Head de Produto e Head de Agilidade. Vamos entender todos eles e suas diferenças.
O famoso Agile Coach acaba por ser o profissional mais completo entre os agilistas, ou pelo menos deveria ser. É difícil encontrar empresas que falem em Agile Coach Junior, Pleno e Sênior, o mais comum é encontrar o Agile Coach que trabalha com os times e tem um foco mais operacional, que neste caso podemos dizer que é um Agile Coach Pleno e que tem experiência mais na formação, acompanhamento, mentoria e orientação dos trabalhos de times. Este profissional geralmente tem a responsabilidade de formar profissionais para atuar em quase todos os outros papéis mencionados até agora, envolvendo diversas práticas, frameworks, abordagens e formações de times.
O Agile Coach Estratégico ou também conhecido como Agile Coach Enterprise é o papel que ajuda as empresas nas transformações ágeis e digitais, e que planeja, define e conduz um plano de transformação, incluindo como serão tomadas as decisões em relação a métodos, práticas, ferramentas e estruturas de times a serem formados. Este papel pode ser considerado o Agile Coach Sênior, que atua diretamente com executivos, alta gestão e C-Level nas decisões estratégicas em relação as implementações de elementos ágeis na organização como um todo, e geralmente conduz e orienta os trabalhos dos Agile Coaches operacionais e de time que seguem o plano montado pelo Agile Coach Enterprise ou Estratégico.
Um outro nome para este Agile Coach Estratégico ou Enterprise, é o Agile Expert, que de uma forma geral é o mais completo dos profissionais denominados agilistas e deve ter capacidade, experiência e maturidade para ajudar e orientar a organização na maioria dos trabalhos que envolve agilidade, e na formação e desenvolvimento de todos os outros papéis que mencionei até agora.
Não podia deixar de falar do gerente de projetos e do gerente ágil de projetos que também está presente em muitas empresas que buscam transformações ágeis e implementações de elementos ágeis em sua estrutura.
Antes de mais nada é importante mencionar que quando temos um gerente de projetos ou gerente ágil de projetos estamos em um cenário híbrido, onde temos necessidade de trabalhos preditivos e adaptativos combinados para atingir os resultados esperados por um projeto. Independe das empresas chamarem explicitamente seus atuais gerentes de projeto de gerentes ágeis de projeto ou não, na minha opinião um profissional atual de gerenciamento de projetos deve obrigatoriamente ter conhecimento mínimo sobre agilidade e alguns métodos e abordagens ágeis utilizadas no mercado, como Scrum e Kanban, e algumas abordagens de otimização e Discovery de produto, como Lean, Lean Inception, Design Sprint, entre outros.
Sendo assim, um gerente de projetos em um ambiente híbrido, poderá apoiar times ágeis na gestão de orçamento e recursos (e aqui não estou colocando pessoas como recursos, ok?), auditorias, integrações entre times e áreas, gestão de contratos de fornecedores, aquisições, gestão de Stakeholders corporativos, entre outros trabalhos que se passados para o time ágil poderão onerar o seu trabalho ou até desfocar o esforço que deveria estar no desenvolvimento de um produto para melhor atender o cliente do produto.
O que eu vi muito acontecer na última década, de uma forma bem natural, foram vários gerentes de projetos que eram focados apenas em micro gestão das pessoas e em processos, migrarem para o papel de Scrum Master para focar em processos ágeis, e outros gerentes de projeto que eram muito focados em requisitos, contato com o cliente e planejamento de entregas, migraram para o papel do Product Owner, mas isto é outro assunto, e se você quiser saber mais sobre isso vou deixar o link no final deste artigo de umvídeo que falo sobre isso no meu canal.
Por último, temos o Head de Agilidade, que nada mais é do que um papel de gestão de área, como se fosse um diretor ou gestor de departamento, que neste caso é o responsável por coordenar, orientar e coletar os resultados de todos os trabalhos de agilidade realizados em uma empresa. É um stakeholder importante, e que assume uma cadeira de ser um Sponsor, ou patrocinador da agilidade dentro das empresas, e também um cliente interno importante que precisa ser ouvido e ter suas expectativas atendidas em relação aos resultados de negócio gerados pela aplicação da agilidade na corporação.
Conclusão
É coisa não é? Ufa, é papel e responsabilidade para caramba não é?! Porém não se assuste, em resumo não é exatamente errado ter vários destes papéis, porém, também não é necessariamente certo e muito menos obrigatório e necessário ter todos. Tome muito cuidado com a criação de papéis e funções demais. Para mim (e para muita gente) a Agilidade bebe na fonte do Lean, que prega processos enxutos e estruturas leve. A Agilidade fala sobre times pequenos e leves o tempo inteiro, então apesar de ser possível ter todos estes papéis em uma mesma empresa, ou uma grande parte deles, isso pode trazer burocracia excessiva, overhead e ao invés de trazer agilidade pode estar contribuindo para uma anti-agilidade.
Lembre-se sempre de definir muito bem cada papel e sua responsabilidade, se houver dúvida sobre quem faz o que, provavelmente você está com papéis demais, e com raríssimas exceções, menos é mais no caso de papéis e responsabilidades.
Espero que tenha gostado e que este conteúdo te ajude de alguma forma, e aproveitando, já que você chegou até aqui não vá embora sem deixar sua contribuição nos comentários e não deixe de curtir e compartilhar com quem você acredita que precisa ler este artigo.
Abraço e até o próximo conteúdo!
