The legal nature of the agile development contract
Software development through a flexible, iterative process — iterations, sprints, incremental delivery — is legally a relationship built on the mechanics of the works contract, though its content is freely determined. Under part 1 of Article 319 of the Civil Code, subjects of private law may freely conclude contracts and determine their content; contracts not provided for by law are also permitted if they do not contradict it. This norm is what makes the agile process lawful: the iterative plan, the backlog and the separate acceptance of each stage take shape as contractual terms.
Personal performance and team rotation
Article 632 regulates personal performance: the contractor must perform the work personally only where this follows from the specific circumstances or the character of the work. In software projects team rotation is common practice — which is why it matters that the contract states explicitly whether the customer insists on particular individuals; if not, a change in the team's composition is not a breach — one of the chief advantages of flexible teams on the market.
Incremental acceptance and remuneration
Under Article 649, where delivery is required by the contract or by the character of the work, the customer must accept the completed work and pay the remuneration immediately upon acceptance; the work is deemed accepted unless the customer rejects it within the period set by the contractor. In an agile process this means: each iteration's result — the increment — is an object of separate delivery and separate acceptance, and refusal without ground is impermissible. Article 656 governs the counting rule: where the work is accepted part by part, the limitation period for a defect claim runs from the day of acceptance of the work in full — the window of responsibility for defects opens with full acceptance.
The right to terminate at any time
Under Article 636 the customer may renounce the contract at any time before completion, but must compensate the contractor for the work performed and the damage caused by the termination. In agile projects this is an exit gate: the project can be stopped at the end of any iteration, and what has been delivered and accepted is then compensated. The model reduces the customer's risk while guaranteeing the contractor the value of completed stages. At the same time the rule balances the contractor's interest as well: the payment covers not only the work performed but also the damage caused by the termination, so the cost of exit is computable in advance — and that shapes the negotiating positions of both sides.