Como lhe dar com mudanças contínuas?

Edmiel, tudo bom?

Acho importante destacar a sua frase: "que fica difícil confrontar o cliente com outra perspectiva do problema". Quando usamos o método tradicional a mudança se torna algo sofrido, onde equipe e cliente entram numa disputa entre o que foi pedido e o que o cliente realmente precisa. Lembrando, nem sempre o cliente sabe no início o que quer (geralmente ele sabe o que precisa resolver) e nem sempre o mundo fica parado esperando o sistema nascer.

A equipe não deve ficar frustrada com as mudanças, principalmente se elas são acordadas e ocorrem nos momentos certos. Sem atrapalhar os time boxes definidos. O Scrum Master deve estar atendo a isso. E claro, a organização como área de negócio deve estar atenta para que essas mudanças não firam o contrato.

No seu caso acho que não está claro ao cliente o que é ser ágil, as funcionalidades que devem ser desenvolvidas, a ordem em que elas devem ser desenvolvidas e a movimentação das alterações nesse backlog. Imagine que o PO tem duas ou três Sprints na frente de forma clara ao cliente. Na Review, quando a equipe apresentar o que foi feito, ele rejeitar, o backlog será reorganizado e repriorizado e ele verá que há um impacto com aquela alteração. O que sendo transparente para todos não tem problema algum.

Outra coisa, você tem alguns pontos de ágil e pelo que entendi ainda não adotam o Scrum, por exemplo, de forma plena. Talvez esteja na hora de usar o framework corretamente para finalmente terem um método de trabalho.

Algo que poucas pessoas falam, nem todos aceitam que a metodologia ágil é melhor para o seu produto e têm dificuldades em entender seu valor. Tudo bem. O papel da equipe é tentar mostrar isso ao cliente, mas tem horas que simplesmente não rola. O que fazer? Sugestão. Adotar o método tradicional, ao contrário do que dizem ele entrega sim software, mas de uma maneira engessada. Quando um cliente assina um documento de requisitos pode voltar atrás, com uma change request (requisição de mudança). Ou seja, tudo documentado e acordado formalmente.

Bem, se isso te ajuda, por favor, marque a resposta como solução. Assim ela sai da lista de questões sem solução do fórum. E qualquer dúvida só mandar.

Entendi bem o que você quis dizer, porém como fazer isso em equipes muito reduzidas que não dispõem de um scrum master ou algum tipo de agilista? Nessa empresa em específico são menos de 10 pessoas, cada pessoa no projeto é responsável por muitas atividades. Tendo em vista as limitações, existe pequenos passos que possamos dar em direção a algo ideal?

Uma equipe Scrum tem entre 3 e 9 pessoas, então vocês poderiam se organizar. Mesmo as pessoas fazendo muitas coisas, aliás, ser multidisciplinar é uma das características dos membros do time Scrum.

Outra forma é criar um Kanban com as demandas, A fazer, Fazendo e Feito, talvez colocar uma coluna bloqueada. Com isso você pedem para que o cliente organize as demandas, discutam com ele quando houver algum impeditivo técnico para a demanda, com isso ele passa a participar mais da organização dos trabalhos, e perceberá que quando uma tarefa é feita, refeita, ou jogada fora tem impacto na produção.

Essa aspecto visual ajuda muito o cliente a criar uma empatia com a equipe. Afinal, todos ali tem o mesmo objetivo: entregar o melhor produto possível.

Não esqueça de deixar essa questão como solucionada para que ela saia da lista de questões sem solução do fórum.