Agile teams build software in short iterative cycles rather than against a frozen, up-front specification, and that single design choice collides with almost every assumption baked into a traditional fixed-scope, fixed-price development contract. This article explains, for lawyers and non-lawyers alike, why fixed-scope paper fails an iterative build and how to structure the deal instead using capped time-and-materials or fixed-price-per-sprint pricing, a master agreement paired with sprint-based statements of work, and a product owner defined as a contractual office. It works through the doctrinal defaults that fill an Agile contract's many silences, including the goods-versus-services question, substantial performance versus perfect tender, and acceptance as a legal event; then through the definition of done and incremental acceptance, change management without change orders, IP ownership under the work-made-for-hire doctrine of 17 U.S.C. 101 and the present-assignment fix, open-source compliance, warranties and liability caps, security and privacy as mandatory backlog items, and the special demands of regulated and government work. Invented hypotheticals and sample clause language illustrate each problem, and the piece closes with a drafting checklist, an FAQ, and cross-references to related UpLaw resources. The organizing idea is a contract as adaptive as the method it governs, firm exactly where the parties' rights and money must be firm.