Squads ágeis e a importância do Product Owner

Neste artigo você vai ver qual o papel de um product owner nos squads ágeis. Vamos aquecer essa conversa com uma pequena história:

Melissa trabalha em uma empresa de desenvolvimento de software. Ela entrou em uma squad e está um pouco perdida. Ela já trabalhou com metodologias ágeis anteriormente, mas dessa vez, o time é composto por um desenvolvedor líder (DL), três desenvolvedores plenos e um estagiário, estrutura diferente do ela estava acostumada. O gerente, o arquiteto e o UX Designer do projeto são meio período, ou seja, trabalham também em outros times, dividindo o tempo entre um projeto e outro. Não há pessoas responsáveis pelo papel do Dono do Produto (ou PO, do inglês Product Owner) nem do Scrum Master bem definido, o que a deixou surpresa.

Essa história é de terror

A primeira coisa que a Melissa estranhou foram as histórias de usuários. Como não havia PO no time, elas eram definidas pelo DL juntamente do time de desenvolvimento. Elas não eram focadas nos usuários, eram as chamadas “histórias técnicas”. Ela achou isso estranho, mas como era nova no time resolveu não opinar. Era também o DL quem negociava a priorização das histórias diretamente com o cliente. Ela participou de algumas reuniões de planejamento e achou a comunicação muito difícil: o time técnico e o negócio estavam de lados distintos, e pareciam até falar um idioma diferente. Ninguém se entendia.

Após duas sprints, Melissa estava irritada e receosa. A “história técnica” que ela ajudou a desenvolver perdeu a prioridade no meio do sprint e não seria colocada em produção. O time estava trabalhando muito, mas pairava uma sensação de descontentamento tanto com o cliente quanto dentro do próprio time. As duas entregas não foram boas. Ela participou da homologação com os usuários e eles pontuaram vários problemas na solução que tinham implementado. Não daria tempo de voltar as histórias para o desenvolvimento e elas foram implantadas assim mesmo.

Afinal, o que estava acontecendo com o squad? Por que estavam todos tão aflitos e desalinhados? Ser ágil parecia muito difícil e frustrante naquele momento.

Ser ágil não pode ser tão difícil assim

Adaptar-se ao contexto de trabalho ágil tem sido um grande desafio para empresas nascidas na era não-digital. Isso porque a transformação digital não envolve apenas uma mudança na forma de trabalho, mas também na forma como as pessoas pensam e desenvolvem produtos. Muitas vezes o modelo de trabalho ágil é entravado pela estrutura organizacional ou cultura da empresa. É de fato um desafio, mas que tem sido encarado, uma vez que a metodologia ágil tem se mostrado efetiva e valiosa no ambiente cada vez mais volátil, incerto, complexo e ambíguo em que estamos inseridos.

Ser ágil pode parecer muito simples, a princípio. O Manifesto Ágil é composto por quatro premissas, por que seria tão difícil? A complexidade vem exatamente da possibilidade do uso das metodologias ágeis em diferentes contextos e situações, sem nada prescrito. É uma definição ampla de uma forma de trabalho, sem especificar “como” deve ser feito. Não existe regra que vá funcionar para todos, o que deixa o desafio mais interessante e estimula a experimentação.

Na história da Melissa foi feita uma tentativa de aplicação de metodologia ágil em um contexto com várias limitações: para reduzir custos, muitos papéis-chave foram eliminados, na esperança de que essas tarefas seriam absorvidas pelo time. E isso de fato é possível em alguns casos, mas depende de vários fatores, como a maturidade e sinergia do time. Porém, a chance de isso criar mais problemas do que economia de fato, é enorme.

A peça que faltava nos squads ágeis

O Time Scrum deve ser multidisciplinar, auto organizável e colaborativo. É composto por pessoas que desempenham os papéis de Scrum Master, PO e o Time de desenvolvimento, que são as pessoas com papéis técnicos (desenvolvedor, UX designer, arquiteto, devops). Não há uma definição rígida de tarefas, mas o time deve se organizar para realizar suas atividades e alcançar o objetivo da sprint. Na história da Melissa, vimos que o time tinha uma estrutura diferente, mas nem por isso podemos dizer que não se tratava de um time ágil. A questão, é que por diversos fatores a combinação das habilidades das pessoas junto ao cliente específico não estava funcionando, por diferentes razões.

Pontos de atenção

Analisemos de perto os principais problemas apresentados no cenário que Melissa estava inserida: uso de histórias não focadas nas necessidades dos usuários e que não entregam valor de negócio, problemas na priorização das histórias, falta de validação contínua das funcionalidades com os usuários, dificuldade de comunicação entre as pessoas de negócio e o time de desenvolvimento, entregas que não agregam valor aos usuários. São problemas que exemplificam a falta que o papel de um PO faz nos squads ágeis. Se o principal objetivo do time é atender as necessidades do usuário e essa é a grande dificuldade do time, o time nunca consegue entregar valor ao usuário. As pessoas fazem um grande esforço, mas não conseguem mostrar o impacto do trabalho que estão fazendo. Além de ser um grande desperdício de esforço, isso causa atrito e desmotivação.

Voltando às definições, o PO é responsável por manter o backlog vivo e visível para todos. Através do registro e detalhamento das demandas, o PO é a pessoa que maximiza o valor do trabalho que o Time Scrum desenvolve, por garantir a entrega de valor aos usuários em questão. Não ter um PO, ou negligenciar essas tarefas é correr o risco de entregar algo que ninguém precisa, quer, ou sequer faz sentido. É não seguir em direção à estratégia de negócio do cliente.

Squads ágeis, uma história diferente

Raquel, uma profissional que trabalha em uma empresa de desenvolvimento de software, integrou uma squad e se sentiu um pouco perdida. Sua experiência anterior com metodologias ágeis a ajudou, e seu time é formado por um Scrum Master, PO, UX Designer, arquiteto, desenvolvedor líder, dois desenvolvedores plenos e dois estagiários. O PO dedica muito tempo imerso no contexto do cliente, mas também colabora com o time em parte do dia.

O time detalha todas as histórias de usuário nas reuniões de refinamento, permitindo que todos tirem suas dúvidas sobre o negócio. O UX Designer trabalha em conjunto com o PO, auxiliando na proposta e validação das soluções com os usuários antes mesmo do desenvolvimento. Raquel sabia que o PO não tinha autonomia para priorizar as histórias, mas ele mantinha contato direto com as pessoas responsáveis por essa priorização. Participando de reuniões de planejamento, ela percebeu que o negócio apresentava os problemas a serem resolvidos, permitindo ao time gerar soluções em conjunto, tornando-as mais ricas e completas.

Após duas sprints, Raquel adquiriu um contexto mais amplo sobre o setor de atuação do cliente. A história em que ela contribuiu foi implementada, enchendo-a de orgulho ao ver sua criação sendo utilizada por muitas pessoas. O time estava trabalhando de forma eficiente, sentindo satisfação, pois não havia códigos represados e todos puderam perceber o impacto da solução. As duas entregas foram bem-sucedidas. Ela também participou de validações com os usuários, pois a solução proposta era testada continuamente com os usuários finais. Quando eram encontrados problemas, eles eram adicionados ao backlog para serem priorizados e desenvolvidos na próxima sprint.

E isso é possível?

A história da Raquel pode parecer um conto de fadas inalcançável. Não existe um time sem problemas, mas a forma de lidar com eles variam bastante. A questão é muito mais como trabalhar de forma preventiva (ao invés de reativa) e usar das metodologias e ferramentas para otimizar e melhorar o trabalho de todos. O que mudou? No cenário da Melissa, não tínhamos a atuação ativa um PO, no da Raquel tínhamos. E isso faz toda a diferença: se o objetivo é entregar valor para o meu usuário, negligenciar o papel que cuida exatamente do alinhamento com o time a esse objetivo pode ser a receita para o fracasso.

A grande questão é que da mesma forma que o Manifesto Ágil propõe, mas não prescreve, o papel de PO pode ser muito mutável, pois, depende do contexto e da natureza do que está sendo desenvolvido. Existem certificações e cursos que ensinam métodos e ferramentas para ensinar esse profissional a extrair as informações que precisa no seu dia-a-dia, mas novamente, conseguir guiar o time na entrega de valor do seu negócio é um desafio que exige experimentação e aprendizado constantes. Por fim, e não menos importante, é preciso entender a fundo o que significa ser ágil: não se trata de entregar rápido, ou fazer logo. É desenvolver a capacidade de perceber mudanças (internas ou externas) e responder adequadamente a elas, agregando valor ao seu produto ou serviço. Fazer isso de maneira assertiva tem tudo a ver com o papel do PO e sua missão dentro de um Time Scrum.