← Agile and Scrum: Flexible Project Management
Lesson
Lesson 1.2 — The 12 principles and Agile vs waterfall
Recognize the 12 Agile principles and explain how an Agile flow differs from a sequential 'waterfall' flow, and where each fits.
The 12 Principles and Iterative vs. Sequential Delivery
From Values to Principles: How Agile Works in Practice
Behind the four Manifesto values sit 12 principles that guide day-to-day behavior. Key among them: deliver working software early and continuously; welcome changing requirements even late in development; deliver frequently (weeks, not months); business people and developers work together daily; build projects around motivated individuals and trust them; face-to-face conversation is the most efficient form of communication; working software is the primary measure of progress — not documents produced; teams should maintain a sustainable, constant pace indefinitely; continuous attention to technical excellence and good design; simplicity — maximizing the work NOT done — is essential; the best architectures emerge from self-organizing teams; and teams should reflect at regular intervals on how to tune their behavior.
Waterfall arranges all work in sequential phases: Requirements → Design → Build → Test → Deploy. Each phase must finish before the next begins. This works well when requirements are truly fixed and known upfront (think bridge construction or regulated medical devices), but it fails when requirements evolve, because feedback comes only at the very end.
Agile flips this into short cycles called iterations or sprints, each delivering a small but working slice of the product. Feedback arrives continuously, and the team can course-correct before costs spiral. The result is incremental, iterative delivery instead of a big-bang release.
Agile is NOT a silver bullet. It fits best where: requirements are uncertain or rapidly changing, fast user feedback is possible, and the product is complex and evolving. It fits poorly where requirements are legally frozen, work is purely sequential and cannot be sliced (e.g., pouring concrete), or regulatory compliance demands exhaustive upfront documentation.
Lesson notes
From Values to Principles: How Agile Works in Practice
Behind the four Manifesto values sit 12 principles that guide day-to-day behavior. Key among them: deliver working software early and continuously; welcome changing requirements even late in development; deliver frequently (weeks, not months); business people and developers work together daily; build projects around motivated individuals and trust them; face-to-face conversation is the most efficient form of communication; working software is the primary measure of progress — not documents produced; teams should maintain a sustainable, constant pace indefinitely; continuous attention to technical excellence and good design; simplicity — maximizing the work NOT done — is essential; the best architectures emerge from self-organizing teams; and teams should reflect at regular intervals on how to tune their behavior.
Waterfall arranges all work in sequential phases: Requirements → Design → Build → Test → Deploy. Each phase must finish before the next begins. This works well when requirements are truly fixed and known upfront (think bridge construction or regulated medical devices), but it fails when requirements evolve, because feedback comes only at the very end.
Agile flips this into short cycles called iterations or sprints, each delivering a small but working slice of the product. Feedback arrives continuously, and the team can course-correct before costs spiral. The result is incremental, iterative delivery instead of a big-bang release.
Agile is NOT a silver bullet. It fits best where: requirements are uncertain or rapidly changing, fast user feedback is possible, and the product is complex and evolving. It fits poorly where requirements are legally frozen, work is purely sequential and cannot be sliced (e.g., pouring concrete), or regulatory compliance demands exhaustive upfront documentation.