Agile

Agile is easily one of my favorite methodologies. It's also one that almost everybody gets wrong, and the first thing they get wrong is what it even is.

So let me say it before anything else: agile is not an SDLC.

A software development life cycle is the set of stages a piece of software moves through to get built and shipped: refining the work, writing the code, reviewing it, testing it, releasing it, watching it in the wild. The SDLC page in this section walks all of that. Agile doesn't replace any of it. A lot of people think the two are the same thing, that "we went agile" means "here is our process for building software." It's far from it. Agile is the philosophy that decides how you move through those stages and what you do with what you learn. The SDLC is the road. Agile is how you drive it. Confuse the two and you'll run every ceremony on this page (the recurring agile meetings and rituals: sprints, stand-ups, reviews, retros) and still ship like it's 1998.

Some of the companies I've worked at split the word in two so people stop talking past each other. Little-a agile is the methodology: sprints, stand-ups, reviews, retros, the way the work gets done. Big-A Agile is the mindset, and my mantra for the mindset is borrowed from the futurist Jim Carroll: think big, start small, scale fast. Have the grand idea, build the smallest piece of it, put it in front of real people, then scale what they actually respond to.

This page hands you the methodology. But the mindset decides whether the methodology works, and the whole thing hangs on one word.

Empiricism.

Empiricism is the theory that all knowledge is derived from sense experience. You know what's true because you observed it, not because you predicted it. It's the engine under Carroll's last step: you can't scale what people respond to until real people have actually touched the thing. So ship it, watch a real person use it, and now you know, instead of guessing. For a product team that means one thing: if you don't release to your customer, you can't be empirical. Full stop. And "customer" here means whoever actually uses what you build, the paying user, or the other team your internal tool serves, not the executive who sponsored it.

Most people view agile as breaking work into small chunks and iterating along the way. Iteration is not agile unless you frequently release to your customer. If you aren't doing releases, you're being incremental, which is just another way of saying you're following the waterfall methodology. Waterfall is the old default: plan everything up front, build for months or years, deliver once at the end. Break that build into small chunks without releasing any of them and you've changed nothing that matters. The chunks pile up inside the building, and the customer still meets all of it at once at the end.

I like to think I have what Paul Saffo calls strong beliefs that are weakly held. Data can move me on almost anything. This is not one of those beliefs.

There is no one true agile

If agile is empirical, then it has to look different on every team. Most people never connect that.

Stay with me. Empiricism means you run the process, watch what actually happens, and change the process based on what you saw. Two different teams, two different sets of people, two different kinds of work, two different sets of constraints. Run the same honest experiment on both and they will not land in the same place. They can't. The data is different, so the answers are different.

So when you find two teams running agile exactly the same way, down to the same ceremonies on the same days for the same length, that's not a sign of discipline. It's a tell. At least one of them isn't being empirical. They copied a format off a slide instead of watching their own team and adjusting. That's cargo-culting: performing the rituals of a thing without the engine that made the rituals work.

The fix is to be agile with the format itself. The format is not sacred. It's another thing you run an experiment on.

I'll give you the cleanest example I have. The standard stand-up format is yesterday, today, blockers, and every person narrates all three. On one of my previous teams we tried something else. We put the sprint board up, the group reviewed it quickly in silence, then we went around the room on blockers only. Stand-up went from 15 minutes to 5, and the team liked having the ten minutes back. We changed the ritual because the data told us to. That's the method applied to the method: try a change, watch what happens, keep what works. A team that's truly agile is doing that to its whole process, all the time, which is exactly why no two of them end up identical.

Waterfall delays the truth

Why do most corporate employees love waterfall? Because it delays the truth. The truth is that a lot of their ideas just aren't going to work out, and a twelve-month plan means nobody finds that out for twelve months.

I've been on projects that ran two and a half, three years before anything reached a user. By the end they'd overbuilt something users only needed a tenth of. Nobody on those projects was dumb. The method protected every wrong guess until it was too expensive to admit.

So when agile gets taught inside those walls, it gets taught the same way: to protect egos. Plan smaller, work in "sprints," keep the demo internal. That's the safe sliver of the actual methodology, and conveniently, it's the sliver that never makes anyone wrong.

There's a name for the result: wagile. Waterfall wearing agile's clothes. The team runs the ceremonies, holds the demos, fills the board with tickets, and never puts working software in front of a real customer.

In 2018 the U.S. Department of Defense's Defense Innovation Board published a guide called "Detecting Agile BS" aimed at exactly this, and its flags are blunt in the best way: nobody on the team is talking with the actual users of the actual code, feedback from those users isn't continuous, and meeting requirements gets treated as more important than getting something useful into real hands fast. (Worth noticing that the military felt the need to write this down.) My own estimate, not theirs: the vast majority of vendor agile projects, the work an outside firm builds for a client, fail those criteria. Often because that's exactly what the client's management wants.

If wagile is the counterfeit, here's the real shape it's counterfeiting. The product leader Marty Cagan put it best in his book Inspired, and I teach his three principles as the test: risks get tackled up front rather than at the end, products get defined and designed collaboratively rather than sequentially, and it's about solving problems, not implementing features. Notice that none of the three mentions a ceremony.

"But I keep reading that agile is dead"

I know. LinkedIn keeps serving me the same clickbait headline. AGILE IS DEAD.

Agile is not dead; your ego is fragile, and you're lazy.

Is that harsh? Absolutely, but I don't have a better explanation for it. Agile isn't dead. What you're doing likely isn't agile.

Go back to the first principle of the Agile Manifesto, the 2001 document this whole methodology grew from: satisfy customers through early and continuous delivery. The key part of that phrase is satisfy customers. So if every sprint ends at one powerful person's demo instead of in a customer's hands, you're aiming the whole machine at satisfying the most senior person in the room instead of the customer, and you aren't being agile. That's the HiPPO trap, the Highest Paid Person's Opinion steering the work. You've built a delivery treadmill, and that's the one Part 07 walks in full: keep that treadmill running long enough and you ship a pile of "perfect" features your customers never asked for.

The team that ran one-week sprints

My preference is sprints of one or two weeks; a sprint is the fixed cycle the team plans, works, and reviews in. That's the default to reach for. One of the last teams I ran went all the way down to one week, and the why is worth telling, because the shorter cadence was a deliberate call, not a speed flex. It's the same 26-person team from Part 07, the one that capped every task at a single day so stuck work surfaced in one morning instead of five.

We ran one-week sprints for two reasons, and neither was speed for its own sake.

First, our environment changed constantly. The executives sponsoring our work would be excited about an idea one week and change their minds the next. One-week sprints let us absorb those swings instead of getting wrecked by them.

Second, and this is the part I'd hand every product manager: one-week sprints gave us a quick out. When a sponsor insisted on a pet idea and wanted it started now, we didn't argue. My team could build a prototype and test it with end users that same week. The results came back, and the results did the arguing. On longer sprints we'd have burned weeks proving the same point.

The data settled it in a week. An argument never would have.

The cadence, end to end

What follows is the little-a agile: the actual format, the meetings, the board, the cadence. Run all of it and you've got the methodology. What turns it into big-A Agile is the one thing the format can't give you on its own: empiricism, releasing to a real customer and changing your next move based on what they do. Keep that in view as you read the mechanics.

The flavor I run is scrum, and I teach it the way scrum.org defines it, because that's where I learned to teach it. Keep the team small, five to nine people; how you compose it is Part 01's territory.

Sprint planning answers three questions. Why is this sprint valuable? What can be done this sprint? How will the work get done? Out of the first question comes the sprint goal: one sentence the team rallies around all week, so every piece of work has a why above it.

Then the team sizes the work, and my favorite tool is planning poker. Every person gets a deck of cards numbered in the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21); the number you throw is your rough read on how big the work is, meaning how much effort it'll take, not how many hours. Someone reads the story (the written-up piece of work) including its acceptance criteria, the list of things that must be true for it to count as done, and everyone reveals a card at the same time. Same number, move on. Different numbers, talk.

Here's an example I use when I teach this. The task is a login screen. I vote 3. A developer votes 8. That gap forces a conversation, and it turns out they recently built a login screen against our slow authentication system and know it takes extra work just to keep the user calm while the app stalls. The card was an 8 all along. Skip the group vote and that conversation never happens. The 8 gets scheduled as a 3, and the timeline blows. Part 07 is where those numbers turn into a forecast, how you add them up across a sprint to plan what the team can actually take on. Here, the number is just the spark; the conversation it forces is the point.

The sprint runs on a board everyone can see: to do, doing, blocked, ready for review, testing, done. Work one card at a time, all the way to done, instead of starting six things. Stretch goals, the extra cards the team pre-agrees to pull in if the committed work finishes early, get planned and voted during planning too, never grabbed at random when the board empties early.

Stand-up is the daily pulse, and the standard format is yesterday, today, blockers. You already saw what we did with it earlier: we ran it, watched it, and changed it, and 15 minutes became 5. That wasn't a one-off trick. It's the standing invitation on every part of this cadence. Run it, watch it, change it.

The sprint review is a demo of real, working software to the people who asked for it. Not a PowerPoint with pictures of software. Treat it as a kind of early go/no-go: the customer sees exactly what was built and effectively signals whether it's headed the right way, while it's still cheap to change course. One language rule keeps reviews alive: drop the word "you." When a demo shows a result you doubt, say it without aiming at a person: "As presented, I don't see how the numbers line up with the outcome; can we discuss the process?" That starts a conversation. "Your numbers are wrong" kills the demo program, because nobody volunteers to be attacked.

The retrospective is the team turning empiricism on itself. Four questions: what went well, what didn't go so well, what have I learned, what still puzzles me. Stick to facts, not judgments. "Two pieces of work were rejected by our customer" is a fact; "I wish our customer was more realistic" is a judgment, and judgments start arguments. Atlassian's Agile Coach guide has the deepest treatment of retros I've found, and I lean on it when I teach this. When the retro produces ten improvement ideas, run the mantra on them. Ten ideas is the think big. The one or two the team votes in and actually implements are the start small. The next retro telling you whether they worked is the scale fast.

The two flavors worth knowing, and the one wearing a mask

Scrum is one flavor of agile among several, and saying "my team works agile" is, on its own, stating something vague. There are two flavors worth knowing up front.

Scrum is the one I run, because it flexes to the team. You shape the ceremonies, the cadence, the board, all of it, to fit the people and the work in front of you. That flexibility is the whole reason I reach for it.

Kanban is the other one you'll meet, and it's more restrictive by design. No sprints. Just a continuous queue of cards with a hard cap on how many can be in progress at once. For teams whose work arrives daily and unplanned, a support desk, say, that restriction is the right call: there's no clean two-week box to plan into, so you cap the work in flight and pull the next thing the moment a slot opens.

Then there's SAFe, the Scaled Agile Framework, the version big corporations roll out. People file it next to scrum and kanban as a third flavor. It isn't one.

SAFe is the Scooby-Doo villain. It comes at the team in the agile costume: the ceremonies, the planning events, the language, the whole rubber mask. Pull the mask off and it's the same waterfall that was scaring the team the whole time. Two-week chunks, weekly demos, requirements signed off up front, and nothing ever reaching a real customer. I'll say plainly that I hate it. It doesn't create trust, and it doesn't let small teams operate the way agile was meant to. It scales the ceremonies and quietly drops empiricism, which was the only part that ever mattered.

If you're stuck in a waterfall shop

You don't convert a waterfall organization by memo. You convert it one practice at a time, in an order that builds trust before it asks for change.

Start with stand-ups; they're cheap and nobody fears them. Then add internal demos of real work, with the no-"you" feedback language from above, so showing unfinished work starts to feel safe. These aren't the wagile demos I mocked earlier; those stay internal forever to protect egos, while these are a stepping stone, practice at showing real work before the audience includes a customer. Only then introduce sprints and retros. And the last step is the one that makes it agile: the first real release to a real customer. Until something ships, you've built better habits, not agile.

And while you do it, fly low: keep your promises modest. Under-promise and over-deliver, with one caution: under-promise by too much and people start questioning your ability to plan. The target is promises you keep, sprint after sprint, until the method has a track record nobody wants to roll back.

There's a reason the order builds trust before it asks for change. Teams that struggle with agile rarely struggle over tools or process; they struggle over psychological safety. If people fear for their jobs when they take risks, they won't take risks, and every ceremony on this page turns into theater. The no-"you" language isn't politeness. It's how you make the risk survivable.

Release something

Agile won't fix your product by itself. There's no magic in the ceremonies; a team can run every ritual on this page and still be waterfall where it counts. The methodology only pays you back when something real reaches someone real.

So audit yourself with one question: when did a real customer last touch something your team built?

If the answer is within the last sprint or two, you're agile. Tune the cadence and keep going. If the answer is months, you're incremental, and you already know what that's another way of saying.

Don't fix it with a reorganization or a framework purchase. Fix it the small way. Find the smallest piece of working software you can put in front of a real customer, and release it this sprint. Watch what they do with it. Let that pick your next move.

Release. Learn. Repeat. Everything else on this page only counts if something ships.