It started with a problem.
In February 2001, seventeen software developers met at a ski lodge in Snowbird, Utah, and produced a short document they called the Agile Manifesto. It described four preferences: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The manifesto was a reaction against heavyweight development processes — large specification documents, long release cycles, and the assumption that requirements could be frozen before work began. The Agile Alliance, founded at the same meeting, maintains the original manifesto and histories of the signatories.
Historical sources below ↓Then something changed.
Agile methods changed the unit of software development from the project to the iteration — typically one to four weeks. Instead of specifying all requirements upfront and delivering months later, teams delivered working software frequently and gathered feedback after each cycle. This changed the role of customers in development: they were expected to participate throughout, not just at the beginning and end. It also changed the economics of error: a mistake discovered after two weeks of work was much cheaper to fix than one discovered after six months. Agile became the dominant software development framework in the 2010s, with many organizations adapting it to non-software work as well.
What a builder can learn.
Our interpretation: agile methods are a response to a specific problem — requirements that change faster than projects can complete. Not all work has this property. A building under construction is better served by accurate upfront planning than by two-week iterations. For a business builder, the question is whether the work involves uncertain requirements or certain ones. If requirements will change as customers use the product, short cycles and frequent delivery reduce the cost of learning. If requirements are well understood, detailed planning before execution may be more efficient.
A door still open.
A hypothesis worth testing: if a small business identified one recurring project type — a website update, a service design, a marketing campaign — and split it into two-week chunks instead of one long effort, delivering something visible and usable at the end of each chunk, would the final result differ from the current approach, and would the effort required change?
Which project are you currently planning for months before starting, when you could start smaller, learn sooner, and adjust before committing?
Follow the evidence.
History is sourced below. Business lessons are editorial interpretations; future possibilities are questions to test, not predictions.
Prepared from primary-source histories. First edition: 25 Sept 2026.