Learning agile development is a lot like learning a basketball jump shot. You can read about it. You can watch videos. You can understand the mechanics intellectually. But until you actually practice it — until you feel what it's like to release the ball at exactly the right moment — it doesn't click.
That's the idea behind 18F Consulting's agile workshop. We designed it so that participants don't just learn agile theory; they actually do agile. Three sprints, a real (if simplified) product, real stakeholder feedback. By the end, they've experienced the rhythm of iteration — and they understand why it works.
Why three sprints?
One sprint isn't enough to see the pattern. After one sprint, it feels like a rush — build something quickly and present it. Two sprints start to show the loop. Three sprints is where it lands. Participants begin to anticipate the retrospective. They start thinking ahead to the next sprint before the current one ends. The rhythm becomes intuitive.
Three sprints also gives you room to fail productively. In our workshops, teams almost always build something in sprint one that doesn't quite work. Sprint two is where they recover. Sprint three is where they surprise themselves.
The setup
Each sprint is compressed — typically 20 to 30 minutes of work, followed by a stakeholder demo and a brief retrospective. The product is deliberately simple: something that can be sketched, prototyped, or described in a short document. The point is the process, not the artifact.
You need a few things to make it work:
- A product owner (ideally someone from outside the immediate team) who can give real feedback during demos
- A facilitator who keeps time and keeps the energy up
- A backlog — even a rough one — of user stories to start from
- Materials: index cards, sticky notes, markers, or a simple digital tool
What happens in each sprint
Sprint planning (5 minutes): The team reviews the backlog, selects stories for the sprint, and commits to what they'll deliver. This is intentionally brief — the point is to make decisions and start, not to over-plan.
Sprint work (20–30 minutes): The team builds. In a real project this would be development; in the workshop it might be sketches, a written document, or a rough prototype. The facilitator calls time.
Demo (10 minutes): The team shows what they built to the product owner. The product owner gives feedback. This is where the most learning happens — teams discover quickly what they built that wasn't what was needed, and why.
Retrospective (5–10 minutes): What worked? What didn't? What will we do differently next sprint? Keep it brief and actionable.
What participants take away
The most common thing we hear at the end of a three-sprint workshop: "I didn't expect the demo to feel so different from what I thought the product owner wanted." That gap — between what teams build and what stakeholders need — is exactly why agile exists. Experiencing it firsthand, and then recovering from it in sprint two, is worth more than any amount of reading.
The second most common thing: "I want to do this with my actual team." That's the goal.
If you want to run your own version, the materials are straightforward. Start with a simple product concept, keep the sprints short, and make sure you have a product owner who will give honest feedback. The rest follows from there.
Originally published on the 18F blog. As a work of the U.S. federal government, this content is in the public domain.