Events

Agile Brazil 2010 – Part 1: XP in Practice with Paper, Scissors, and True Collaboration

Experience XP through hands-on paper ATM building—discover how WIP limits, lead time awareness, and pair programming create sustainable team flow beyond just coding practices

XP - AgileBrazil2010

Series: Agile Brazil 2010 | Part 1 of 6 > Complete coverage of Brazil’s first national agile conference

Just got back to the hotel. I can still feel the intensity of a full day immersed in Extreme Programming (XP), guided by people I had long admired from afar and finally had the chance to learn from in person. Bruno Pedroso, Dairton Bassi, Daniel Wildt, Giovanni Bassi, Hugo Corbucci, and Renato Willi delivered one of the most complete hands-on XP workshops I’ve ever experienced. This wasn’t just about concepts — it was about living them.

Pomodoros and Purpose

We kicked off the day with a rhythm: the Pomodoro technique. These 25-minute focus sessions, punctuated by breaks, gave structure to our learning. Each Pomodoro introduced a topic — XP cycles, values, practices, principles — in digestible bursts of theory followed immediately by practical activities. It kept our energy high and attention sharp all day long.

One of the earliest cycles had us post our expectations on a wall using sticky notes. It might seem trivial, but it immediately created a sense of inclusion. This wasn’t a lecture — it was our space, our learning. The wall became our emotional backlog for the day.

The Paper ATM

The standout activity was building a paper-based ATM. Split into teams, each group had to construct their product using paper, markers, shoeboxes, and tape. Sound childish? It wasn’t. The constraints drove creativity and forced meaningful collaboration.

We followed real XP iterations: clearly defined roles, short sprints, visible deliverables, rapid feedback from “clients” (our facilitators). With every cycle, new features were added, and every team hit walls — some from poor communication, others from failing to validate early with stakeholders.

It wasn’t about making a beautiful model. It was about team dynamics, communication loops, and delivering incrementally. This is where XP came to life.

Managing WIP: Less Really Is More

Midday, the facilitators introduced a challenge: reduce the number of features being worked on simultaneously. That’s when Work In Progress (WIP) limits became real. Until then, many teams — ours included — were juggling too many tasks. The effect? Nothing got finished.

By capping our WIP, clarity returned. We focused. Conversations became crisper. Dependencies got resolved. We delivered more by trying to do less at once. Morale even improved — finishing something before starting something else gave us momentum.

Limiting WIP isn’t just a flow strategy. It’s cultural. XP needs this discipline to truly shine.

Lead Time: The Delay Isn’t in the Code

At another point, we explored Lead Time — the total duration from when a feature is requested to when it’s actually done. We discovered delays weren’t technical. They stemmed from unclear scope, decision bottlenecks, and unvalidated assumptions.

XP attacks this head-on with short iterations, constant feedback, and engaged stakeholders. We saw teams with shorter lead times because they released smaller chunks. Others bundled features, but progress became invisible. A clear takeaway emerged: fragmenting value doesn’t weaken it — it exposes it.

We were forced to confront how much time we really spend creating value, and how much is consumed by everything else.

Cycle Time: Learning the Team’s Natural Rhythm

Later in the day, we focused on Cycle Time — how long a feature takes from “in progress” to “done.” It measures execution flow. Some teams had very short cycle times — but skipped critical steps. Others moved slower but delivered working slices with consistent quality.

XP practices like continuous integration and TDD were modeled even in our paper-based setting. Teams that monitored cycle time could adapt and deliver predictably. We saw how measuring this helped us find balance: not rushing, not stalling.

Cycle time reminded us: sustainable pace isn’t about going slow or fast — it’s about learning to move together.

XP Is a Stance, Not a Stack

Daniel Wildt hit a chord with me when he said XP is not about tooling — it’s about posture. He walked us through the Chaos Report, showing how failed projects often don’t lack code, but rather alignment. Poor scoping, low engagement, and communication breakdowns are the real dangers.

XP values — courage, feedback, simplicity, communication, respect — are more than posters on a wall. They’re daily habits. They manifest in small acts: a clear commit message, an honest retro, or the humility to refactor.

This session reframed XP not as an engineering solution, but a cultural stance.

Pairing Up: More Than Just Coding

In the late afternoon, we paired up to tackle a deceptively simple problem: converting numbers to English words. It quickly became a mirror — not of our technical skill, but of our collaboration. We had to negotiate ideas, sync logic, explain clearly, and revise respectfully.

XP isn’t just about pairing for code coverage. It’s pairing to build shared understanding. Even with paper and markers, the same dynamics of a real codebase emerged: merge conflicts, naming decisions, test cases, logic drift. This is why XP values pairing — it teaches us to build together.

XP - Agile Brazil 2010

Exhausted but Energized

Back at the hotel, still wearing my backpack, I stood in silence for a moment. My brain was tired, but my motivation was lit. I had not just attended a training — I had experienced a mindset.

To the facilitators: thank you. And to every teammate today: I hope we keep building things with clarity, respect, and courage. May we deliver more than code — may we deliver with purpose.


Agile Brazil 2010 Series Navigation: