Topic 5 — Agile and Scrum in depth

Goal: Understand agile values and run the Scrum framework confidently.

Lesson 5.1 — Why teams stopped planning everything up front

When Renata coordinated a 300-person conference, the plan was the job. Months out, she'd lock the floor layout, the menu, the run-of-show down to the minute. The event happened once, the rules never changed, and a binder you finished in March still held in October.

Her first week at Cartwheel, she reached for the same binder. She asked Marcus, the tech lead, for a full plan of the driver app: every screen, every feature, dates for all of it. Marcus gave her a look she'd come to know. "We don't actually know what drivers need yet," he said. "We'll know more after they touch the first version."

That was Renata's introduction to the agile mindset. The idea is simple once you feel the difference: in software, you can't predict everything up front, because you learn what to build by building a little and watching people use it. So instead of one giant plan executed start-to-finish, agile teams work in small steps, get feedback often, and adapt as they learn.

The older way Marcus was pushing against has a name: waterfall. In waterfall you finish each phase completely before the next begins. Gather all requirements, then design the whole thing, then build it all, then test it, then release. It works beautifully when the requirements won't change. A conference is waterfall. A new app for couriers, where you're guessing what real drivers will tolerate at 6 a.m. in the rain, is not.

Agile isn't "no plan." It's a plan you expect to revise the moment reality tells you something new.

Lesson 5.2 — The four values behind the word

Renata kept hearing "agile" used to mean "fast" or "no documentation" or "we change our minds a lot." None of those is quite it. The word traces back to a one-page document a group of software people wrote in 2001, the Agile Manifesto, and it's worth knowing what it actually says, because people will quote it at you.

It names four values. Each is a preference, not an absolute, written as "we value the first thing over the second":

• Individuals and interactions over processes and tools. A quick conversation often beats a perfectly filled-out form.
• Working software over comprehensive documentation. A thing drivers can tap on tells you more than a 40-page spec about it.
• Customer collaboration over contract negotiation. Stay close to the people you're building for instead of arguing over who promised what.
• Responding to change over following a plan. When you learn the route screen confuses drivers, you change the route screen.

The manifesto is careful about that last word in each line. There is value in the things on the right. Processes, documents, and plans all matter. The point is which one wins when they collide.

For Renata, this reframed her whole job. At the conference, her job was to enforce the plan. At Cartwheel, her job became to help a team adapt well as it learns. Same instinct for keeping things organized, aimed at a moving target instead of a fixed one.

Lesson 5.3 — Scrum's three accountabilities

Agile is the mindset. Scrum is the most common concrete framework for working that way, and it's almost certainly the one a job ad means when it says "agile experience." Renata's squad runs Scrum, which makes her the Scrum Master.

A small but important word first. The current Scrum Guide (the official rulebook, last updated in 2020) deliberately stopped calling these "roles" and calls them accountabilities. The reason matters in practice: "role" sounds like a job title and a person, but one human can hold more than one, and what's defined is what each is answerable for, not a seat on an org chart. There are three.

The Product Owner is accountable for maximizing the value of the product. On Renata's squad that's Priya, who owns and orders the Product Backlog. Priya decides what gets built and in what order, and why. When everyone wants their pet feature next, Priya is the single person who makes the call.

The Scrum Master is accountable for the team's effectiveness — that's Renata. Notice it is not "the boss." She helps the team get better at Scrum, facilitates the events so they're useful instead of endless, and clears the obstacles in people's way. When Jamie, the QA engineer, is stuck waiting three days for a test environment, getting that unblocked is Renata's job.

The Developers are accountable for building the increment — the actual usable product each cycle. That's Marcus and Jamie and anyone else doing the building, including design and testing work. The Scrum Guide groups all the builders under this one word.

Product Owner owns what and why. Developers own how and the building. The Scrum Master owns how well the whole thing runs.

Lesson 5.4 — Three artifacts, each with a promise

Scrum tracks work through three artifacts. Renata found these click faster once she learned the twist the 2020 guide added: each artifact carries a commitment, a specific thing it's promising to keep it honest.

The Product Backlog is the full, ordered list of everything that might get built for the driver app — every feature, fix, and idea, with the most important at the top. Priya owns it. Its commitment is the Product Goal: the single bigger objective the whole backlog is climbing toward (for Cartwheel right now, "drivers can plan a full day's route in under two minutes"). The goal keeps the list from becoming a junk drawer.

The Sprint Backlog is the slice the team pulls in for the current short cycle, plus the plan to deliver it. Its commitment is the Sprint Goal: one sentence naming what this sprint is really for, so that if the details shift mid-week, everyone still knows the point.

The Increment is the working, done piece the team produces each cycle. Its commitment is the Definition of Done: the shared checklist for what "done" actually means — coded, tested, reviewed, no known critical bugs. If it doesn't meet the Definition of Done, it stays out of the Increment, however close it looks. This one quietly saves Renata from the oldest trap in delivery: work that's reported as "done" but isn't.

Artifact	What it is	Its commitment
Product Backlog	the full ordered wishlist	Product Goal
Sprint Backlog	the slice for this cycle + the plan	Sprint Goal
Increment	the done, usable result	Definition of Done

Lesson 5.5 — The sprint, and the events inside it

Here's the rhythm that ties it all together. A sprint is a short, fixed cycle — one month or less, most commonly two weeks — in which the team turns a slice of the backlog into a usable, done increment. It's the heartbeat. One ends, the next starts immediately, the same length every time. That steady beat is what makes the team's pace predictable enough for Renata to give Tomás, the engineering director, a straight answer about when things will land.

The Sprint is itself a container event holding four others. Renata facilitates all of them, and facilitating them well is most of her week:

• Sprint Planning opens the sprint. The team agrees on the Sprint Goal and pulls items off the Product Backlog into the Sprint Backlog. Priya brings the priorities, Marcus and Jamie size the work and decide how much they can take. Marcus's build estimates live here.
• The Daily Scrum is a ~15-minute daily sync for the Developers to inspect progress toward the Sprint Goal and re-plan the day. It's short and focused, not a status report to the manager. Renata's job is to protect those fifteen minutes from sprawling into an hour.
• Sprint Review closes the sprint's work. The team shows the actual increment to stakeholders — Tomás, sometimes a real courier — and gathers feedback that feeds the backlog. It's a working demo, not a slide deck.
• Sprint Retrospective closes the sprint's learning. The team inspects how it worked — not the product, the process — and picks a concrete improvement or two for next time. This is the continuous-improvement engine of Scrum.

One more activity isn't a formal event: Backlog Refinement. It's the ongoing work of keeping upcoming items clear, sized, and ready, so Sprint Planning is quick instead of a four-hour slog. Renata and Priya do a little most weeks.

And a tool you'll meet on day one: the burndown chart, a simple line showing how much work remains in the sprint, sloping down toward zero. If the line flattens while days tick by, the team can see it's falling behind early enough to do something — drop scope, or warn Tomás before the deadline, not on it.

Worked example — Renata's first two-week sprint

Cartwheel's driver app needs a feature: drivers should be able to mark a delivery "failed — nobody home" and have it reschedule. Priya, the Product Owner, has it near the top of the Product Backlog because couriers complain about it constantly. It ladders up to the Product Goal of planning a day's route fast.

Monday, Sprint Planning. Priya explains the why. The team writes a Sprint Goal: "A driver can mark a delivery failed and reschedule it without calling dispatch." Marcus estimates the build, Jamie flags that the reschedule logic needs careful testing, and together they pull a realistic set of items into the Sprint Backlog. They agree on the Definition of Done: coded, tested on a real device, no critical bugs.

Every morning, the Daily Scrum. Fifteen minutes, standing. On Wednesday Jamie says the test devices won't sync — that's a blocker, and unblocking it is Renata's job, not the team's. She has it fixed by lunch.

Midweek, the burndown chart flattens. Renata notices the remaining-work line stalled for two days. Rather than hope, she raises it: scope is slightly too big. She and Priya agree to push a minor sub-feature to next sprint so the Sprint Goal still lands. She gives Tomás a calm heads-up instead of a deadline-day surprise.

Final Friday, Sprint Review. The team demos the working feature to Tomás and a courier on the call. The courier asks for a confirmation buzz — useful feedback, which Priya adds to the backlog.

Then, the Retrospective. The team reflects on how the sprint went. The test-device delay cost a day; their improvement for next sprint is to confirm device sync the Friday before. The increment ships. The next sprint starts Monday.