Se você está iniciando a sua jornada no SAFe e está com dúvidas relacionadas a Review e System Demo este artigo é para você. 

Antes de fazermos um paralelo entre Review e System Demo vale lembrar que nenhuma delas é uma reunião de validação.  

É um momento de demonstração e troca de feedbacks.

Portanto, ao invés de executar uma bateria de testes (automatizados ou não) é muito mais importante “pilotar” as novas funcionalidades e deixar as pessoas de negócio degustarem a solução, o que nos dá a oportunidade de uma conversa muito interessante.

Veja o comparativo abaixo entre Review e System Demo: 

Comparativo_Review_e_System_Demo

E se não fizermos a System Demo? 

Isto pode levá-lo a caminhar vendado por uma pista repleta de surpresas e obstáculos. 

Lotes grandes e alta variabilidade 

Quanto maior o lote de trabalho, maior será a sua variabilidade. Mais difícil será manejar problemas e gerenciar a qualidade. 

Pense que você precisa encontrar um grão de arroz estragado, qual cenário você prefere trabalhar? 

Cenário A – 50 gramas de arroz. 

Cenário B – 5 Kg de arroz 

Você certamente escolheria o cenário A. Afinal de contas pode ser muito mais rápido você encontrar esse “arroz estragado” em um pequeno lote, digamos assim. 

A questão é que negligenciar o tamanho do lote pode significar você ter que trabalhar em um Cenário C,  

Não sei quantos grão de arroz estragados tem em 5 Kg, mas preciso remover todos. 

Tudo isso afeta a execução do programa. Lotes grandes além de gerar incertezas, podem gerar correções não previstas, problemas de integração, questionamentos e validações extensas, o que normalmente significa baixar a velocidade do seu “trem”. 

Se não demonstramos, as pessoas de negócio não sabem como a solução está indo.

Elas passam a ter uma percepção de evolução baseada em reports, planilhas e pdfs. Esta sensação de que tudo parece estar indo bem nós chamamos de “falso positivo”.  

Transparência

A melhor forma de saber se estamos no caminho certo é ver a evolução do produto.

Isto está no Manisfesto Ágil.

Qualquer outro artefato ou métrica é interessante e agrega novas perspectivas, mas nada é melhor do que pilotar a solução. 

PD.. sem CA 

Umas das críticas que tanto se faz aos modelos tradicionais é a dificuldade em executar o ciclo PDCA

Com o SAFe, temos esta oportunidade devido aos pequenos ciclos. 

Assuma o PDCA como algo não só de times, mas de todo o ART

A oportunidade de Check e Ajuste precisa ser de todos, porque o objetivo não é entregar pequenas partes de software, e sim gerar valor para o cliente. 

Bom, espero que este artigo tenha te ajudado. Deixe seus comentários. Abraços!

Rodrigo Costa

Atuo diretamente na transição e experimentação ágil em diferentes organizações. Experiência profissional em TI em diversos segmentos, minhas principais certificações: SPC4 (SAFe Program Consultant), SAFe Agilist (SA), SSM e POPM pela Scaled Agile; ICP (Instructor Authorization) e Certified Agile Professional pela ICAgile.

Este post tem 3 comentários

  1. Noel Portugal

    Parabéns pelo texto Rodrigo!

  2. .

    Perfeito timing em que estou lendo seu post. Como scrum master, esse mês assumi um novo time na empresa. Ao contrário do que o texto sugere, eles só faziam a demo, e dispensavam a iteration review. Fiquei confusa ao saber disso, porque é
    na review que o time consegue concretizar a entrega da iteração. Vou usar seu post pra esclarecer a eles que os dois eventos são importantes! Obrigada, Rodrigo!

    1. Noel Portugal

      Que ótimo Jú, muito obrigado pelo seu comentário. Abraços!

Deixe um comentário