Pre-class reading for ESP IT. We're learning two ways software gets built — through pirates trying to outrun the Black Pearl and a casino heist crew planning the perfect job. Read this before class. There will be a test.
The Software Development Life Cycle (SDLC) is the structured framework teams use to build software. Different sources count anywhere from five to eight phases — and that's fine. Some authors add more stages to the Waterfall model, so don't just memorise a fixed number. Get the general understanding of the approach, and compare it with the Agile model. This page covers both. Kanban is presented as part of Agile, because that's what it is.
The two short videos linked in each section come from The Digital Project Manager on YouTube — a channel that explains these methods through a casino heist (Waterfall) and Captain Jack Sparrow building a pirate ship (Agile). They're funny, fast, and they stick. Watch them. Then come back here, click around the games, and check the glossary.
If you can explain the difference between Waterfall and Agile to a friend in your own words by the end — using either pirates or a heist crew as an example — you're ready for the test.
Prefer to ask questions rather than read top to bottom? ALMA is an AI assistant that will walk you through Waterfall, Agile and Kanban in conversation — answer your questions, push back on shaky understanding, and check what stuck. Note: ALMA uses a different metaphor — cooking — instead of the casino heist and Captain Sparrow you'll meet on this page. Two metaphors, same ideas. Use ALMA alongside this page, not instead of it.
Open ALMA in a new tab →Waterfall is linear and sequential. Five phases, top to bottom, no going back. Like planning the perfect casino heist — every door, every camera, every guard mapped out before anyone touches a lock. One wrong move and the whole crew goes down.
🎰 A four-person crew is planning to rob an ocean-style casino. Mastermind, analyst, tech expert, developer. Five phases. One rule they cannot break — and if they break it, the alarm goes off. This is the cleanest way you'll ever see Waterfall explained: pixel art, fast jokes, and a heist that lands every concept where it needs to.
The heist is fun, but here's where it lands in your future career. Imagine your team is hired to build the online banking system for a national bank. The regulator demands that every requirement, every architectural decision, every test result is documented and traceable. The launch date is fixed by law. The features are stable — people want to log in, check balances, transfer money, and that's not changing next month.
This is exactly when Waterfall earns its keep. The Business Analyst spends weeks gathering requirements with compliance officers. The Tech Expert chooses a stack that meets banking regulations. Only then do the Developers write code, against a frozen specification. If a requirement changes after sign-off, going back is expensive — but in regulated software, the cost of not documenting and locking down would be much higher. Same logic as the heist: plan everything before anyone touches a lock.
Requirements gathered, stakeholders identified, project charter created. The PM brings in the Analyst to map every corner of the casino floor before anyone touches a lock. Business value calculated, goals mapped out.
Detailed plan, tech stack, tasks and timeline are set. The Tech Expert joins. Tasks are assigned to developers with anticipated completion dates. The crew gets the green light only after the full plan is approved by the client.
Work begins. The PM holds the kickoff and the team works through tasks — getting into character, disabling security, creating diversions. The PM monitors progress, manages the budget, and guides the team through corridors, hallways, ventilation shafts and past security guards.
Quality and progress checked continuously. If an alarm goes off — accidental triggering, getaway car not starting — the PM corrects course fast. Documentation is key. Every adjustment is recorded for visibility, accountability and traceability.
Deliverables verified, cash counted, profits divided. A retrospective is held to celebrate the team and identify areas for improvement. Documentation is archived for the next job — assuming the crew is up for a sequel.
▲ Tap any phase to expand
Writes the code in Phase 3 only — and only after the full plan is approved. No improvising on the casino floor.
The mastermind. Plans every step, manages the budget, monitors progress and steers the crew through ventilation shafts.
Joins in Phase 1. Gathers requirements, shapes the project charter, maps the casino floor from penthouse to vault.
Brought in during Phase 2 to choose the tech stack. Makes sure the crew has the right tools to see the plan through.
The crew got the phases mixed up. Tap each one in the correct order to fill slots 1 through 5. Get it right and the vault opens.
Now that you've watched the heist — three pulls, three questions. Three correct = jackpot. One wrong answer trips the alarm and the heist is over.
Agile is iterative and incremental — the opposite of Waterfall. Captain Jack Sparrow commissions a ship to outrun the Black Pearl. His crew builds it Agile-style: an MVP first, then improve it iteration by iteration based on what Jack actually wants. Time is short. The plan changes. That's the point.
⚓ Captain Jack Sparrow needs a ship faster than the Black Pearl — and he needs it now. He doesn't know exactly what it should look like, but he'll know when he sees it. His crew has a method for exactly that kind of customer. Watch them build the impossible ship in four minutes, and watch the moment a "small request" almost capsizes the whole project.
Captain Jack is fun, but here's where this lands in your future career. Picture a consumer mobile app at an early-stage startup — say, a food delivery service launching in a new city. The founder has a strong gut feeling about what users want, but no one really knows yet. The market shifts every week. Competitors copy features overnight. And the only honest answer to "what should the app do?" is "we'll find out by shipping something and watching what users actually do."
This is exactly when Agile earns its keep. The team builds an MVP — maybe just login, browse three restaurants, place one order — and ships it to a small group of users. They watch what happens, talk to people, read reviews. The next two-week sprint adds whatever turned out to matter most: faster checkout, restaurant filters, push notifications. Each iteration is a small bet, and each one teaches the team something the original founder couldn't have predicted. Same logic as the pirate ship: build the bare hull, get it on the water, let the customer tell you what's missing.
The idea is defined. Details still coming together. Time is short.
The crew builds and delivers a working increment.
Feedback reviewed, plan adjusted — the loop starts again.
The bare hull of the ship. Jack's first real feedback. He can already see what's coming.
Crow's nest added, hull reinforced for rough maelstroms. Closer to what Jack actually needs.
Extra mast, more rum storage in the galley. Peak satisfaction. The ship is ready to sail.
Work split into short cycles. Each one produces a shippable increment the customer can see and use.
Customers give continuous feedback throughout — not just at the start and end of the project.
Developers, testers, designers and product owners all working together in one crew.
Changing requirements are welcomed even late in development. Adapting is a strength, not a weakness.
Useful features released often — quick responses to feedback and shifts in the market.
Testing built into every cycle — automated tests keep quality high throughout the voyage.
Don't wait for perfection. Build the bare hull and show it early. The customer gives feedback, you improve it next iteration. Each cycle brings the product closer to what they actually need.
Fixed sprints of 2–4 weeks. Predictable rhythm.
Each sprint has a clear agreed target pulled from the backlog.
Results reviewed at sprint end. Improvements feed the next cycle.
Captain Jack keeps adding requirements to the ship. Every "great idea" feels harmless on its own. Click each one to add it to the project. Watch the budget bar. Don't fill it up. Try.
Statements drift across the deck. Some are true Agile principles — leave them alone. Others are Waterfall ideas trying to sneak aboard — fire your cannon at those! 60 seconds. Hit the wrong one and your ship takes damage.
Tap a drifting statement to fire at it. Wrong hits cost 20% hull. Correct hits = +10 points each.
A sprint is a fixed 2–4 week period in Scrum. The crew selects tasks from the backlog, holds daily stand-ups, then demos results and runs a retrospective before the next sprint sets sail.
Unlike Scrum's fixed sprints, Kanban visualises work as a continuous flow. Tasks move across columns. The key rule: limit how many tasks can be In Progress at once. When Captain Jack's crew builds his ship using Kanban, they draw the board in the sand — and every pirate sees the project's status at a glance.
🏴☠️ Jack's crew has a problem: too much rum, too many distractions, and a ship that's not building itself. So they draw a board in the sand and discover the strangest rule in project management — start fewer things and you'll finish more. Three minutes, four principles, and the trick that runs Toyota factories and tech teams alike.
Every task is a card on the board. The whole crew sees status at a glance — no one wonders what anyone else is doing.
Only a few tasks In Progress at once. Finish before starting new — work doesn't pile up unfinished.
Regular reviews identify bottlenecks and improve how work moves through the board, voyage by voyage.
Continuous input from team and stakeholders keeps improving the process — Jack, the harbormaster, even fellow pirates.
Tap a card to advance it: To Do → In Progress → Done. WIP limit: 2. Try breaking it.
Can you explain each difference in your own words before class?
Tap each statement to assign it. Each tap cycles: unassigned → 🎰 Waterfall → ⚓ Agile → unassigned. Sort all 10, then hit Check.
Use this to check your sorting — and as a study reference.
| Aspect | 🎰 Waterfall | ⚓ Agile |
|---|---|---|
| Approach | Linear, sequential | Iterative, incremental |
| Phases | 5 phases, done once in order | Repeated cycles (sprints) |
| Documentation | Extensive — every step recorded | Lighter — working software over docs |
| Requirements | Fixed at the start | Can change throughout |
| Customer | Mainly at start and end | Continuous throughout |
| Testing | After coding is complete | Built into every cycle |
| Delivery | One final release | Frequent small releases |
| Flexibility | Low — changes are costly | High — change is welcomed |
| Best for | Stable, well-defined projects | Evolving or complex projects |
Make sure you understand all of these before class.