Waterfall, Agile, Kanban

Why methodologies matter

A DevOps engineer works inside a team that has its own rhythm: planning meetings, task boards, release cycles. Understanding how that work is organized helps you fit in and speak the same language. This is about how a team moves from an idea to a working product. The code itself is secondary here.

Three approaches cover almost everything you'll run into: Waterfall, Agile, Kanban.

Waterfall: stage by stage

Waterfall is a sequential model. First all requirements are gathered, then the design is done, then the code is written, then it's tested, then it ships. Each stage finishes completely before the next one starts, the way water falls from one ledge to the next.

Its strength is predictability and documentation: everything is planned upfront. Its weakness is rigidity. If testing reveals the requirements were wrong, going back is expensive. That's why waterfall survives where requirements are strict and rarely change: government contracts, hardware, regulated industries.

Agile: in iterations

Agile is a set of values and principles. There's no single methodology with that name. They were written down in 2001 in the Agile Manifesto: four values and twelve principles. The main idea: work in short iterations, show a working result often, and adapt to change. Instead of one big release a year out, there are many small ones, every couple of weeks.

The best-known Agile framework is called Scrum. Work happens in sprints: a fixed-length period, no more than a month per the Scrum Guide, though in practice it's usually one or two weeks. At the start of a sprint the team picks as much as it can finish from a list of tasks (the backlog), and at the end it shows what's done. A short 15-minute meeting happens every day (Daily Scrum, usually called a standup) so everyone stays in the loop.

Teams often estimate how many tasks fit in a sprint in story points: each task gets its own estimate, and the team has its own sprint capacity based on past sprints. This is a common practice, but it isn't in the Scrum Guide itself.

Agile wins when requirements change along the way. And that's almost all product software.

Kanban: flow and the board

Kanban is built on a continuous flow of tasks, with no fixed sprints. Work is tracked on a board with columns:

To Do      | In Progress | Review | Done
task 1     | task 3      |        | task 5
task 2     |             |        |

A task moves across the columns left to right. The key idea is limiting work in progress (WIP): a column like "In Progress" can't hold more than N tasks at once. This stops the team from grabbing everything at once and highlights bottlenecks. If tasks pile up in front of some column and sit there for days, that's where the bottleneck is, and starting new tasks is pointless until it clears.

Metrics from the Kanban Guide help spot a bottleneck. The two simplest ones:

• WIP: how many tasks have started but aren't finished.
• Task age (work item age): how much time has passed from when a task started to today. The oldest unfinished task usually shows where the flow has stalled.

Kanban works well for a flow of similar work (support, operations, DevOps tasks), where splitting time into sprints doesn't make sense.

Where DevOps fits in

DevOps isn't on this list. It's a culture: remove the wall between development and operations and automate the path from code to production. It sits on top of Agile and Kanban. Frequent small releases (Agile) and a continuous flow of changes (Kanban) are impossible if every release is built and shipped by hand. That's why CI/CD, infrastructure as code, and observability are needed, which is what DevOps is about.

Common mistakes

• Calling Agile a methodology. Agile is a set of principles, while methodologies and frameworks (Scrum, Kanban, and others) implement it. This difference comes up often in interviews.
• Loading a sprint with "just in case" tasks. If a sprint takes on more than its capacity, part of it won't finish, and there's nothing to show at the end. Less but done is better.
• Taking a new task when a column has hit its WIP limit. The limit exists for a reason: help push through what's stuck further along the board first.
• Looking for the bottleneck in the longest column. A long "To Do" list is a normal backlog with no limit. The bottleneck is where tasks have started and are sitting: a column above its limit and tasks that have been in progress for a long time.
• Treating DevOps as a job title that "does Agile". DevOps practices support frequent releases, but the team chooses its own process.

What you'll need for the tasks

• A board as a set of columns; a task moves left to right.
• A WIP limit: how many tasks can sit in a column at once.
• Task age: the date since which a task has been in progress.
• A sprint and team capacity in points: tasks are taken into a sprint from the backlog by priority, as long as the sum of points stays within capacity.
• From the terminal: ls, cat, grep, mkdir, mv, wc -l. In the labs, the board lives on disk: a column is a folder, a task is a file in it.

Later these approaches show up in practice: CI/CD and GitOps are the tools that Agile and Kanban teams use to ship changes.