O documento discute a importância de entregas frequentes de software funcionando para obter feedback dos usuários, citando pesquisas que mostram que 52% dos projetos de software falham ou excedem o orçamento. Ele também descreve como a equipe mudou suas práticas de revisão para envolver mais os usuários finais e validar o trabalho em produção, ao invés de apenas no final das sprints.

1. Validando soluções no governo

2. Entregar frequentemente software
funcionando, de poucas semanas a
poucos meses, com preferência à
menor escala de tempo.
Manifesto Ágil
http://agilemanifesto.org

3. A Review é executada no final da
Sprint para inspecionar o
Incremento...
…é uma reunião informal, não uma
reunião de status, e a apresentação
do Incremento destina-se a obter
feedback e promover a
colaboração.
Scrum Guide
http://www.scrumguides.org

4. Mas por que entregar frequentemente
e
obter feedback?

5. 52%
19%
29%
Standish Group 2015 Chaos Report

6. Standish Group 2013 Chaos Report
Nunca
Raramente
As vezes
Sempre
45%
19%
16%
20%

7. Fazíamos Reviews para o “nosso” PO

8. Fazíamos Reviews com o cliente no papel
passivo (pseudo feedback)

9. Fazíamos Reviews no final da Sprint
Quando este
ítem ficou
pronto?
Terceiro dia
de Sprint!
Doze dias de
desperdício!

10. Mudamos as tradicionais Reviews para entregas
com os usuários em seu local de trabalho

11. Começamos a fazer Reviews em produção com
trabalho real

13. envolvemos os
gestores
nas entregas que
exigem visão
estratégica

14. usamos a
tecnologia a
nosso favor

15. usamos
OKRObjective, Key Results
para validar os resultados

16. Outras dicas
Utilize
ice breakers
nos
momentos
mais tensos
Faça acordos no
momento da entrega
Use dados
reais para
demonstrar
o software

17. Celebre as
conquistas
junto com
o cliente

18. Trabalho pronto é trabalho em produção!
Obrigado
@stefanohs
stefanohs@gmail.com