🔄 Agile Development Principles

Why Agile Exists

Agile is not a single tool or ceremony — it's a mindset for building software when you can't know everything up front. Instead of one giant plan executed once, Agile teams work in short, repeating cycles: build a little, show it to real users, learn, and adjust.

💡 An analogy: The old "waterfall" way is like building a rocket — you design every bolt in advance, assemble it exactly to plan, and hope it flies on the first launch. Agile is like building a skateboard, then a scooter, then a bicycle, then a motorcycle. At every stage you have something that works and can be ridden, and you learn what the rider actually needs before committing to the car.

The two approaches handle change very differently. Waterfall treats a change late in the project as a failure of planning; Agile treats it as normal and even welcome — because the people who use the software almost always understand what they want better after they see a working version.

The Agile Manifesto

In 2001, seventeen software practitioners met and distilled their shared experience into the Agile Manifesto. Its heart is four value statements. Each one says "we value the thing on the left more than the thing on the right" — not that the right side is worthless.

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 12 principles, grouped

The manifesto is backed by twelve principles. Rather than memorize them as a list, it helps to see the three themes they fall into:

Scrum, Kanban & XP

Agile is the philosophy; methodologies are concrete ways to practice it. Three dominate the industry. They're not mutually exclusive — many real teams blend them.

Scrum — work in sprints

Scrum organizes work into fixed-length sprints (typically 1–4 weeks). Each sprint is a mini-project with a clear goal, framed by a set of recurring events.

Real-world example: Spotify famously adapted Scrum into autonomous "squads" grouped into "tribes," letting many small teams ship independently while staying aligned.

Kanban — visualize and limit flow

Kanban has no sprints. Instead you visualize work on a board and limit work in progress (WIP) so tasks flow smoothly and bottlenecks become obvious. It's ideal for continuous streams of work like bug-fixing or support.

The magic is the WIP limit. If "In Progress" is capped at 2 and both slots are full, you can't start anything new — you're forced to help finish existing work first. That single rule kills the "everything is 90% done, nothing ships" trap.

Extreme Programming (XP) — engineering discipline

Where Scrum and Kanban organize work, XP focuses on technical practices that keep code healthy under rapid change:

• Test-Driven Development (TDD): write a failing test first, then the code to pass it.
• Pair programming: two developers, one keyboard — continuous review as you write.
• Continuous Integration: merge and test small changes many times a day to catch conflicts early.
• Refactoring: continuously improve the design without changing behavior.

User Stories

A user story captures a requirement from the user's point of view, in one sentence, using a simple template:

The "so that" clause is the secret weapon — it forces you to state the why, which often reveals a simpler solution than the one originally requested.

• "As a logged-in user, I want to reset my password so that I can regain access if I forget it."
• "As a site administrator, I want to see recent login attempts so that I can spot suspicious activity."
• "As a mobile visitor, I want the layout to adapt to my screen so that I can read comfortably on my phone."

Good stories are often checked against the INVEST checklist — a story should be Independent, Negotiable, Valuable, Estimable, Small, and Testable. Each story also carries acceptance criteria: the concrete conditions that make it "done."

Story: As a logged-in user, I want to reset my password
       so that I can regain access if I forget it.

Acceptance criteria:
- [ ] A "Forgot password?" link appears on the login page
- [ ] Submitting a registered email sends a reset link
- [ ] The reset link expires after 1 hour
- [ ] An unknown email shows the same generic message (no account leak)
- [ ] After a successful reset the user is redirected to login

Estimation & MVPs

Story points, not hours

Humans are famously bad at estimating time ("it'll take two hours" → two days). Agile teams estimate relative size instead, using story points — usually a Fibonacci-like scale (1, 2, 3, 5, 8, 13, 21). A 5-point story is "about as big as five 1-point stories," accounting for effort, complexity, and uncertainty together.

Planning Poker turns estimation into a quick consensus game: everyone secretly picks a card, all reveal at once, and big disagreements spark a short discussion that surfaces hidden assumptions before you re-vote.

💡 Why relative sizing works. It's like rating hiking trails "easy / moderate / hard" instead of predicting exact minutes. The absolute time depends on the day, but the relative difficulty is stable — and over a few iterations your team's velocity turns points into a reliable forecast.

The Minimum Viable Product (MVP)

An MVP is the smallest version of a product that delivers real value and lets you learn from actual users. It is not a broken or ugly product — it's a complete thin slice.

Real-world example: Dropbox's first "MVP" was a short demo video showing the idea working. It validated demand before the founders built the hard synchronization engine — saving enormous effort had nobody cared.

Agile for Solo Devs & Small Teams

You don't need a Scrum Master or a big team to benefit. Here's a stripped-down Agile practice that works for one person on a side project.

Personal Kanban

A three- or four-column board is enough: Backlog → This Week → In Progress (limit 1–2) → Done. The WIP limit on "In Progress" is the whole point — it stops you from starting five things and finishing none.

Time-boxed cycles

Pick a rhythm (one or two weeks). At the end of each cycle, run a tiny personal retrospective: What shipped? What blocked me? What one thing will I change next cycle?

Spike before you commit

When you're unsure about a library or approach, do a small throwaway experiment (a "spike") to reduce uncertainty before building the real thing on top of it — for example, wiring up two candidate charting libraries with fake data instead of fully integrating one and discovering its limits a week later.

Common Pitfalls

Hands-on Exercise

Summary & Quiz

📚 Further Reading

• The Agile Manifesto (original text)
• The Scrum Guide
• Atlassian Agile Coach
• Extreme Programming (XP)

🚀 What's Next?

Now that you can plan work the Agile way, the next lesson looks at the tools that make it flow day to day — task boards, time-management techniques, and productivity systems built for developers.