Olá Rubens,
geralmente os contratos de software tem 3 fatores: escopo, tempo e custo. Só que existe um 4 fator que está implícito no software que é a qualidade. O problema clássico é justamente que de todas eles, as empresas e/ou clientes tendiam a querer deixar o escopo fixo de qualquer forma, enquanto que as outras os outros 3 acabavam variando, principalmente a qualidade.
Então o resultado disso é que para entregar o escopo fechado, a qualidade do código era piorada ou então o custo e/ou o prazo aumentavam. Normalmente quem sofria era a qualidade. O resultado disso eram softwares lotados de bugs, com custo de manutenção extremamente altos e, por ser um escopo fechado, que não atendiam a necessidade do usuário.
Então nos contratos ágeis o que tentamos negociar (e convencer ao cliente) é de deixar os fatores tempo, custo e qualidade como fixos. O único que pode variar é o escopo. Uma forma de fazer isso é justamente estabelecer contratos de curta duração e que podem ser renovados.
Por exemplo, você pode estabelece um contrato com seu cliente com o tempo de duração de 1 mês e um custo X para este 1 mês de trabalho. E é prometido que a qualidade do software entregue é garantida e não será afetada. Neste um mês de contrato é estabelecido um escopo inicial, sobre que poderá ser entregue. Porém, no meio do processo ocorra algum problema/impedimento com o time ou o cliente, eles podem negociar uma mudança no escopo como a remoção de alguma história. Ou então caso o contexto do cliente mude e ele queria trocar alguma história por novas, ele também pode negociar com o time a mudança do escopo. Ou até mesmo, caso o conjunto de histórias que o time pegou tenha sido entregue antes do final do mês, o cliente pode acrescentar novas histórias no escopo. Mas lembrando que toda mudança afetará diretamente o escopo, nunca o tempo, custo ou qualidade.
O ganho principal que o cliente terá dessa forma é que, pelo contrato durar apenas 1 mês, caso ele esteja satisfeito com o quanto o time conseguiu entregar com qualidade neste espaço de tempo e custo fixos, ele pode renovar o contrato por mais 1 mês, podendo inclusive avaliar um novo custo e escopo para o próximo mês. Porém, caso ele não tenha gostado do trabalho, ele teve apenas o custo de 1 mês de trabalho, ao invés de ficar prolongando por muito mais tempo, e poderá não renovar o contrato. Como o custo e tempo foram de curta duração, talvez ele ainda tenha budget e tempo para procurar um novo time desenvolver a sua APP ao invés do projeto simplesmente fracassar.
Só que para o time ter poder neste contrato, o time também pode cancelar ou não renovar o contrato se desejar. Isso geralmente acaba sendo necessário quando o cliente não se compromete com o trabalho, dado que para projetos ágeis o cliente tem que estar presente e próximo do time no dia a dia. Então se o cliente não participa das cerimônias, ou não está disponível para o time quando este tem alguma dúvida, um time ágil pode decidir não trabalhar mais com esse cliente.
Só tendo cliente e time próximos que é possível que eles se comuniquem melhor e entendam as dores um do outro. Inclusive esse é um dos principais fatores do porque clientes não entendem a necessidade do escopo ser variável, dado que eles muitas vezes nunca viram como é o processo de construção de um software e os problemas enfrentados no dia a dia. Quando você traz o cliente para perto do time, ele normalmente aceita melhor a cultura ágil e o escopo variável ao invés do fechado.
Então por mais que ele tenha perdido o escopo fechado (que querendo ou não sempre foi uma mentira) ele ganha previsibilidade e adaptabilidade. Para os dias de hoje em que o mercado muda em questão de dias ou até horas, as empresas que não tiverem esta capacidade de se adaptar na velocidade com a qual as coisas mudam acabam ficando para trás.
