Definition of Ready, agora escalado

Há alguns anos entendemos que entender o que é pronto em uma entrega é ponto inquestionável. Um conceito que permeia toda a agilidade.

A tal frase “mas na minha máquina funciona” não faz mais sentido para nossos padrões avançados de uso de métodos e frameworks. Do mesmo modo que times de alto desempenho aumentaram seus conhecimentos e expertise técnica, também aumentaram o nível de exigência na qualidade de entrada de requisitos que direcionarão uma iteração.

Práticas como “Refinement Backlog”, uma reunião que pode acontecer duas ou três vezes em uma semana, com objetivo de clarificar o entendimento de um item de backlog entre P.O. e time é cada vez mais usual, tornando as Sprint Planning Meeting assertivas.

No entanto, práticas como “Refinement Backlog Meeting”, escrita de Definition of Done (DoD) e Definition of Ready são comuns em times que tiveram alguns ciclos de aprendizado completos. Ou seja, experimentaram as dores de conviver com um backlog sem granularidade, as dores de ter uma Sprint falha ou até mesmo cancelada por falta de entendimento do que era pronto para entrega e só então entenderam a importância desses acordos e encontros.

Em 2012, Alexandre Magno escreveu aqui no Blog sobre essas tais dores:

“Uma reclamação frequente de times de desenvolvimento (Dev Team) em Scrum é que, com o discurso de agilidade, requisitos chegam nas Sprints com baixa qualidade. Não é difícil encontrar Product Owners que mantém no topo do Product Backlog itens com granularidade ruim, pouco (ou nenhum) detalhamento e – pior – baixo entendimento do próprio Product Owner sobre o que está sendo pedido. Isso, na maioria das vezes, transforma a Sprint Planning Meeting em uma reunião arrastada e com muitas perguntas não respondidas. Consequentemente, times fazem um planejamento de baixa qualidade e são surpreendidos ao longo das Sprints com impactantes descobertas do Product Owner sobre aquele item, o que resulta em mudanças no objetivo e desenvolvimento. Resultado: Time desmotivado. Sprint não consegue atingir meta. Product Owner insatisfeito com o time. Sistema em colapso.”

E nos esclareceu sobre o uso dos dois acordos de trabalho DoD e DoR, nos exemplificando o uso:

Requisitos Ready se transformam em entregáveis Done

Uma prática que tem ajudado bastante nestes casos é a adição ao Scrum do conceito de “Definition of Ready”. Este conceito age de forma bem parecida com a conhecida “Definition of Done”, mas enquanto “Done” garante qualidade na saída da Sprint, “Ready” garante qualidade na entrada da Sprint.

Um exemplo de Definition of Ready

Uma “Definition of Ready” precisa ser capaz de expressar o mesmo significado para todos que a leem, principalmente Dev Team e Product Owner. Um exemplo:

Um Product Backlog, que aqui trataremos como Team Backlog Itens está Ready quando:

– Está escrito como uma User Story INVEST;
– Possui um Teste de Aceitação automatizável;
– Possui um Wireframe de baixa fidelidade;

Caso você trabalhe com itens de diferentes tipos no seu Product Backlog, como por exemplo: itens de negócio, itens técnicos, spikes, bugs, etc., você pode optar por ter uma Definition of Ready diferente para cada um deles; afinal de contas pode não fazer sentido gerar um Wireframe para um Spike intitulado “Escolha de solução para Pagamento de Cartão de Crédito”, certo?”

Nos dias atuais está cada vez mais comum precisarmos entender esses conceitos em escala.

Profissionais que atuam em empresas que vem utilizando o SAFe como seu framework de escala ágil carregam o desafio de levar este conceito para além times de desenvolvimento ágil. Precisam deixar claro para Product Managers, Business Owners e demais envolvidos na entrega final de um produto o que esperam ver concretizado como produto pronto.

Por sua vez, times ágeis que trabalham em paralelo entre si e com times de sistemas, infraestrutura, arquitetura e devops precisam se fazer entender e estar alinhados quanto ao que necessitam como requisitos para produção do produto final.

Já sabemos, “Quem tem a responsabilidade de tornar um item Ready, em um único time ágil?

A responsabilidade é do Product Owner, mesmo que para isso precise envolver outras pessoas. Enquanto o Dev Team trabalha, por exemplo, na Sprint 3, o Product Owner tem que garantir que os itens do topo do Product Backlog estejam Ready para a Planning Meeting da Sprint 4. Caso ele precise envolver o Dev Team neste trabalho, seria interessante “oficializar” reunião(ões) de “Refinement”(no texto original era citado o “Grooming” – porém por respeito à alguns países de língua inglesa, que utilizam a palavra com conotação ruim de assédio infantil, a substituição tem sido mais do que recomendada) que já fossem previstas no TimeBox da Sprint.

O uso de “Definition of Ready” não está limitado ao Scrum, e pode ser muito útil também quando trabalhando com Kanban e outros métodos. (Alexandre Magno – 2012).

Agora a nova pergunta se repete para escala. E essa mesma lógica da relação time <-> P.O. é utilizada pelo SAFe para produtos desenvolvidos com times escalados.

Para que vários times entendam qual a expectativa de Produto Pronto, de um Product Manager ou de Bussiness Owner, quem deve deixar os itens Ready?

Um P.M. (Product Manager) tem a missão de entender o produto, escrever e compartilhar essa Visão, o time-to-market ideal, o principal problema que este produto resolve com o Bussiness Owner, que entendemos normalmente como um diretor ou executivo patrocinador da ideia de um novo produto ou novas funcionalidades e mapear as primeiras métricas que funcionarão como feedback sobre o sucesso do produto.

Ou seja, esse P.M. é nosso P.O. escalado, atua no Program Backlog, que contém Features, entendendo-o, priorizando-o e refinando-o.  No entanto, pela complexidade e tamanho do produto, não mais sozinho, ele tem um time. O time de P.Os., que transformará seu entendimento sobre as funcionalidades do produto em requisitos granulares, refinados e priorizados para alcance do time, as user stories.

Um time ágil entrega pronto itens do Team Backlog em uma iteração, aqui temos um nível de Definition of Done e Definition of Ready. Vários times ágeis terão suas entregas integradas para um novo incremento de produto, ou incremento do sistema, aqui temos um próximo nível de Definition of Done e Definition of Ready.

• Veja um exemplo dos níveis de Definition of Ready citados:

Então o P.M. tem uma visão de uma ou mais Features (funcionalidades) prontas, mesmo que estas sejam desenvolvidas por mais de um time trabalhando ao mesmo tempo. O que nos dá ganho de time-to-market. Essa visão deve ser compartilhada entre todos os P.Os., Scrum Masters e times de desenvolvimento. E, pensando SAFe, essa Visão também deve estar compartilhada com os demais comprometidos com a entrega: como arquitetos, RTE, devops, system team, time de lean-ux e outros. Todos entendem a expectativa de produto pronto e sinalizam o que deve estar “ready” para a completar entrega.

Percebemos então que na medida que o ágil cresce em aplicação dentro de uma corporação e a necessidade de coordenação escalada também cresce, as práticas de qualidade devem acompanhar este crescimento. Por isso recomendamos o DoD e DoR em dois níveis.

Como sua corporação está aplicando e escalando estes acordos de trabalho? Compartilhe conosco nos comentários.