Lesson 8

Waterfall and Agile: Why We Use Both

Sooner or later someone in this room notices something odd. We write a semester plan in August that runs to December, and we also run three week sprints where the plan can change every time. Which one is it?

Both, on purpose. Here is the defense.

Two ways to run a project

Waterfall means you decide the whole plan up front, then build it in order. You do requirements, then design, then build, then test, mostly in that order, mostly without going back. Changing the plan late is expensive, because everything after the change point has to be redone.

Agile means you work in short cycles. At the end of each cycle you have shown something working, and you use what you just learned to adjust the plan for the next cycle. Nothing far in the future is locked in stone.

Neither is right or wrong. Each fits a different kind of problem.

What we actually do

The season plan is waterfall. It got written in Sprint 0, from the score autopsy, and it points all the way to the regional competition in May. That plan names what we build, roughly when, and why, based on evidence from last season.

The sprints inside that plan are agile. Every three weeks, your team publicly commits a short list of deliverables, builds toward a pool day, and reviews what happened. The next sprint’s plan responds to what the pool actually told you.

Why the season is waterfall

Three real reasons, not tradition.

MATE sets the deadlines, not us. The manual, the documentation due dates, and the regional date do not move for anyone. A plan with a fixed end point wants a plan built backward from that point, which is exactly what waterfall is for.

Parts have lead time. School purchasing takes weeks, so BOMs for a sprint have to be requested during the sprint before it (Card 0.5). That only works if you can see far enough ahead to know what you will need.

You had evidence up front, for once. Most waterfall plans fail because someone guessed at requirements before building anything. Our plan is built from last season’s actual scoresheets (Card 0.4), which is the one condition under which planning far ahead actually works: you are not guessing, you are extrapolating from a real result.

Why the sprints are agile

The water tells you things the bench cannot. A claw that works on the table can fail at depth, in current, gripping a real task prop. You cannot design that away on paper; you have to test it and adjust.

Three week cycles make lateness visible early. A deliverable that is “20% done” or “80% done” looks the same on the bench for weeks. A cycle that ends in a demo cannot hide that. Card 0.3 covers why this fixes the planning fallacy, where everyone underestimates how long things take.

Where waterfall fails

A plan is a prediction, and predictions rot as the season goes on. The specific failure this program has actually lived through: staying committed to a design after the evidence said it was wrong, because it was on the plan. “The plan said so” is not a reason to keep building something that is not working. Big plans also hide their errors until late, which is the most expensive time to find them.

Where agile fails

Iterating with no finish line. A team can feel productive every single sprint while the thing that actually gets scored quietly slips. Agile normally assumes you can cut scope when you are behind, and we mostly cannot: the mission tasks are given by MATE, not chosen by us. Retros that name the same problem three sprints running and change nothing are agile in name only. And documentation is the first thing that dies under “we will get to it next sprint,” which is why DDRs get written same-sprint instead of saved for later.

How to tell which one you are in

If the thing you want to change is on the semester plan, it needs a DDR and a conversation with the whole company. If it is inside this sprint, your team decides it at planning or at the retro.

That is the whole rule. Most disagreements about “why can’t we just change this” are really disagreements about which of those two you are standing in.

When the semester plan does change

The plan is allowed to change. It changes at a sprint boundary, not mid-sprint. It changes because of evidence: a pool day result, a new score autopsy insight, a part that turned out not to work. And the change gets written down as a DDR, same as any other decision, so the reasoning survives past whoever made the call.

Why this matters for competition

Judges ask about your process, and “we use agile” is a buzzword answer they have heard a hundred times. Naming your actual hybrid, and being honest about where each half of it fails, is what a real answer sounds like. Most engineering organizations run some hybrid of planned and iterative work. Few of them can describe theirs out loud. You can.

Going further

A video your teacher recommends on the difference between these two approaches, if you want to go deeper than this page.