After this lesson, you will be able to: Explain what Agile actually says vs the mythology that has grown around it, and reason about why most companies implement it imperfectly.
Agile is the most-misunderstood word in software. This lesson distinguishes the actual Agile Manifesto from the dysfunctional practices people call 'Agile' at most companies.
This is a free introductory lesson. No purchase required.
Written in 2001 by 17 practitioners frustrated with heavy waterfall processes. Four values: 1. Individuals and interactions over processes and tools. 2. Working software over comprehensive documentation. 3. Customer collaboration over contract negotiation. 4. Responding to change over following a plan. Note the words 'over', not 'instead of'. The right-hand items still matter; the left-hand items matter more.
Satisfy the customer through early and continuous delivery. Welcome changing requirements, even late. Deliver working software frequently (weeks, not months). Business people and developers work together daily. Build projects around motivated individuals. The most efficient communication is face-to-face. Working software is the primary measure of progress. Sustainable pace, indefinitely. Continuous attention to technical excellence. Simplicity (maximizing the work NOT done). The best architectures emerge from self-organising teams. Reflect and adjust at regular intervals. Read these slowly. They are nothing like what most 'Agile' shops do.
Daily standups that became status meetings. Sprint planning theatre with story-point estimates nobody believes. Burndown charts watched by managers. Retros that produce 'we'll do better' and then change nothing. Process imposed by leadership rather than chosen by the team. Most teams call themselves Agile while practising the opposite of every principle. That's not a flaw in Agile; it's organizational dysfunction wearing Agile's name.
Conflating Agile (a philosophy) with Scrum (one specific framework). Scrum is one way to be Agile; not the only way. Treating the rituals as Agile. Six daily standups don't make you Agile if you're not delivering working software frequently. Pushing back against process change because 'we already do Agile'. The whole point is continuous adaptation. Defending Agile as a religion. It's a toolkit; use what works, drop what doesn't. Skipping the retro. It's the ONE ritual that's actually required by the values; most teams skip it.
Pick the answer that matches the values, not the rituals.