Categories
Scrum

Livro: Tornando-se um excelente Product Owner

Como já disse em outras ocasiões, o papel do Product Owner é um dos menos abordados em literaturas sobre Scrum – e o papel dele é tão fundamental para o sucesso de um time que é difícil de entender o porque.

Inspirado no livro Scrum and XP from the Trenches do Henrik Kniberg, Robert Galen está escrevendo um novo livro entitulado Becoming a Great Scrum Product Owner, disponível para download em PDF no seu site. O livro ainda é um draft e sua cópia/impressão/distribuição ainda não são permitidos, porém pelo pouco que já li estou percebendo que é um excelente material e que deve preencher um espaço muito importante na literatura de Scrum. E o mais legal é que claramente várias das coisas que estão escritas são fruto da experiência prática do autor e não apenas um monte de teorias.

Recomendo muito muito fortemente a leitura, especialmente se você for um P.O., quiser ter um time de sucesso e quiser ser um profissional de sucesso!

Categories
Scrum

Times Scrum trabalhando em vários projetos ao mesmo tempo?

Antes de começamos a trabalhar com Scrum na Globo.com, era comum nossa equipe trabalhar em três ou quatro projetos ao mesmo tempo. Cada projeto era tocado por um time de mais ou menos uma a três pessoas e assim íamos fazendo as coisas.

Depois, com o Scrum, acabamos criando um time um pouco maior (de aproximadamente 9 pessoas) e, pela força do hábito, várias vezes nos pegamos com vontade de trabalhar em dois ou três projetos ao mesmo tempo. Talvez dê vontade de fazer isso para ter a impressão de que as coisas estão acontecendo, mesmo que lentamente, e que os projetos estão andando… Mas será que isso vale a pena? Vejamos.

Um dos principais objetivos do Scrum é entregar o maior valor de negócio para o cliente no menor tempo possível. Quanto mais dinheiro o cliente puder ganhar e quanto mais rápido, melhor. Sendo assim, o P.O. sempre deve pensar na melhor forma de maximizar o ROI – retorno sobre o investimento.

Falando de forma simplificada, o retorno sobre o investimento é calculado da seguinte forma: se você investe R$ 100,00 em alguma coisa e no final de um período você ganhou R$ 50,00 por conta deste investimento, você teve 50% de ROI. Sendo mais prático, quando você paga alguém para desenvolver um sistema para você, se você gastar R$ 100.000,00 e ganhar R$ 10.000,00 por mês, você está tendo um ROI de 10% por mês. Neste cenário o sistema se pagará em 10 meses, e a partir daí você passa a ter lucro.

Dito isso, vamos pensar numa situação hipotética. Imagine que um time de Scrum está trabalhando em 3 projetos ao mesmo tempo. Constata-se que no fim de 3 meses o time consegue finalizar e colocar em produção todos os 3 projetos:

Tudo ao mesmo tempo 1

Para conseguir entregar esses 3 projetos, o time teve que trabalhar paralelamente em todos eles, usando sempre 1/3 do tempo de cada Sprint para cada um dos projetos. Desta forma só depois de 3 meses o cliente poderia começar a faturar com seus novos produtos.

A pergunta é: não seria muito melhor se o time tivesse trabalhado de forma serial, focando todo seu tempo e esforço em apenas um projeto e entregando uma coisa de cada vez?

Tudo ao mesmo tempo 2

Trabalhando dessa forma, no fim do primeiro mês o primeiro projeto já poderia entrar em produção, antecipando o faturamento, gerando dinheiro (ROI) para o cliente mais rápido e diminuindo o tempo necessário para recuperar seu investimento. Neste caso, a antecipação da entrega de um dos projetos faz com que o cliente comece a faturar 2 meses antes do que poderia – sem dúvidas o ROI foi maximizado.

Voltando ao ponto inicial, é preciso resistir à tentação de querer trabalhar em vários projetos ao mesmo tempo. O melhor é focar no mais importante deles (ou seja, o que vai gerar mais lucro para a empresa) e trabalhar nele até o fim, passando em seguida para o próximo projeto mais importante e assim por diante.

Categories
Agile Scrum

Mais sobre Product Owners

Para os Product Owners de plantão, seguem alguns artigos interessantes:

Em primeiro, Roman Pichler escreveu um excelente artigo no InfoQ entitulado “Creating Product Owner Success” com vários insights sobre como ser um Product Owner de sucesso. Além disso ele também fala de alguns erros comuns cometidos nesse papel. Há uma lista de outros artigos sobre Scrum e P.O.s no site do Roman, vale a pena dar uma vasculhada.

O segundo artigo é do Rodrigo Yoshima entitulado “Product Owner: Um de$graçado ganancio$o”. O Rodrigo colocou um ponto interessante que eu também vejo acontecendo em alguns projetos: a falta de compromisso com o ROI. O Scrum é totalmente “ROI-oriented” e é absolutamente essencial que o P.O. entenda isso plenamente para o sucesso dos projetos.

E por último, o Danilo Bardusco escreveu sobre “Product Owner Técnicos”, argumentando porque o P.O. também deve ter bons conhecimentos técnicos e como isso é benéfico para que ele possa guiar bem o time e expressar melhor suas idéias.

Além disso, há uns meses escreví sobre esse mesmo assunto referenciando um artigo do Antonio Carlos Silveira sobre “O papel do Product Owner e priorização do Product Backlog”, que também vale a pena ler.

Categories
Scrum

O papel do Product Owner no Scrum

Se você pesquisar na Internet sobre Scrum, vai perceber que muito se fala sobre o Scrum Master, características do time, organização de backlog e histórias, sprints, e etc. Uma das características mais interessantes do Scrum, e que nem sempre é enfatizada, é que o cliente tem um papel muito importante dentro do projeto, muito diferente das metodologias “tradicionais”. O Product Owner, como é chamado, representa um dos papéis fundamentais do Scrum. Ele pode ser o próprio cliente ou alguém que tem a visão dele e que ele confia para administrar seu projeto.

Nos projetos Scrum, o P.O. tem uma importância tão grande quanto o próprio time ou o Scrum Master. Eu pessoalmente considero sua importância de certa forma maior do que a de todos os outros, visto que o P.O. pode fazer um projeto falir ou “skyrocket”, dependendo das decisões que ele toma.

O Antonio Carlos escreveu um ótimo resumo sobre o papel do P.O. e sua importância dentro dos projetos Scrum. Leitura obrigatória.