Concrete Logo
Hamburger button

Anatomia de um time ágil

  • Blog
  • 15 de Junho de 2018

Como Product Owner (PO), acredito que ter autonomia ao executar um produto é fundamental, essencial. Precisamos ter “licença poética” para criar, priorizar e planejar, mas seria egoísmo da minha parte pensar somente na minha autonomia como Dona do Produto. Até porque PO é parte de um grupo e onde um tem, todos também devem ter.

Neste artigo vou falar sobre a minha opinião a partir de experiências vividas dentro de times ágeis. Nada está escrito em pedra, porém está dando certo por enquanto.

Quando comecei como PO, entrei em um projeto que já estava rodando há dois anos em um grande cliente. A ideia era inovadora para um determinado processo de pagamento, mas ao entrar, pude perceber três problemas graves:

1. Em dois anos o incremento havia evoluído muito pouco;
2. Eles não possuíam uma estratégia de mercado, nem um time to market;
3. Tinham uma grande dificuldade de escutar as sugestões dos envolvidos.

Sem detalhar o projeto, já que não é o foco aqui, aprendi muito com esses pontos: o cenário seria diferente se as pessoas envolvidas escutassem as sugestões e opiniões do time.

Meu outro cliente era a nova ‘vaca leiteira’ da empresa. Para ele, elaboramos uma estratégia utilizando o Scrum Scale, ou seja, squads cross. Dividimos o ‘produtão’ em três frentes e fiquei responsável como PO em uma delas, na de Configuração. A partir do método Lean, seguimos a premissa do MVP (minimum viable product), construindo por camadas, fazendo o mínimo a cada entregável.

Falando da vertical de Configuração, especificamente, cada pessoa tinha um papel importante na criação do produto. Montamos uma estratégia para envolvê-los desde o início, assim os desenvolvedores poderiam opinar em como e qual seria a melhor forma de produzir uma feature considerando um menor esforço, focando em algo mais simples para o MVP. E, claro, seguindo os padrões de usabilidade que o Product Designer argumentar como melhor caminho a seguir para o usuário com base no mínimo necessário.

Um dos pontos positivos desse projeto foi termos liberdade e autonomia para produzir algo do zero. Toda semana acontecia um refining no qual era discutido os desejos e as necessidades dos stakeholders e só então partíamos para a idealização das telas etc. Como sabemos que muitos devs não curtem reunião, eles ficavam à vontade para participar seja presencialmente ou via alguma ferramenta de comunicação online. Na volta do evento, quem compareceu repassava para o restante da equipe o que havia sido debatido e assim mantínhamos o alinhamento entre nós.

No momento de idealizar uma nova tela ou uma nova feature para a plataforma que estávamos construindo, a partir de insights gerados no refining com os stakeholders, cada integrante do time opinava sobre o conceito e fazia levantamento com base em pesquisas, vivências e em experiências para chegarmos em um denominador comum.

Esse era um momento de concepção e não o de um refining mais técnico – que também acontecia na sprint -, o que não vem ao caso.

O intuito do desenvolvimento é a equipe trabalhar em conjunto em cima do mesmo propósito, com autonomia para gerar, sugerir e debater. O produto não é do PO. É do time. Um mérito de todos.

Para mim, isso é o que faz uma entrega dar certo. Matemática básica: PESSOAS com AUTONOMIA geram IDEAÇÃO, trabalhando em cima do MESMO PROPÓSITO, criando PRODUTOS de qualidade.

Parece tudo muito incrível, mas para chegar a esse nível de maturidade é preciso passar por um período de aprendizado e de crescimento, no qual percebemos o verdadeiro papel de cada um dentro do contexto ágil.

(Ficou com dúvida sobre como alcançar esse nível? Tem um podcast muito bom com dois Agile Coaches da Concrete, o André (Dedé) Coelho e o Luis Guimarães. Clica aqui para acessá-lo.)

Ou seja, cada membro tem sua capacidade única de contribuir da melhor forma possível. Ter autonomia requer algumas responsabilidades também.

Os Scrum Masters, Product Designers e QAs com quem trabalho até hoje estão sempre me acompanhando nas reuniões com os stakeholders e em eventos de refining, principalmente, o que não significa que somente nós fazemos parte da criação. Compartilhamos informações com todo o time, porque todos trabalhamos em prol de um objetivo comum.

Pois ‘departamentalizar’ uma equipe não condiz com o termo multidisciplinar que o ágil prega. Cada integrante tem o seu papel e suas responsabilidades, considerando o incremento e principalmente a qualidade do produto.

Do lado técnico, muitas vezes em uma consultoria, os desenvolvedores não possuem tanta autonomia para escolher as tecnologias com as quais gostariam de trabalhar. Levando isto em consideração, o mínimo que podemos fazer como time é proporcionar liberdade para eles desenvolverem da forma que desejarem, sempre contemplando uma entrega de qualidade e seguindo os critérios pré-estabelecidos no PBI (Product Backlog Item). Isso é ter autonomia com responsabilidade.

O QA, por exemplo, precisa ter total autonomia para criar os cenários do teste automatizado. Os desenvolvedores também, não só como vão produzir, mas também como vão criar os cenários de testes unitários e de contrato.

Outra forma também seria apresentar propostas para os clientes visando melhorias de arquitetura, códigos, linguagens etc. É importante mostrar quais são os retornos, riscos e retrabalhos dessa nova proposta – se compararmos com a antiga – e como ela impacta no cliente e nos envolvidos.

Mais um ponto muito importante é que o PO precisa dar abertura para o time opinar quanto aos PBIs escritos. Nem sempre lembramos de todos os critérios de aceite necessários. Às vezes esquecemos de considerar algum fluxo negativo, por exemplo, que um QA ou um dev lembraram.

O projeto atual tem sido bastante desafiador. No início, para descobrir qual produto desenvolver, alcançamos a confiança dos stakeholders e, assim, tivemos a oportunidade de fazer duas semanas de imersão com técnicas consensuais de design thinking, entre outras, para convergir ideias e sair com um roadmap ao final.

Já que não estávamos desenvolvendo nada ainda, foi de extrema importância a participação de todos durante cada dinâmica e bate-papo com os stakeholders. O time não só teve autonomia para discutir o MVP, como, a partir do momento em que conquistamos a confiança do cliente, teve autonomia para seguir com o nosso processo de criação.

E assim vivemos felizes para sempre. 😛 #sqn

Sei que pareceu tudo ou um pouco óbvio para alguns ou irreal para outros. A questão é, cada pessoinha dentro de um time ágil, precisa entender seu papel na constituição de um produto seja mobile, web, inteligência artificial etc.

A autonomia gera motivação, enriquece o incremento, ajuda no alinhamento do time em prol de um mesmo propósito, incentiva cada um a evoluir junto e a evoluir o MVP. Autonomia não quer dizer que cada um vai trabalhar por si e “adeus, restante dos coleguinhas”, mas sim unir cada pessoa, aprender a escutar uns aos outros, aprender a argumentar suas ideias, a mostrar o melhor caminho para o cliente e tudo isso com uma única visão de propósito.

VOCÊ (seja dev, PO, QA, product designer, SM…) é uma peça essencial e fundamental para tornar a experiência de um usuário super incrível quando ele for utilizar o SEU produto. Por isso brigue por sua autonomia e crie junto. Sugira ideias!

*Todos os ícones das imagens foram retirados do site www.flaticon.com

Os Product Owners na Concrete são responsáveis por maximizar o resultado dos Produtos Digitais que fazemos para nossos clientes. Fazemos parte de Times multidisciplinares de alto desempenho e criamos Produtos com criatividade e agilidade. Acreditamos no uso de Cloud, open source, Scrum, customer development, inbound marketing, testes A/B, SEO e Analytics como parte do sucesso dos produtos. Nosso papel é garantir que as expectativas do cliente estejam alinhadas com o trabalho do time. Vem mover o mundo com a gente! Acesse: concrete.com.br/vagas