O porco e a galinha: responsabilidades em times ágeis

Quando comecei a estudar Scrum em 2010 havia pouco tempo que a primeira versão do Scrum Guide havia sido lançado e o professor que me treinou era o segundo da América Latina autorizado pela Scrum.org. Ainda guardo o material do treinamento e nele tem a fábula do Porco e da Galinha, que mais tarde em 2011 seria removida dos materiais oficiais do Scrum (ao que parece isso estava criando algumas disfunções).

Se você não conhece a fábula, dê uma olhada na tirinha abaixo.

O Porco e a Galinha
O Porco e a Galinha

Nela, a galinha convida o porco para abrir um restaurante, que se chamaria “Pernil com Ovos” (eu prefiro usar bacon no lugar). O porco recusa pois neste caso ele estaria comprometido com o projeto enquanto a galinha estaria apenas envolvida (afinal o porco se sacrifica, enquanto a galinha põe o ovo e sai fora).

Esta fábula era muito usada para designar não apenas comprometimento literal, mas responsabilidade sobre determinado assunto ou aspecto do processo de desenvolvimento de software com Scrum. Claro que todos os envolvidos no projeto são responsáveis em maior ou menor grau pelo sucesso do mesmo e justamente por isso em Inglês não se usava nessas situações a palavra responsible mas sim accountable. Você sabe a diferença?

Basicamente a responsibility (responsabilidade) pode ser compartilhada, enquanto que a accountability (responsabilidade também, mas em um sentido de prestar contas) não.  Logo, se você é accountable em algum aspecto do projeto, você está commited (comprometido) com o mesmo em altíssimo grau e seu bacon está em jogo!

No Scrum, em diversos momentos ou sob diversos aspectos temos diferentes porcos e galinhas. Como vejo que muitas vezes os times se atrapalham com isso e são questões que caem em prova de certificação, resolvi montar uma espécie de matriz RACI com diversos elementos presentes no Scrum Guide.

Como eu considero o conceito de porcos e galinhas muito mais lúdico e divertido do que o conceito oficial pra matriz de responsabilidades, vou usar apenas as letras P e G ao invés das quatro originais (R, A, C e I).

Note que a matriz foi construída usando única e exclusivamente o conteúdo presente no Scrum Guide. Interpretações à parte, cada time acaba encontrando a sua maneira de trabalhar, mas como queria uma representação fiel ao Scrum Guide, construí ela dessa maneira. Caso busque uma abordagem mais emergente e colaborativa com seu time, você pode usar a dinâmica do “É/Não É/Faz/Não Faz” do Rafael Sabbagh, que explico no artigo sobre Lean Inception ou a variante do Andy Barbosa: “É/Não É/Faz/Não Faz/Pode/Não Pode”.

Como o primeiro pilar do Scrum é a transparência, nada mais justo de que o papel, os direitos e os deveres de cada membro do time esteja explícitos e que, cada um fazendo a sua parte como esperado, todos chegaremos no sucesso desejado.

Logo mais abaixo, as matrizes e suas interpretações.

Cerimônias

A matriz PG (Porcos e Galinhas) das cerimônias do Scrum fica assim.

PG Cerimônias
PG Cerimônias

Eu dividi a planning em duas partes, assim como citado no guide, uma vez que na primeira parte o PO é o elemento central, trazendo os inputs que são os itens do Product Backlog priorizados. Na segunda parte, o porco vira o Dev Team, que tem de definir o que cabe na sprint e como pretende desenvolver cada um dos itens. É citado no guide que stakeholders ou consultores podem aparecer, caso necessário, para serem ouvidos (ou seja, galinhas).

A Daily Scrum, ao contrário da crença popular é uma cerimônia para o time de desenvolvimento se sincronizar, comparando sempre com o Sprint Goal. Outros participantes, se aparecerem, não devem bagunçar a cerimônia e esse é um conceito que muitas vezes cai na prova de certificação. O SM deve garantir que ela aconteça e que não exceda os 15 minutos, uma vez que isso esteja ok, ele é dispensável.

A Review é o Dev Team apresentando o Incremento para o Product Owner e stakeholders (idealmente). Eu adoraria colocar os stakeholders como porcos aqui, para lhes dar mais responsabilidades, mas entende-se no Scrum que somente membros do time Scrum são porcos.

E por fim, a Retrospectiva é de responsabilidade do time Scrum como um todo. Se eu tivesse que elencar um responsável eu colocaria na conta do Scrum Master, mas o guide sugere diferente, dizendo que ele deve ser tratado como um “peer member” nesta cerimônia.

Note que, ao contrário do que muitos acham, o Scrum Master não é o porco das cerimônias, ele é apenas o facilitador, devendo garantir que as mesmas aconteçam e sejam produtivas, para o bem do próprio time e não para benefício próprio.

Artefatos

A matriz PG dos artefatos do Scrum fica assim.

PG Artefatos
PG Artefatos

Aqui temos um assunto bem menos polêmico e menos complicado também. O PO é dono do Product Backlog e somente ele mete a mão lá (inclusive os stakeholders ficam de fora dessa gestão, embora opinem). Já quando pegamos uma fatia do PB, o Dev Team constrói e mantém o Sprint Backlog durante toda a vida da sprint, gerando na sequência o Incremento, DONE conforme a Definition of Done, também de sua autoria.

O Scrum Master “apenas” garante que tudo isso seja seguido e ensina boas práticas e técnicas, especialmente para o P.O. conseguir lidar com o backlog de forma eficiente.

Outros Aspectos

Como as duas matrizes anteriores não lidam com todos os pormenores do Scrum no que tange responsabilidades, fiz mais uma envolvendo outros aspectos do framework que devem ajudar no dia a dia de quem é novato no assunto.

PG Sprint
PG Sprint

Aqui temos o reforço de alguns conceitos como o P.O. sendo o porco das prioridades e do ROI do produto que está sendo desenvolvido, mas traz aspectos menos conhecidos como o fato dele ser a única pessoa que pode cancelar uma sprint, no caso do Sprint Goal se tornar obsoleto. Goal esse definido pelo Time Scrum durante a Sprint Planning.

Para o Scrum Master vêm as responsabilidades clássicas como facilitar cerimônias, ensinar e melhorar continuamente o processo e remover impedimentos que possam estar atrapalhando a performance do time. Este último, um tanto polêmico em alguns times, envolve a fina arte de equilibrar o aspecto “facilitador” do aspecto “babá” que alguns times acabam se acostumando. E sim, o Scrum Master é o “servant leader” do time Scrum e ele é o único papel mencionado como líder (não confundir com gestor).

E por fim, o Dev Team se auto organiza (dividindo e distribuindo suas atividades) bem como decide como transformará os itens do backlog em um incremento de software através de técnicas de UX e Engenharia de Software disponíveis no mercado e que um bom time multifuncional deve ter entre seus membros.

Espero ter ajudado!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

A evolução do Scrum

No artigo de hoje vou falar um pouco da história do Scrum e da sua evolução desde a sua criação até hoje e para onde acredito que o mercado está seguindo em termos de agilidade. Essa história é melhor trabalhada no livro Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo de Jeff Sutherland e outras publicações menos conhecidas.

A Inspiração

Vale lembrar que durante a Crise do Software da década de 70 muitos profissionais de projeto e de tecnologia estavam empenhados em criar métodos e processos a fim de aumentar o grau de sucesso dos projetos à época. A Engenharia de Software moderna se originou deste movimento e metodologias tradicionais como o Waterfall e mais tarde o processo Iterativo Incremental se consolidaram neste período como formas “corretas” de se fazer software.

No entanto, conforme a tecnologia avançava, a digitalização das empresas começava a aflorar e os projetos se tornavam cada vez mais complexos e dinâmicos em um mundo globalizado, isso não bastou. Em 1986 a dupla de professores de Harvard, Takeuchi e Nonaka, escreveram o famoso artigo The New New Product Development Game onde relatavam o resultado da sua pesquisa com algumas das mais bem sucedidas empresas à época. Essa pesquisa buscava entender porque os produtos destas empresas se saíam tão bem, uma vez que a maioria dos projetos até então não estavam sendo bem sucedidos.

Não entrarei em detalhes sobre o artigo em si, que linkei acima que você pode ler na íntegra, mas este artigo inspirou engenheiros como Ken Schwaber e Jeff Sutherland a criarem novas formas de fazerem a gestão dos projetos de software. Em 1995, Ken Schwaber submetia o artigo SCRUM Development Process para a OOPSLA daquele ano, uma conferência sobre desenvolvimento orientado a objetos.

Assim nascia o Scrum, mas bem diferente de como é hoje.

A primeira versão do Scrum

Inúmeras são as diferenças da visão inicial de Ken Schwaber em relação ao que o Scrum se tornou anos mais tarde. Primeiro, ele era descrito como um processo de desenvolvimento, o que mais tarde se transformou em um framework. Talvez você já tenha ouvido falar isso, mas você sabe qual a diferença?

Um método ou processo é algo prescritivo, que deve ser seguido nos mínimos detalhes para que funcione. Já um framework é uma estrutura oca, onde você pluga novos componentes e o usa como base para evoluir para algo que supra a sua demanda. Scrum te dá apenas linhas gerais como base, logo não é um processo, caso contrário seria um processo incompleto.

Também nessa primeira versão, que você pode ler aqui, existiam apenas dois papéis: o Manager e o Development Team. O Manager era descrito como um Product Manager, mas que tinha também funções de Project Manager, o que obviamente o tornava quase um deus dentro do time e ao mesmo tempo alguém sobrecarregado. Anos mais tarde, Ken e Jeff quebrariam este papel em dois, além de evoluir suas funções como Product Owner e Scrum Master.

Os artefatos à época eram oito, o que mais tarde se reduziu pela metade:

  • o clássico Backlog (hoje quebrado em dois) mais as Issues;
  • Release/Enhacement, atualmente chamado de Incremento;
  • Packets, Changes e Problems, hoje todos incorporados no Incremento;
  • Risks e Solutions, não mais evidenciado de maneira diferenciada hoje;

E por fim, uma sprint à época possuía as seguintes fases (hoje cerimônias, eventos ou timeboxes, como preferir):

  • o Pregame, composto por Planning e Architecture (as mesmas duas etapas da Sprint Planning atual);
  • o Game, o desenvolvimento da sprint;
  • o Postgame, com testes, documentação, preparação para release e a dita cuja.
Scrum v1.0
Scrum v1.0

Note como isso não era exatamente um método ágil moderno, uma vez que não previa melhoria contínua (com a Retrospective atual) embora citasse algum grau de transparência com uma menção à Review atual Também não é explícito que estas fases devam acontecer a cada sprint, e entendia que uma vez feito o Pregame, poderiam acontecer diversas sprint de desenvolvimento (Games) e depois um único Postgame para fechar o pacote.

As versões posteriores

Mais tarde, com Ken se aliando a outros engenheiros importantes e com a própria publicação do Agile Manifesto em 2001, o Scrum ganhou força e tivemos uma grande publicação que descrevia sua implementação em mais detalhes, fruto da parceria de Ken com Mike Beedle, o livro Agile Software Development with Scrum, em 2001 mesmo. No entanto, como descrito no livro, o Scrum teria sido criado como uma forma de fazer com que o Extreme Programming (XP) pudesse ser aplicável nas empresas.

Ou seja, Ken Schwaber e Mike Beedle eram fãs do trabalho de Kent Beck, o que mostra como essa galera estava compartilhando conhecimento e bebendo uns nas fontes dos outros naquela época.

Depois em 2004 veio novo livro de Ken Schwaber de como aplicar Scrum na gestão de projetos, o Agile Project Management with Scrum. Diferente do seu antecessor, mais focado em engenharia, este último era para o público de projeto, provavelmente oriundo da incompatibilidade dos métodos de gestão tradicionais com a nova abordagem de desenvolvimento.

Finalmente em 2010 surge o Scrum Guide, o guia que se tornaria a fonte oficial (e enxuta) de informação sobre Scrum. Foi nessa época que aprendi sobre métodos ágeis a primeira vez e quando li o guia, que tinha 32 páginas (hoje tem 19). Aqui o Scrum já estava bem mais próximo da versão atual. De lá pra cá apenas se apararam algumas arestas como por exemplo:

  • maior foco no Sprint Goal, principalmente na Daily;
  • o Incremento se tornando um artefato oficial (voltando às origens);
  • o Burndown Chart deixando de ser um artefato oficial;
  • criação dos Valores do Scrum;

Entre outras mudanças menores.

Em 2012, o famigerado Software in 30 Days foi lançado por Ken e Jeff. Famigerado porque, assim como “Scrum: Arte de fazer o dobro do Trabalho na Metade do Tempo” de 2014 (este somente pelo Jeff), este livro é muuuito marketeiro, o que gera críticas por fazer um desserviço à comunidade ágil uma vez que ilude manager inescrupulosos, criando falsas expectativas que geram mais pressão sobre os times. Mas enfim.

Em 2016 eu lancei o meu livro sobre o assunto, visando preencher as lacunas que eu fui encontrando ao longo dos anos com técnicas e artefatos de outros autores e que fizeram (e ainda fazem) sentido para os times ágeis que eu liderei ao longo dos anos trabalhando com Scrum.

O futuro do Scrum

Pesquisas como a State of Agile e a State of Scrum indicam que nunca o Scrum foi tão popular nas empresas. Não somente nas que se autoproclamam ágeis, mas também em maior ou menor grau até mesmo em empresas tradicionais, sendo que células independentes de muito empresa jurássica usa Scrum atualmente. Isso mostra o Scrum como um framework mainstream para desenvolvimento de produtos complexos, o que é evidenciado pela tendências apontadas pela InfoQ ano passado, o qual eu reproduzo a imagem abaixo.

InfoQ Trends
InfoQ Trends

Note que o que esta imagem mostra é que os métodos ágeis mais tradicionais, os que estamos acostumados, já estão sendo adotados na categoria de empresas Late Majority. Isso não significa que Scrum está caindo em desuso, muito pelo contrário, que jamais foi tão utilizado na indústria de software.

No entanto, note o quanto de novidades temos à frente de nós e que só o Scrum por si não consegue dar conta. Ao invés de eu ficar especulando o que o futuro reserva para o Scrum, acho que vale a pena você dar uma olhada nestes tópicos aí para ver como as empresas mais tops do mercado estão trabalhando hoje, para quem sabe amanhã você puxar essas novas linhas na sua empresa.

Conforme eu mesmo for estudando e aprendendo sobre estes temas, tenha a certeza que estarei compartilhando aqui no blog.

Até lá!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Leituras recomendadas para Product Owners

Atualizado em 16/02/19 com duas traduções de livros e a nova versão de outro!

Desde a criação do Agile Manifesto em 2001 e a consequente popularização dos métodos ágeis no início deste século que eu tenho como o maior ganho promovido pelo modelo a aproximação da área de negócio das empresas com  área de TI das mesmas. Essa aproximação se dá em grande parte à obrigatoriedade do papel do Product Owner dentro dos Times Scrum, sendo esse o framework ágil mais difundido no mundo.

No entanto, para que essa conexão produza bons frutos é necessário que o papel do Product Owner seja respeitado e que o mesmo possua as skills necessárias para tanto. Mas que skills seriam essas?

Um Product Owner geralmente é um especialista na sua área de negócio, mas não necessariamente um especialista em métodos ágeis. No entanto, diferente de um Scrum Master ou de um Agile Coach que devem respirar métodos ágeis no seu dia-a-dia, um Product Owner deve respirar concepção e desenvolvimento de produtos de maneira ágil, tema central das leituras que recomendarei neste artigo.

Clique nos títulos ou nas capas para ver o livro na Amazon.

A Startup Enxuta

Obra máxima de Eric Ries, A Startup Enxuta (Lean Startup no original) já foi motivo de resenha aqui no blog e dispensa apresentações. Conceitos como MVP (Minium Viable Product), Contabilidade para Inovação e o ciclo Build-Measure-Learn são obrigatórios no repertório de qualquer Product Owner.

Business Model Generation

Este fantástico livro de Alex Osterwalder (até a edição é excelente, já fiz resenha aqui no blog) introduz o famoso Business Model Canvas, estrutura o raciocínio sobre a ideação de modelos de negócio inovadores e nos traz diversos cases de modelo disruptivos que empresas famosas descobriram para se reinventar.

Value Proposition Design

Outra obra-prima de Alex Osterwalder, desta vez ele nos introduz ao Value Proposition Canvas, uma poderosa ferramenta que auxilia os Product Owners a fazer a conexão certa entre o que os clientes desejam e o que o seu produto realmente deve ser.

Sprint

Ao contrário do que o nome sugere, este não é um livro de Scrum, mas sim um livro sobre o método usado no Google para testar e aplicar novas ideias em apenas cinco dias. É muito interessante de ler e aplicar, tendo sido escrito por Jake Knapp em parceria com membros do Google Ventures.

Reinvente sua Empresa

ReWork no original de Jason Fried, este livro é a versão parruda e mais moderna do recomendadíssimo Caindo na Real, escrito pelos fundadores do Basecamp. Não apenas promove uma mudança cultural na cabeça de quem lê, ele dá aos Product Owners um passo-a-passo de como orientar a criação de aplicações ágeis e que realmente atendem as necessidades dos clientes com menos pessoas e menos software.

Lean Inception
Lean Inception

 

Lean Inception

Paulo Caroli é um engenheiro de software e autor brasileiro que ficou famoso no mundo inteiro com a sua Lean Inception, um método de concepção de novos produtos muito alinhado aos conceitos do Lean Startup, permitindo que através dos métodos descritos em seu livro, empresas consigam definir os escopos de seus novos produtos em até uma semana de trabalho.

Scrum

O mais famoso livro sobre Scrum do mercado (ele aparece na minha lista de 6 livros recomendados para aprender agilidade), o “livro amarelo do Scrum” foi escrito por Jeff Sutherland, um dos criadores do Scrum e uma das figuras mais famosas em agilidade no mundo inteiro. Não é exatamente um livro que te ensina como dominar o framework, mas que te dá a base histórica e teórica do framework, seus princípios e como eles são aplicados em diversos contextos através de todo tipo de case. Essencialmente um livro sobre cultura ágil.

Comece sua Startup Enxuta
Comece sua Startup Enxuta

 

Comece a sua Startup Enxuta

O excelente Running Lean do Ash Mauriya foi traduzido como “Comece sua Startup Enxuta” e traz conceitos de outros livros como o Business Model Generation e o Lean Startup para outro nível, mais focado em produtos digitais e na realidade que os permeiam. Ele ajuda o profissional de produto ou empreendedor a parar de fazer conjecturas e validar suas hipóteses em campo, com ferramental sugerido pelo autor. Se eu pudesse resumir esse livro em uma frase seria: saia do escritório e vá falar com seus clientes.

Do Sonhos à Realização em 4 passos
Do Sonhos à Realização em 4 passos

 

Do Sonho à Realização em 4 Passos

Esse livro de Steve Blank (um dos maiores investidores e mentores do Vale do Silício) é o avô do movimento Lean Startup, tendo sido Blank o professor do Eric Ries (autor do Lean Startup). Neste livro ele introduz conceitos como Customer Discovery e Customer Development, trazendo à tona questões como a busca pelo Product-Market Fit e tantos outros conceitos importantíssimos para todos profissionais responsáveis pela criação de produtos no século atual. Apesar do nome tosco da tradução brasileira (o original é The Four Steps to the Epiphany ou Os 4 Passos para a Epifania) não é um livro de auto-ajuda e sim um método de validação e desenvolvimento de Product-Market Fit.

Agile Product Management with Scrum

Esta é uma obra-prima do guru dos Product Owners, Roman Pichler. É um livro que já foi traduzido pro Português mas que é bem difícil de achar a versão nacional, sendo bem mais fácil comprar o ebook na Amazon, embora um tanto salgado. Mas felizmente vale a pena cada centavo se você está investindo na carreira de PO. Roman fala do MMP (Minimum Marketable Product), fala de grooming, de planejamento de releases e ajuda de uma vez por todas a entender este importante papel dentro de times ágeis.

Esqueci algum livro que você gostaria de adicionar na lista? Me mande nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis