0

Scrum em quadrinhos …

Mais um post explicativo dos nossos papéis, para facilitar entendimento de alguém que não seja da área e precise entender o que é o PO, SEO, UX, Arquiteto, Front End, Back End e Testador. Este é o MVP, o valor proposto é diferenciar ao máximo nossos diferentes papéis, técnicamente e participação:

DISCOVERY 1 – O PO é uma ampliação do papel do analista de negócios, pois agora ele passa a ser o representante do cliente, com foco em ROI e valor:

DISCOVERY 2 – O Product Owner conta com o trabalho dos papéis de UX e SEO para conceitos de comunicação, ergonomia, identidade, relevância, etc:

DISCOVERY 3 – O PO deve envolver o arquiteto ou integrante mais senior da equipe, além do testador ou SQA, para validar e alinhar os requisitos mais técnicos e que poderiam inviabilizar a US da forma como foi descrita:

PLANNING – Após a User Story detalhada e aferida a contento, o product owner esta em condições de apresentá-la a equipe, para estimativas e pacto:

CONSTRUÇÃO – O trabalho em sinergia entre os desenvolvedores e testador é fundamental para a entrega de software com qualidade e valor pactuados:

REUNIÃO DIÁRIA – A cada dia, sempre no mesmo local e horário, o time se reune em frente ao quadro de tarefas para ajustar o rumo e corrigir desvios:

REVIEW – A cada término de um ciclo de 2 a 4 semanas, o time convida seus principais usuários e stakeholders para apresentar o que foi construido, o debate de 2 horas irá proporcionar maior entendimento e convergência entre os times:

RETROSPECTIVA – A cada ciclo de 2 a 4 semanas de trabalho, a equipe se reune por 2 horas para refletir e debater sobre como trabalharam e como melhorar, usando dinâmicas de integração e auto-avaliações técnicas:

Clique aqui para ler mais sobre papéis e funções da equipe Scrum.
Clique aqui e leia um post sobre a responsabilidades do papel Scrm Master.
Clique aqui para acessar um post sobre o papel de Product Owner.

1

Product Owner

O Product Owner é o papel de maior responsabilidade e visibilidade no método Scrum, representa o cliente e é responsável pelas decisões de qual trabalho da equipe maximizará o valor do produto e agregará mais aos envolvidos, define metas, prioriza e aprova a qualidade, sempre buscando garantir o maior retorno ao investimento.

Mas, deve ter cuidado com o sentimento de “posse”, em métodos ágeis cada integrante deve ter a humildade do sentimento de “pertencimento”, que o impulsiona a entender, compartilhar e atingir a meta em conjunto, colaborando no orgulho do que, como e com quem esta trabalhando, ele não é exceção a esta premissa, ele “faz parte” do time.

O que diz o Scrum Guide?

O Product Owner é O responsável por gerenciar o Product Backlog do produto, pode pedir a um analista de negócios, SEO ou sistemas, QA ou arquiteto, que lhe auxiliem no entendimento, registro, diagramação do fluxo, mas será sempre o responsável final pelas decisões de backlog e priorizações:

  • Registrar com clareza os itens do Backlog do produto;
  • Ordenar assertivamente os itens do Backlog do produto;
  • Garantir que o Backlog do produto seja visível e claro a todos;
  • Garantir que a equipe entenda 100% os itens do Sprint Backlog;
  • Garantir o valor do trabalho desempenhado pela equipe;
  • Perceber o MVP e melhoria contínua em ciclos iterativos.

Ninguém está autorizado a mandar a equipe de desenvolvimento trabalhar em um conjunto diferente de requisitos ou mudar sua prioridade a revelia do PO. Isto NÃO quer dizer que ele não pode ser questionado, deve, mas qualquer mudança no planejado deve ser compartilhada e decidida COM ele.

Cotidiano de um PO

Eu trabalho em um departamento de TI em uma grande empresa em que o PO é um colega e esta disponível a qualquer momento, é diferente de uma empresa prestadora de serviços que trabalha com um PO do cliente, mas em ambos os casos o PO deve dedicar-se a este papel e ter o máximo de tempo para este desafio.

Digo que 50% do tempo de um PO é sentado junto aos usuários, envolvidos e interessados, enquanto 50% é sentado junto a equipe, participando das reuniões diárias, planejamento, retrospectivas, reviews, dia-a-dia. Cuidado, ter um PO que fica a disposição só pelo telefone, pois tem “mais o que fazer” é a fórmula do insucesso!

Autocracia x Democracia

Assim como o Scrum Master, o Product Owner não possui hierarquia sobre a equipe enquanto exerce seu papel, sua força é conhecimento e argumentação, mantendo sempre o foco na obtenção do melhor do processo, pessoas e recursos para atingir o máximo de valor para o negócio, de forma equilibrada e sustentável.

Um erro comum de um PO iniciante é continuar usando  a conjugação na 1ª pessoa do singular e 3ª do plural, “eu” e “eles”, enquanto o único meio de tornar uma equipe Scrum um sucesso é usar só a 1ª do plural, “nós”. Parece abobrinha, mas não é, todo o time, inclusive o PO deve ter a certeza de que TODOS vencem ou falham juntos.

Discovery e Delivery

Na etapa de Discovery, desde a visão até o Sprint Planning, seu papel é montar e gerir o Product Backlog, extrair dele a melhor definição de Release e de cada Sprint Backlog, de forma a permanentemente oferecer à equipe o melhor entendimento daquilo que mais agregará valor ao negócio em um contínuo iterativo-incremental.

O PO não é cargo de gabinete, deve ir a campo diariamente, lançando mão de eventos que valorizam a participação e convergência, Business Model Canvas, Story mappings, Brainstormings, Focus Groups, pesquisas, abrir canais junto aos envolvidos e interessados, apoiar e ampliar oportunidades para embasar suas decisões.

Na etapa de Delivery, a partir do Sprint Planning até a entrega e retrospectiva, exige dele permanente entendimento do status das tarefas selecionada para a iteração, de forma a diariamente tomar as decisões necessárias para correção de desvios, apoiando a equipe nos planos de ação de contorno e ajustes necessários.

Um erro clássico é o PO manter-se como único elo entre negócio e equipe, interfaceando de tal forma que os usuários desconhecem o restante do time e o time não possui qualquer vínculo com usuários, esta é uma reserva de mercado perigosa, que centraliza e bitola toda informação.

Cuidado com a reserva de mercado

O Product Owner deve sempre que possível convocar integrantes da equipe (analistas, arquitetos, QA, …) para reuniões na área de negócios e para as timeboxes do ciclo de DISCOVERY, garantindo visões complementares e também divergentes, ampliando debates e qualificando as decisões.

A meu ver, a timebox de REVIEW existe exatamente para garantir um mínimo de integração e vínculos, a equipe não pode ter uma única visão oficial, garanti-la é oportunizar a entropia que gerará o debate, sinergia, compromisso e convergência, gerando maior conhecimento de causa a todos.

Ferramentas

As ferramentas mais relevantes a nível mundial são RALLY e VERSIONONE, mas tem-se diversas opções free e freemium, como o plugin JIRA, SeeNowDo, ScrumHalf, ScrumDo, ScrumWise, entre outros produtos e serviços que apoiam a gestão Scrum de product backlog, sprints backlogs, sprints, quadro, artefatos.

Product backlog – Na ausência de ferramentas especialistas, alguns PO’s usam planilhas Excel ou mapas mentais como o WEBBRAIN, que os apoia em todo o ciclo de DISCOVERY, até que um de seus tópicos torne-se parte de um Sprint Backlog, na forma de uma User Story completa e detalhada.

Sprint backlog – Na ausência de ferramentas especialistas, nós usamos uma ferramenta Wiki para a documentação das User Stories, que nos permite tratar todos os documentos de forma colaborativa, com acesso web, perfis e logs, embedando ou linkando o trabalho do UX, SEO, Engenharia e tudo mais do interesse da Sprint.