Agile methodology

What is agile methodology?

Agile methodology is the family of ideas and frameworks behind iterative work, not one specific process. The name traces back to 2001, when a group of software practitioners published the Agile Manifesto: four values and twelve principles that favor working software over exhaustive documentation, collaboration over contract negotiation, and responding to change over following a fixed plan.

Everything that calls itself agile descends from that document. Scrum, Kanban, Extreme Programming, and their many hybrids are all implementations of the same principles: deliver value in small increments, get feedback early, and treat the plan as a hypothesis rather than a promise.

It helps to separate the methodology from the practice. Agile methodology is the "why and which framework" layer; the day-to-day engineering habits (short cycles, frequent releases, retrospectives) are covered under agile development. You can understand the philosophy in an afternoon; living it takes discipline.

The values behind agile

Stripped of jargon, the manifesto makes four bets. People and communication beat rigid process. A working product beats a thick specification. Collaborating with customers beats negotiating against them. Adapting to change beats defending a plan. None of these say process, documentation, contracts, or plans are worthless; they say the left side wins when the two conflict. For a startup, where the plan is guaranteed to be partly wrong, that ordering is less a philosophy than a survival strategy.

Popular agile frameworks

Framework	How it structures work	Best fit
Scrum	Fixed-length sprints, defined roles, sprint planning and review	Teams that want rhythm and clear commitments
Kanban	Continuous flow on a visual board with limits on work in progress	Teams with changing priorities or support-heavy work
Extreme Programming	Engineering-centric: pairing, test-first, continuous integration	Teams focused on code quality under fast change

Why agile methodology matters for startups

For a 1-5 person team, the value is choosing deliberately instead of cargo-culting. The methodology question is really: how much structure do we need to keep shipping and learning? A tiny team that adopts every big-company ritual buries itself in ceremony; a team with zero structure loses track of priorities within a month. Understanding the principles lets you take the minimum process that serves them, and change frameworks when the team or product changes, without feeling like you failed.

It also changes how you plan. An agile roadmap is a ranked list of bets, not a delivery contract, which keeps a small team honest about uncertainty.

Agile methodology in practice

Imagine a three-person startup debating process. They try Scrum first: one-week sprints, planning on Mondays, demo on Fridays. After a month they notice the fixed sprint keeps breaking, because customer bugs and sales requests arrive mid-week and cannot wait. So they switch to Kanban: one board, a limit of two items in progress per person, priorities re-ranked whenever reality changes. Velocity feels smoother and nothing important waits a week. Neither choice was "correct"; the agile move was noticing what the principles demanded (respond to change) and adapting the framework instead of forcing the team to fit it.

Common mistakes

• Worshipping a framework instead of the principles. Running perfect ceremonies while shipping quarterly is not agile. Judge your process by cycle time and feedback, not ritual compliance.
• Adopting big-company agile at startup scale. Story point poker and multi-team ceremonies exist to coordinate dozens of people. Three founders need a list, a cadence, and honesty.
• Using "agile" to avoid all commitment. Iterative does not mean directionless. You still need a prioritized backlog and a destination; see product roadmap.
• Never revisiting the choice. The framework that fit at two people may strangle you at ten. Retrospect on the process itself, not just the product.

Related concepts

Agile methodology shares DNA with the lean startup approach, which applies the same build-measure-learn loop to the business model rather than the codebase. If you want the hands-on view of these ideas in an engineering week, start with agile development, then pick the lightest framework that keeps your team shipping.