The Agile Manifesto values customer collaboration over contract negotiation. This sets an important tone for procurement relationships on agile projects.
Valuing customer collaboration more than contract negotiation doesn't mean that agile projects have no contracts: Contracts and negotiation are critical to business relationships. However, the Agile Manifesto sets forth the idea that a buyer and seller should work together to create products, and that the relationship between the two is more important than quibbling over ill-informed details and checking off contract items that may or may not ultimately be valuable to customers.
All 12 Agile Principles apply to procurement on agile projects. However, the following seem to stand out the most when securing goods and services for an agile project:
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
(4) Business people and developers must work together daily throughout the project.
(5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
(10) Simplicity — the art of maximizing the amount of work not done — is essential.
(11) The best architectures, requirements, and designs emerge from self-organizing teams.
This table highlights the differences between procurement on traditional projects and procurement on agile projects.| Procurement Management with Traditional Approaches | Procurement Management with Agile Approaches |
| The project manager and the organization are responsible for procurement activities. | The self-managing development team plays a larger part in identifying items needing procurement. The scrum master facilitates the acquisition of needed items for the development team. |
| Contracts with service providers often include provisions for fixed requirements, extensive documentation, a comprehensive project plan, and other traditional deliverables based on a waterfall lifecycle. | Contracts for agile projects are based on the evaluation of working functionality at the end of each sprint, not on fixed deliverables and documentation that may or may not contribute to delivering quality products. |
| Contract negotiation between buyers and sellers can sometimes be challenging. Because negotiation is often a stressful activity, it can damage the relationship between the buyer and the seller before work even starts on a project. | Agile project teams focus on keeping a positive, cooperative relationship between buyers and sellers from the start of the procurement process. |
| Switching vendors after a project starts can be costly and time-consuming because a new vendor must try to understand the old vendor's massive amount of work in progress. | Vendors provide completed, working functionality at the end of each sprint. If vendors change mid-project, the new vendor can immediately start developing requirements for the next sprint, avoiding a long, costly transition. |
Both waterfall and agile project teams are interested in vendor success. Traditional project approaches were firm in their accountability for compliance, defining success as checking off documents and deliverables in a list. Agile project approaches, by contrast, are firm in their accountability for end results, defining success with working functionality.
