Olá Renato,
existem modelos de contratos ágeis que se adequam a esta realidade de entrega de software.
Nos modelos clássicos de contratos que seguiam principalmente o waterfall, como você comentou, os três valores definidos de fato eram escopo, custo e prazo. O problema é que software existe um quarto valor que nunca aparecia no contrato, mas que é implícito na área de software, que é a qualidade.
O problema dos modelos clássicos de contrato, qualquer problema ou alteração no projeto, dentre esses 4 valores sempre o que variava era a qualidade de software. Então muitas vezes, para entregar o projeto no mesmo custo, prazo e escopo, havia uma brusca queda na qualidade do código, o que resultava em bugs, dificuldade de manutenção, alto custo para mudanças, entre outros tantos problemas.
Como para a agilidade temos até como princípio a excelência técnica e o bom design, os contratos ágeis deixam fixos as variáveis custo, prazo e qualidade. Então qualquer problema que ocorra durante do desenvolvimento do projeto, o escopo é que irá variar.
Além disso, para se adequar aos modelos de entrega frequente e desde cedo, normalmente os contratos ágeis tem custo e prazo calculados para períodos curtos de tempo, como por exemplo 1 mês. Ou seja, a idéia é que o cliente negocia um contrato de um software de alta qualidade para o prazo de 1 mês e custo para este período de trabalho. Neste período de trabalho, é definido um escopo, que pode sofrer alterações durante o trabalho. Se no término deste período de 1 mês o cliente gostou do trabalho feito, já existem cláusulas no contrato que permitem sua renovação por mais 1 mês, estabelecendo um novo escopo e até mesmo um novo custo se necessário.
Caso o cliente não goste do trabalho, ele encerra as renovações e cada uma das partes segue a vida. Essas cláusulas de renovação também valem para o lado do desenvolvimento, pois nos modelos ágeis o cliente precisa estar presente para o projeto ter uma chance maior de sucesso. Se durante o trabalho o cliente não era presente e não tirava dúvidas do desenvolvedores quando necessário, o time pode decidir também não renovar o contrato.
Neste modelo, o cliente perde aquela ideia de data para o projeto completo, que em geral era um grande chute muitas vezes errado. Mas ele ganha em adaptabilidade, ser mais assertivo em relação ao seus custos, gerenciar melhor as mudanças dado que são escopos de 1 mês, uma visão mais precisa do projeto dado que ele consegue acompanhar mês a mês e fazer o fail fast quando necessário ao invés de investir por anos em projetos que tendem ao fracasso.
