From Theory to Practice: Bringing SAFe to Life in One Day

Sharing how SAFe shapes our daily work

On 21 September 2026, we hosted a full-day Agile workshop for the procurement team of one of our customers. The goal was simple: build a shared, practical understanding of the Scaled Agile Framework (SAFe), not through slides alone, but by letting people experience the principles first-hand. Along the way, we gave them a look behind the scenes at how our own teams work with SAFe every day. 

For us, SAFe is not a set of meetings. It is the rhythm that keeps multiple teams aligned while each one delivers independently. And it is not reserved for software developers: we have brought non-technical teams, including our own marketing team, into the same way of working. That journey takes patience, but it is exactly why we believe Agile works well beyond IT. 

From daily alignment to continuous improvement

• Daily Standups: Each team syncs quickly on what's done, what's next and any blockers.
• Scrum of Scrums: Team representatives meet to resolve cross-team dependencies fast.
• Business value first: Work is prioritised by value, not by effort.
• Demos: Customers see real, working results instead of progress reports.
• Definition of done: Only fully completed work counts as delivered.
• Inspect & Adapt: Before every new Program Increment, we step back, look at what happened and improve how we work.

These ceremonies are connected, and each one feeds the next, so everyone moves forward in one delivery cycle.

The roles behind the rhythm 

Clear roles are what make the rhythm work. During the workshop, we showed how these SAFe roles map onto our own organisation:

• Business Owners: carry business and technical responsibility for the return on investment and make sure what we build meets real business needs.
• Product Owner: the voice of the customer in the team. Owns requirements and priorities, but is not a project manager and does not assign tasks.
• Scrum Master / Team Coach: a servant leader who protects the process, not the team’s boss.
• System Architect: keeps the technical direction consistent across teams.
• Release Train Engineer (RTE): keeps the whole Agile Release Train in sync, much like a conductor keeps the beat.

One distinction sparked a lot of discussion: the difference between the person who owns the requirements (the Product Owner) and the person who implements the tool. In practice, those roles are often blurred, and that is where priorities get lost.

A day built around three simulations 

The people in the room had very different levels of Agile experience, from none at all to several years of hybrid practice. So instead of assuming shared knowledge, we built the day around three hands-on simulations, each designed around one core Agile principle. Everyone could feel the principle before we explained it.

1. The Paper Airplane Challenge: why plans need checkpoints

Teams had 60 seconds to build the best paper airplane, with no criteria given. In round one, the goal was distance. In round two, the same planes had to land on a target. 

The debrief made the point: “best” only means best against today’s goal. A plan without checkpoints cannot respond when priorities shift. Inspecting and adapting after every cycle is a far stronger habit than a single lessons-learned review at the end of a project, which usually comes too late to act on. We also talked about the cultural side: teams need to feel safe saying something isn’t going to plan, without fear of blame. 2. Passing the Ball: estimation, flow and predictability

The whole group formed one team and passed tennis balls down a line, without using hands and without throwing. Over three rounds, they estimated how long it would take, ran it against the clock, then paused to inspect what slowed them down before trying again.

Two things happened. First, estimates and actual times moved closer together every round, not because people guessed better, but because they learned from each cycle. Second, a simple “one ball at a time” rule showed how a steady, continuous flow beats working in batches. One participant even started counting out a steady drumbeat for the group, without knowing it, doing exactly what a Release Train Engineer does.

Practical takeaway: size work small enough to finish within a single sprint. When people split their time across several initiatives, work that spills over sprint boundaries creates idle time and costly re-familiarization. 3. The Cup Tower Challenge: a Program Increment in 45 minutes

The final simulation brought everything together in a full mini delivery cycle.

• Three teams of two or three people each built part of one shared “castle”: a left wing, a right wing and the bridge connecting them.
• Business value was assigned to each part, and all teams had to prioritise accordingly.
• Limited resources: all teams shared one pool of cups, which created real dependencies.
• Standups were held as often as each team decided.
• Two Scrum of Scrums sessions helped the teams resolve blockers, share materials and agree on shared constraints, such as how far apart the wings could be so the bridge would still fit.
• The customer demo closed the exercise, and only fully standing structures earned points.

The demo turned into a real business-value discussion. One team proudly added a flag nobody had asked for. Does an unrequested extra add value, or does it just consume effort? And a missing connection between the bridge and the castle was flagged as a legitimate reason to deduct a point. The final score was deliberately left open, just like many real stakeholder negotiations.

What the challenge taught us 

In just 45 minutes, principles that often take months to sink in on real projects became clear to everyone in the room.

• Standups are for syncing, not planning. Quick check-ins kept teams aligned, but they worked best when the plan was already in place.
• The Scrum of Scrums unblocks. When cups ran short, representatives solved cross-team dependencies without taking over each other's work.
• Value leads, effort follows. Teams that focused on the highest business value first scored the most.
• Done means done. A structure that was almost finished but didn't stand scored nothing. Only completed work delivers value.

These are the same lessons our teams apply every day, now experienced first-hand.

Final result, built during the workshop:

From big idea to “provably done”

Good delivery starts with well-written work. We walked through how SAFe breaks large ambitions down into pieces a team can deliver and test:

1. Epic: a large business outcome spanning several Program Increments. It answers: why does this matter to the business?
2. Feature: a deliverable slice with its own benefit, sized to one Program Increment. What capability are we delivering?
3. User Story: a small piece of work finished within one sprint. What does the user actually do?
4. Acceptance Criteria: specific, testable conditions that define “done”. How do we prove it’s done?

Each level trades breadth of vision for precision of delivery, moving from “the right direction” to “provably done”.

Participants then practiced with a fictional coffee-shop app and its persona, Mia, a regular customer who is always in a hurry. Using the “As a… I want to… so that…” format and Given/When/Then acceptance criteria, they wrote stories such as reordering a usual drink in one tap. The test we use ourselves: could someone who has never seen the app read the story and know exactly what to build and how to check it, without asking us anything?

Several participants saw this structure as immediately useful for writing sharper, clearer problem statements in their own work.

• Inspect & adapt, not look back at the end. Improving after every cycle instead of waiting for a final retrospective.
• Predictability over speed. A steady, reliable flow is what builds stakeholder confidence, raw speed does not.
• A shared language. Epics, Features and User Stories give business and delivery teams one way to describe work.
• Learning by playing. The games made abstract concepts tangible. Participants even suggested using short “mini Agile trainings” at the start of new projects, to teach the principles and build team cohesion from day one.

Everyone also agreed on one honest point: becoming Agile is a gradual process. A workshop does not change an organization overnight, but it does create a shared starting point and a common vocabulary to build on.

Curious how SAFe could work for your organization?

We’d be happy to show you how our teams bring Agile to life every day or run a hands-on session like this one with your team, from a focused simulation to a full-day workshop with a follow-up deep dive.