DSC04593
Compartilhar no facebook
Compartilhar no twitter
Compartilhar no linkedin
Diurno

A importância de P.O’s nos squads ágeis

Uma breve história de terror

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.

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

Exemplo de Time Scrum
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.

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 no squad. 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.

Uma história diferente

Raquel 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 e seu time é composto por Scrum Master, PO, UX Designer, arquiteto, desenvolvedor líder, dois desenvolvedores plenos e dois estagiários. O PO passa muito tempo imerso no contexto do cliente, mas não deixa de trabalhar com o time pelo menos parte do dia.

As histórias de usuário são detalhadas juntamente com o time nas reuniões de refinamento e todos têm a oportunidade de tirar dúvidas sobre o negócio. Além disso, o UX Designer está sempre trabalhando junto do PO, ajudando na proposta de soluções e as validando com os usuários antes mesmo do início do desenvolvimento. Raquel sabia que o PO não tinha autonomia para priorizar as histórias que seriam desenvolvidas, mas ele tinha contato direto com as pessoas que faziam essa priorização. Ela participou de algumas reuniões de planejamento e percebeu que o negócio apresentava os problemas que tinham que ser resolvidos, para que a solução fosse gerada em conjunto pelo time, agregando muito mais riqueza e completude às soluções.

Após duas sprints, Raquel tinha muito mais contexto sobre o setor de atuação do cliente. A história que ela ajudou a desenvolver foi implantada e ela ficou muito orgulhosa de ver aquilo que ela construiu em uso por tantas pessoas. O time estava trabalhando bem e havia uma sensação de satisfação, pois não havia código represado e todos podiam ver o impacto da solução. As duas entregas foram boas. Ela participou de algumas validações com usuários, pois a solução proposta era testada com os usuários finais continuamente. Quando eram encontrados problemas, eles entravam como itens no 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.