Agile and Scrum, Explained by Someone Who Ran Both Badly First
My first Agile adoption was not a success story. We renamed our weekly status meeting a "standup," called our task list a "backlog," and kept working exactly as before, now with more ceremonies. It took a failed release and one honest retrospective to admit we had adopted the vocabulary and skipped the idea. Since then I have run Scrum and Kanban across a portfolio of product teams, and the distinction between the vocabulary and the idea is the whole game.
Agile is a bet, not a process
Agile is one core bet: in work where requirements will change, learning fast beats planning perfectly. Everything in the Agile Manifesto derives from it. Deliver small increments so reality can correct you early. Talk to users over negotiating documents, because documents don't change their minds and users do. Welcome changing requirements, because the change was coming anyway and the only choice is whether it arrives cheap or expensive.
What Agile is not: an excuse to skip planning, documentation, or commitments. Every unplanned team I have inherited called itself Agile. The actual discipline plans constantly, in smaller units, against better information.
Scrum is one way to operationalize the bet
Scrum takes the bet and gives it a heartbeat. A fixed-length sprint, one to four weeks. A Product Owner who owns what to build next and has the authority to decide. A Scrum Master who owns the health of the process. A team that commits to a sprint goal and demos working software at the end, followed by a retrospective where the process itself gets fixed.
The parts teams skip are, predictably, the parts that hurt. The demo hurts because unfinished work has nowhere to hide. The retrospective hurts because it names problems while they are still small. My renamed-status-meeting team skipped both, which is exactly why nothing changed. When I later ran Scrum properly, the demo did more for schedule honesty than any report I ever formatted: sponsors watching working software need no RAG status.
One hard-won note on the Product Owner role: it fails quietly when the PO has responsibility without authority. A PO who must escalate every prioritization call is a proxy, and the team ends up waiting on decisions that Scrum assumed would take a conversation.
Kanban, and when I reach for it instead
Scrum's sprint rhythm fits feature work. But some streams don't arrive in plannable batches: support queues, integration incidents, small merchant requests trickling in daily. For those I use Kanban: visualize the flow, limit work in progress, measure cycle time. The WIP limit is the entire method in one number. The day we capped one team's in-progress column, finished work per week went up, because finishing beats starting and the limit forces that choice.
There are other frameworks in the family, XP with its engineering practices, SAFe and LeSS for scaling. My honest advice is to be fluent in Scrum and Kanban first; most real situations are covered by one of them or a sensible mix, and scaling frameworks amplify whatever discipline you already have, including its absence.
Choosing, in practice
My selection rule after years of running both: if the work is exploratory and batchable, Scrum, because the sprint boundary forces learning checkpoints. If the work is a continuous flow of small independent items, Kanban, because artificial sprint boundaries just delay things that could ship today. If a fixed enterprise deadline wraps the whole thing, that is a hybrid, and I wrote up how I wire that separately.
And if a team is adopting Agile for the first time, the only advice that matters: adopt the feedback loops, the demo and the retrospective, before adopting any vocabulary. A team that demos honestly and retrospects honestly will invent half of Scrum by themselves within a quarter. A team that starts with the vocabulary can perform the ceremonies for years, the way mine once did, and never take the bet at all.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.