How Software Actually Gets Built

The launch that didn't

Priya ran project management at a mid-size logistics company. Her team had spent nine months building a new delivery-tracking app, following a plan that, on paper, was flawless: three months to gather every requirement, three months to design the whole system, three months to build it exactly as designed, then test and ship.

It's called the Waterfall model, because work flows in one direction, downhill, through fixed stages: requirements, design, build, test, release. Nothing moves to the next stage until the one before it is completely finished.

Three weeks after launch, the app was pulled. Drivers couldn't mark a delivery "attempted but failed", a scenario nobody had written down back in month one, because back in month one, nobody had actually watched a driver work a real route yet. By the time anyone realized the gap, the design was locked, the code was written against that design, and fixing it meant reopening a stage the team had closed six months earlier.

This wasn't Priya's team being careless. It's the structural problem with Waterfall: it assumes you can know everything up front, and bets nine months on that assumption being right.

What Agile actually changed

The response to that failure is where most modern software teams now live: Agile. Not a tool, not a piece of software, a different bet entirely. Instead of planning everything up front and building it once, Agile teams build a small piece, show it to real users, learn what's wrong, and adjust, over and over, in short cycles.

The four ideas underneath Agile, from the original Agile Manifesto, all point the same direction:

• Individuals and interactions over rigid processes and tools
• Working software over exhaustive documentation
• Customer collaboration over locking in a contract up front
• Responding to change over following a fixed plan

Notice what it doesn't say: documentation, process, and planning aren't bad, they're just not the point. The point is working software that real people can react to, as early and as often as possible.

Scrum: Agile with a rhythm

If a driver had tested the delivery-tracking app after two weeks instead of nine months, the "delivery attempted but failed" gap would have surfaced almost immediately, cheap to fix, not catastrophic. That's the entire idea behind Scrum, the most common way teams actually run Agile day to day.

Scrum organizes work into short, fixed cycles called sprints, typically two weeks. Inside every sprint:

• The team pulls a small batch of work from the product backlog (everything that could be built, roughly ranked) into a sprint backlog (what this specific sprint will actually deliver)
• A daily standup, a short check-in, keeps blockers visible instead of buried until the end
• A sprint review at the end shows real, working software to real stakeholders, not a slide deck about what will eventually exist
• A sprint retrospective asks the team what to change before the next sprint starts

Two weeks is short enough that a wrong assumption gets caught almost immediately, and long enough that the team can actually finish something real inside it.

The five roles you'll meet on every team

Every software team, regardless of company size, tends to fill the same handful of roles. You'll see these names constantly for the rest of this course, so it's worth meeting them once, clearly:

• Product Owner — decides what gets built and in what order, representing what customers and the business actually need.
• Scrum Master — protects the team's ability to work, removes blockers, keeps the process healthy. Not a manager telling people what to do.
• Development Team — builds the thing: engineers, designers, whoever's hands are actually on the product.
• QA — checks that what got built actually works the way it's supposed to, before a customer finds out otherwise.
• DevOps Engineer — the role this entire course builds toward: making sure what QA approved can move from a developer's laptop into production, safely, repeatedly, without someone manually copying files at 11pm.

That last role is the bridge to everything else in this course. Agile and Scrum solve what to build and in what order. DevOps solves a different, equally hard problem: how that finished work actually, reliably, gets in front of a real user. That's Module 3 onward, once Foundations wraps up.

Check your understanding

Five questions, all from this module. Get 4 out of 5 to mark it complete.