Skip to main contentblog
back to blog

scrum, agile, waterfall: what i wish i knew before that interview

21 oct 2025, 09:27 utc+8·4 min read
share:

that awkward moment

interviewer: "you've been working for 3 years. can you explain what scrum and agile are?"

me: "uh... we use it at work i think?"

silence

yeah. 3 years of experience, couldn't explain the process i used every day. embarrassing.

so i finally sat down and learned this stuff. here's what clicked for me.

the simplest way i can explain it

remember group projects in school?

waterfall = the way that always failed

  1. plan the entire project at the start
  2. divide all the work
  3. everyone goes off and does their part alone
  4. meet up the night before to combine everything
  5. realize nothing fits together
  6. panic

the problem: you planned everything based on guesses. by the time you see the whole thing, it's too late to fix.

agile = what actually worked

  1. meet up, do a small part together
  2. show it to each other
  3. "wait this doesn't make sense, let's adjust"
  4. do another small part
  5. keep checking in and adjusting

why it worked: you catch problems early. you adapt as you learn.

that's basically it. waterfall = plan everything then build. agile = build small pieces, learn, adjust.

okay but what's scrum then?

scrum is just one specific way to do agile.

think of it like:

  • agile = "let's work out regularly"
  • scrum = "here's a specific workout routine: 3 sets, 12 reps, rest 60 seconds"

scrum gives you specific rules: work in 2-week chunks, meet daily for 15 mins, etc.

the basic scrum setup

3 roles:

  1. product owner - decides what to build (like the team leader who knows what the teacher wants)
  2. scrum master - removes blockers (like the person who books the study room and brings snacks)
  3. dev team - builds it (everyone else actually doing the work)

the 2-week cycle (called a sprint):

  • monday week 1: sprint planning

    • pick what you'll build this sprint
    • break it into tasks

  • every morning: standup (15 mins)

    • what'd you do yesterday?
    • what'll you do today?
    • any blockers?

  • friday week 2: sprint review

    • show what you built
    • get feedback

  • friday week 2: retrospective

    • what went well?
    • what sucked?
    • what'll we change?

then repeat. forever.

the part that confused me

"is agile the same as scrum?"

no. agile is the mindset. scrum is one way to do it.

other ways: kanban (continuous flow), XP (pair programming), etc.

but scrum is most common, so when people say "we do agile" they usually mean scrum.

"what if we can't finish everything in the sprint?"

move it back to the backlog. discuss why in the retrospective. don't extend the sprint.

fixed time is the whole point - it forces you to break work into smaller pieces.

why i should've known this

in that interview, they weren't testing if i'm a scrum master.

they wanted to know:

  • do i understand how teams work?
  • can i explain my work process?
  • have i actually worked professionally?

what i should've said:

"we work in 2-week sprints. i join daily standups to share progress and blockers. in sprint planning, i help estimate how long frontend tasks will take. retrospectives helped us improve our code review process."

instead of: "uh... we use it?"

what actually helped me understand

  1. paid attention in standups - started noticing the pattern: planning → work → review → improve → repeat

  2. asked my senior - "why do we do retrospectives?" turned out there's actual reasons, not just corporate ritual

  3. read the scrum guide - it's like 13 pages, very readable: scrumguides.org

  4. connected it to my experience - oh, sprint planning is why we estimate tasks. daily standup is why we unblock each other fast. retrospectives is why our process keeps improving.

the honest takeaway

you don't need to memorize everything. but know the basics:

  • sprints - work in fixed time chunks (usually 2 weeks)
  • standups - quick daily sync
  • retrospectives - regular improvement discussions
  • agile mindset - adapt to change instead of rigidly following a plan

it's like knowing git. you don't need to know git internals. but you should know commit, push, pull, branches.

same here. know enough to participate and explain your process.

don't be like past me. don't go 3 years without understanding your own workflow.

just pay attention in your next standup. ask why you do things. it'll click.

contents
  • that awkward moment
  • the simplest way i can explain it
  • waterfall = the way that always failed
  • agile = what actually worked
  • okay but what's scrum then?
  • the basic scrum setup
  • the part that confused me
  • why i should've known this
  • what actually helped me understand
  • the honest takeaway