Participe da Maratona Behind the Code! Prêmios e desafios incríveis te esperam, não perca! Inscreva-se aqui

Escalando o Scrum Product Owner para grandes programas

Introdução

O Product Owner (PO) é o papel que possue maior visibilidade e responsabilidades no método Scrum, ele é o responsável pelas decisões sobre o trabalho que o time realizará e como o time poderá maximizar o valor para os usuários de negócio garantindo o maior retorno ao investimento.

Neste artigo, destinado a praticantes de processos ágeis e possíveis candidatos a se tornarem Product Owner em times ágeis, vamos discutir as principais responsabilidades de um Product Owner, suas habilidades e como devemos escalar o Product Owner para atuar no contexto de grandes programas.

Visão Geral do Scrum

Tudo começou a alguns anos atras com a criação do Manifesto Ágil para desenvolvimento de software que contemplava um conjunto de princípios a serem seguidos dentro de um projeto de software.

Dentre alguns desenvolvedores que criaram o manifesto ágil, estavam o KenSchwaber e Jeff Sutherland que criaram o Scrum. Segundo eles, o Scrum trata-se de um framework dentro do qual pessoas podem resolver problemas complexos e adaptativos.

O framework Scrum consiste nos times associadas a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum.

Leia mais sobre o Scrum em : http://goo.gl/4CovQJ

Quem é o Product Owner ?

O Product Onwer é membro do time ágil que serve como um representante ou proxy do cliente responsável em definir e priorizar o backlog do trabalho do time.

Não devemos concluir que o Product Owner resume-se em escrever, priorizar e aprovar user stories, pois ele também é o principal responsável em representar os interesses dos stakeholders e atuar como um representante do time para todos os demais envolvidos.

Ken Schwaber, define o Scrum Product Owner como o “responsável em representar os interesses de todos bem como o resultado do trabalho”

Figura 1 – Fluxo de Comunicação do Product Onwer

alt

Quais as habilidades de um Product Owner ?

Muitos questionam como selecionar os Product Owners ? Quais são suas principais habilidades ? Quem são os candidatos a serem Product Owners nos times de desenvolvimento tradicionais ?

Primeiramente vamos responder, as principais habilidades que um Product Owner deve possuir:

  • Poder e habilidades para tomar decisões: Ter habilidade para tomar decisões, pois todo o tempo o Product Onwer será questionado pelo time: Qual user story é a mais importante ? Qual devemos fazer primeiro e qual devemos ignorar ? Imagine que se tivermos um backlog de 50 requisitos, não poderemos ter 10 com prioridade 1. O PO deverá ranquear na ordem 1 até 10. É nessa ordem que o trabalho será executado. Isso ajudará a manter o foco na equipe.

    Essa priorização deve ser feita pensando na entrega de valor. Vale lembrar também que o Product Owner deve trabalhar em conjunto com o Arquiteto para priorizar também user stories importantes para a arquitetura ou mitigação de riscos.

  • Skills de análise de negócio: O Product Owner deve ter habilidades para identificar as necessidades dos stakeholders, entender o problema e identificar os requisitos para o backlog. Ele deve ter respostas como: “Porque a empresa esta disposta a gastar esse valor para construir o software ?” “Porque devo fazer primeiro esse item e não o terceiro ?” “Quem serão os beneficiados por esse desenvolvimento ?”
  • Habilidades de Comunicação: O Product Owner precisa de ser um bom comunicador, possuir habilidades de comunicação oral, saber ensinar e possuir uma boa escrita. Ele precisa conhecer quem são os stakeholders, interagir constantemente com eles e facilitar a comunicação destes com os times. Vale lembrar aqui que os stakeholders não são somente as pessoas da área de negócio, e sim qualquer envolvido direta ou indiretamente com o desenvolvimento.
  • Conhecimento do Negócio: Parece básico aqui, mas é importante ressaltar que conhecimento do négocio não é somente saber quais funcionalidades e como o processo vai funcionar no sistema.

    É necessário conhecimento da organização, do segmento do mercado, princípios e práticas do negócio e o conhecimento da solução bem como os impactos técnicos de suas decisões.

    Possuir a “Visão Horizontal”, principalmente nos programas maiores é essencial. A capacidade de visualizar o todo e não somente o pedaço do processo que é do interesse do seu time vai facilitar o Product Owner tomar as decisões corretas.

    Vale ressaltar, que o Product Owner pode precisar de experts para ajudá-lo com o conhecimento de partes do negócio desconhecidas. Em alguns casos o PO pode ter um “time” de especialistas de diferentes domínios de negócio (time extendido), mas quem dita a prioridade e responde pelos requisitos é sempre ele.

Quais as principais responsabilidades do Product Owner ?

Segue abaixo um guia rápido sobre as principais responsabilidades do Product Owner e como é o seu dia-a-dia :

  • Definir a Visão: Estabelecer e comunicar a visão do que será construído refletindo as necessidades dos stakeholders e as features propostas para atender à essas necessidades.
  • Elaborar o Roadmap: Estabelecer e comunicar os principais entregáveis (features) ao longo do tempo. Lembrando que o nível de detalhe e refinamento será revisto ao longo das fases.
  • Preparar e participar do planejamento da Release: Como mencionado anteriormente, o PO é responsável em definir e priorizar o Backlog. O plano inicial da Release bem como seu refinamento ao longo das iterações (sprints) deve ser definido pelo PO.
  • Refinar do Backlog: Com o input dos Stakeholders e Product Managers, o Product Owner tem a responsabilidade primária de definir e manter o backlog do time. Essa responsabilidade também é conhecida por “Backlog Grooming”. O Backlog é composto na sua maioria por user stories mas também contempla defeitos, spikes (pesquisas, design, exploração ou prototipação), refactors e tarefas de infraestrutura. Os itens do backlog devem ser priorizados com base no valor entregue ou outras dependências do time determinadas no planejamento da Release.
  • Planejar a Iteraçao: O PO tem a responsabilidade em definir e preparar o backlog da iteração. Durante o planejamento da iteração, ele é quem apresenta a meta bem como as stories com seu detalhamento e ao final da iteração deve aceita-las ou não.
  • Elaborar as User Stories: A elaboração das user stories deve acontecer antes do planejamento das iterações. Durante a iteração corrente, o PO define as stories da próxima (grooming backlog). Qualquer membro do time pode escrever ou apoia-lo na elaboração das stories, mas lembrando sempre que a responsabilidade sobre as stories é do Product Owner.
  • Definir ou apoiar na definição dos Critérios de Aceitação: User Stories devem possuir seus respectivos critérios de aceitação, que descrevem as formas de usar a funcionalidade implementada. O objetivo é validar se a user story foi implementada de acordo com o que o PO deseja. Também apoia na especificação dos testes de aceitação fornecendo exemplos no caso de ATDD (Acceptance Test Driven Development).
  • Participar da Demonstração e Retrospectiva: Como membro integral do time, e o principal responsável pelos requisitos, o Product Owner tem uma papel importante na cerimônia de Demonstração que ocorre no final da iteração, revisando e aceitando as stories na baseline da Release. Também participa na Restrospectiva onde o time discute as melhorias no processo.

Escalando o Scrum através do SAFe

Sabemos que nossos projetos de desenvolvimento possuem fatores que podem tornar o trabalho muito mais complexo e difícil:

  1. Tamanho do time ;
  2. Distribuição Geográfica;
  3. Complexidade, rigidez e tamanho da organização;
  4. Requisitos de Compliance;
  5. Distribuição das atribuições (outsourcing, parceiros externos);
  6. Complexidade técnica.

Assim, questionamos quanto ao uso isolado do método Scrum:

“Como utilizar o scrum se eu tiver vários times no meu projeto ?”

“Como organizar as dependências e sincronizar o trabalho destes times ?”

Nesse caso, precisamos de uma maior governança e complemento às práticas do Scrum, podendo ser utilizado um outro framework chamado SAFe.

Figura 2 – SAFe Agile Framework

http://www.scaledagileframework.com/

alt

O SAFe foi criado por Dean Leffingwell, ex. Vice Presidente da Rational Software (atualmente uma divisão IBM), com as responsabilidades que incluiam o desenvolvimento e comercialização do Rational Unified Process (RUP), Rational Clearquest e Rational RequisitPro. Dean possue algumas publicações como “Managing Software Requirements”, “Scaling Software Agility” e sua mais recente publicação “Agile Software Requirements” (eu recomendo).

O SAFe fornece um conjunto de práticas, devidamente experimentadas, para ajudar grandes organizações a tratarem os fatores de escala nos seus projetos.

Leia mais sobre SAFe na comunidade IBM DevOps em : https://goo.gl/23AB1q

Como o SAFe nos ajuda a escalar o Product Owner ?

Principalmente nos grandes programas, precisamos ter alguém com a responsabilidade em garantir o retorno do investimento e benefícios do produto além da garantia da entrega do software.

O SAFe (Scaled Agile Framework), define o papel do Product Manager, também conhecido como Chief Product Owner. Descrevo aqui de forma resumida as principais responsabilidades do Product Manager:

  • Possuir a visão do portfólio para melhor entendimento dos objetivos das Releases. Participa e possui a visão da carteira de Iniciativas, Orçamentos, etc.
  • Definir e comunicar a Visão e Roadmap do Programa para melhor direcionamento das Releases ou ART (Agile Release Trains). Responsável pelas features do programa, possue uma visão unificada do escopo e trabalha em conjunto com os Product Owners na elaboração da Visão e Roadmap. O Product Manager, deve possuir a “Visão da floresta” enquanto que os Product Owners estão mais focados com os requisitos dos seus times.

Figura 3 – SAFe – Roadmap de Features

alt

  • Definir, priorizar e comunicar o backlog do Programa que é composto de features com seus respectivos critérios de aceite.
  • Planejar a Release em conjunto com os Product Owners dos times, avaliando a prioridade e o mapa de dependências das user stories para a entrega das Features.
  • Participar da Demonstração da Release que ocorre no final da Release, após o encerramento da Release, mede o valor de negócio entregue x planejado.

Você consegue imaginar um programa com 4 times ágeis sem ninguém tendo a visão do todo ? Como ficariam as dependências dos trabalhos entre esses times ? E a prioridade, quem iria pensar na prioridade das entregas do programa ? Isso faz sentido para você ?

Para ajudar no entendimento, segue então uma tabela resumo das principais diferenças nas atribuições do Product Owner e o Product Manager:

Figura 4 – Product Owner e o Product Manager

alt

O Product Owner continua responsável pelo backlog e planos de sprint do time composto pelas user stories e tarefas. Dessa forma podemos então governar os grandes projetos e programas em diferentes níveis desde o mais granular com stories e tarefas até a um nível mais gerencial e executivo através das Features e Epicos de Négocio.

Figura 5 – Rational Team Concert – Plano de Sprint / SAFe Agile Framework

alt

Product Owners e Product Mangers trabalham juntos. Da mesma forma que os times possuem suas cadências e cerimônias, todos os Product Owners devem sincronizar as cadências dos seus times e datas. Devem trabalhar em conjunto com o Product Manager se comunicando regularmente com uma relação de parceria, colaboração e confiança.

Conclusão

Como mensagem final, para encerrarmos esse artigo, vale compartilhar algumas dicas importantes para você se tornar um bom Product Owner:

1) Seja um Product Owner presente. Comprovadamente uma das principais causas de falha em projetos ágeis é a ausência do Product Owner nos times. Não seja somente um participante no início e final das iterações.

“Pessoas de negócio e desenvolvedores devem trabalhar juntos diariamente” (Manifesto Ágil #4) –

2) Mantenha uma relação de parceria com seu time. Não assuma o papel de “cliente” ou “gerente de projeto” que vive de cobrança, não trate seu time como um “fornecedor” que deve tirar o máximo de trabalho. Confie no seu time e seja uma parte da unidade colaborando o máximo possível. Confiança é a chave!

3) Não tente ser o herói e trabalhar em vários times ao mesmo tempo. Um Product Owner pode suportar no máximo 2 times (*Ref.scaledagileframework)

4) Um Product Owner nunca pode ser o Team Lead (Scrum Master). Ambos tem interesses e hábitos completamente diferentes.

5) Não queira ser o “dono” do time, assim como o Team Lead (Scrum Master), o Product Owner não possui hierarquia sobre o time enquanto exerce seu papel, sua força é conhecimento e argumentação, mantendo sempre o foco para atingir o máximo valor para o negocio de forma equilibrada e sustentável. Não use “eu” ou “eles”, sempre procure usar o “nós”. Se o time falhar, você falha junto.

E para encerrar, essa vai para o time: Se você acha que seu Product Owner não possui nenhuma dessas habilidades, você deve se encarregar em construir e ajuda-lo a tornar-se um excelente Product Owner. Lembre-se que Product Owner inexperiente é diferente de Product Owner ruim. Procure fazer com que ele seja parte do seu time sempre…

Glossário de Termos:

Stakeholder = Um stakeholder pode ser um usuário direto ou indiretamente afetado pela soluçao entregue.

User Stories = User Story ou “história de usuário” é uma descrição de uma necessidade ou funcionalidade do usuário do produto (ou seja, de um “requisito”) sob o ponto de vista desse usuário.

Spikes = A Spike é um tipo especial de user story utilizado para atividades como pesquisa, exploração ou prototipação para obter o conhecimento necessario ou reduzir um risco de uma determinada abordagem tecnológica.

Backlog = O Product Backlog é uma lista contedo todas as funcionalidades desejadas para um produto.

Features = A feature são funcionalidades de um sistema que atendem a uma ou mais necessidades dos stakeholders, são armazenadas no backlog do Programa e alocadas para as Releases.

Épicos de Negócio = Os Épicos de Negócio ,diferentes do conceito de Épicos do Scrum, são grandes iniciativas da organização organizadas em portfólios e backlogs e priorizadas no nível de negócio considerando o potencial ROI para implementação.

Roadmap = O Roadmap fornece uma visão de todos entregáveis de um grande projeto ou programa, contemplando as features priorizadas na linha do tempo.

Backlog Grooming = O Grooming do Backlog consiste na tarefa de organizar os itens de um determinado backlog.

Refactor = Prática da metodologia XP, trata-se do ato de reescrever e organizar um código de forma mais elegante, clara sem alterar sua funcionalidade

ART = Agile Release Train consiste de um conjunto de times de um determinado programa que utilizam a mesma cadêcia para continuamente definir, construir, testar e entrega valor para o negócio

Referências:

Aproveite para conhecer o Rational Team Concert (RTC) e como ele suporta o SAFe:

https://goo.gl/KlgAr9

10 desenvolvedores de RTC free license

https://jazz.net/products/rational-team-concert/

Comunidade IBM DevOps – SAFe:

http://goo.gl/KVRo18

Manifesto Agil

http://agilemanifesto.org/iso/ptbr/

Guia do Scrum

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf

SAFe Framework site:

http://www.scaledagileframework.com/